DedSec Security Research · 2026-10-14
Security tooling tends to be argued about as if it were a single shopping decision — one budget line, one platform, one winner. But attacks do not arrive from a single direction, and two of the most important questions a security team can ask are not variations of each other. They are opposites.
*What are we shipping into production right now?* That is an inside-out question. You answer it by looking at your code, your dependencies, your pipelines — the things you control and can read directly.
*What can an attacker reach without any credentials?* That is an outside-in question. You answer it the way an attacker would: starting from a domain name, with no access and no inventory, discovering what is exposed.
A tool built to answer one of these answers the other badly or not at all. That is not a gap in any particular product; it is a consequence of where each one stands.
Application security works from the inside out, with full knowledge of the thing being examined. AppSecD runs SAST, DAST, SCA, secret detection, IaC, container, Kubernetes and API security from one platform — wired into Git, gated at the pull request, and managed through a real vulnerability lifecycle.
Its strength is precision at the source. It can read the git history to find a credential that was deleted in the latest commit but still sits in the repository. It can trace taint from source to sink across function boundaries to say whether a vulnerable path is even reachable. It can block a pull request the moment it introduces a violation, while the author still remembers why the code is shaped that way. Found in the pull request, a vulnerability is a five-minute change; found in a breach report, it is not an engineering problem any more.
But this precision depends entirely on having the code. AppSecD knows about what connects to your Git. It is, by design, blind to the asset nobody checked into a repository: the forgotten staging host, the vendor-provisioned microsite, the credential leaked in someone else's breach.
Attack-surface management works from the outside in, with no special knowledge at all — which is the point. Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. It starts from nothing more than a domain name.
Its strength is completeness from the attacker's vantage. It enumerates subdomains, resolves infrastructure, fingerprints live services and attributes each asset back to your organisation — including the assets you forgot you owned. It watches the parts of the attack surface that sit outside the perimeter entirely: leaked credentials in breach corpora, look-alike domains and impersonating applications — attack paths against your users that never touch your network, so no internal tool can see them.
But the outside-in view cannot read your source. It sees the login form on the forgotten host; it does not see the SQL injection in the handler behind it until an active check, inside an explicit scope boundary, proves the behaviour. It knows what is exposed, not what is about to be written.
Put the blind spots side by side and the complementarity is exact.
AppSecD sees a vulnerability in code that is in your repositories, before it ships. It does not see the asset that was never in a repository.
Maphra sees every asset an attacker can reach, including the ones nobody remembered. It does not see the flaw in the code before that code becomes a live, reachable service.
A flaw caught in the pull request never becomes exposure — that is the inside-out win. An exposure that exists regardless of your code — a reused credential, a look-alike domain, a host a vendor stood up and never told you about — is caught only from the outside. Each tool's strongest capability is precisely the other's structural blind spot. That is why the two overlap very little, and why most teams run both.
The two directions are not just complementary; they converge on the same discipline. Neither platform treats a long list as the deliverable.
Maphra ranks findings by real reachability and retains the evidence per finding, so a theoretical CVE does not raise an alarm unless it touches an asset you actually operate. AppSecD ranks findings by whether the vulnerable path can be reached, using interprocedural taint analysis and CVE-reachability, so a team is not paged for code that cannot be hit. Both deduplicate across scans and track findings through new, reopened and fixed with ownership and an SLA. One works from the attacker's outside view, the other from the developer's inside view, but both answer the same underlying question — *which of these can actually hurt us?* — rather than *how many are there?*
You do not have to adopt both at once, and the sensible order follows the risk you cannot currently see.
The directions are different, the blind spots are mirror images, and an attacker does not care which one you bought. Covering one direction well simply means the next intrusion comes from the other.
See both against your own estate. Book a walkthrough rather than a canned demo — or start outside-in for free with the attack-surface scanner, email authentication check and credential exposure check.