Plain-language definitions of the attack-surface and application-security terms we use
across Maphra and AppSecD. New to the categories? Start with
EASM vs ASPM or the FAQ.
External Attack Surface Management (EASM)
The practice of continuously discovering, attributing and analysing everything an organisation exposes to the internet — from the outside in, the way an attacker would. Rather than starting from a known asset list, EASM starts from a domain and works outward: enumerating subdomains, resolving infrastructure, fingerprinting live services and attributing each asset back to its owner. Maphra is DedSec's EASM platform and does this with no agent and no credential into your estate.
Application Security Posture Management (ASPM)
Consolidating the application-security scanning disciplines — SAST, DAST, SCA, secret detection, IaC, container and API security — against one deduplicated finding model with a real vulnerability lifecycle, instead of running each tool in its own silo. AppSecD is DedSec's ASPM platform: it unifies those engines so a vulnerability is deduplicated once and tracked once, from the pull request to resolution.
Attack Surface
The total set of points where an unauthorised user could try to enter or extract data from a system. For a modern organisation that means every internet-facing host, subdomain, API, certificate, cloud endpoint and exposed service — including the ones nobody registered. The attack surface changes constantly, which is why discovery is treated as a continuous process rather than a one-time inventory.
Subdomain Takeover
An exposure that occurs when a DNS record (often a CNAME) still points at a third-party service that has been de-provisioned, letting an attacker claim that service and serve content from your subdomain. It is a classic consequence of shadow IT and decommissioned infrastructure, and a reason attribution and dangling-record detection matter in attack surface management.
SAST (Static Application Security Testing)
Analysis of source code, bytecode or binaries without running the application, to find vulnerability patterns such as injection, unsafe deserialisation or hard-coded secrets. SAST runs early — typically in the pull request — so a flaw is caught before it ships. In AppSecD, SAST is one input into a unified finding model rather than a standalone tool.
DAST (Dynamic Application Security Testing)
Testing a running application from the outside by sending crafted requests and observing responses, with no access to source code. DAST finds issues that only appear at runtime — authentication flaws, misconfigurations, injection reachable through the live app. It complements SAST: SAST sees the code, DAST sees the behaviour.
SCA (Software Composition Analysis)
Identifying the open-source and third-party components an application depends on and matching them against known vulnerabilities and licence obligations. Because most modern code is dependencies, SCA is where a large share of real risk lives. Pairing SCA with reachability analysis separates the vulnerable packages you actually call from the ones you merely ship.
Secret Detection
Scanning code, commits, history and configuration for credentials that should never be there — API keys, tokens, private keys, passwords. Because a leaked secret is immediately exploitable, detection across the full git history (not just the latest diff) matters, as does validating whether a found secret is still live.
Infrastructure as Code (IaC) Scanning
Checking Terraform, CloudFormation, Kubernetes manifests and similar declarative infrastructure for insecure defaults and misconfigurations — public buckets, over-broad IAM, open security groups — before they are applied. It shifts cloud misconfiguration left, catching the exposure in review rather than after it is live.
Container & Kubernetes Scanning
Inspecting container images for vulnerable OS packages and application dependencies, and Kubernetes configurations for unsafe settings. It answers two questions: is the image you are about to run full of known CVEs, and is the cluster configured to contain a compromise if one happens.
API Security Testing
Discovering an application's APIs (REST, GraphQL, gRPC) and testing them for the failures that dominate API breaches — broken object-level authorisation, broken authentication, excessive data exposure. Because APIs are frequently undocumented, discovery is half the work; you cannot test an endpoint you do not know exists.
Reachability Analysis
Determining whether a vulnerable piece of code is actually callable from the application's execution paths, rather than merely present as a dependency. Reachability is what separates a finding that matters from one that does not, and it is the main reason a long raw scan list can be reduced to a short, truly-actionable one.
Attack Chain
The ordered sequence of steps an attacker links together to reach an objective — for example, a forgotten subdomain leading to a live service, to a leaked credential, to a validated exploit. Thinking in chains, rather than isolated findings, is how exposure is prioritised by what an attacker could actually accomplish.
Certificate Transparency (CT)
A public, append-only set of logs recording every TLS certificate a certificate authority issues. Because a certificate names the hosts it protects, CT is a rich, passive source for discovering an organisation's subdomains — the same starting point real external-recon tools and Maphra's discovery use.
SBOM (Software Bill of Materials)
A machine-readable inventory of every component in a piece of software, with versions and licences, published in a standard format such as CycloneDX or SPDX. An SBOM lets you answer 'are we affected?' the moment a new vulnerability lands in a widely-used library, instead of auditing by hand.
SPF, DKIM & DMARC
The three DNS-published standards that let receivers verify email really came from your domain. SPF lists who may send, DKIM cryptographically signs messages, and DMARC ties them together and tells receivers what to do with mail that fails. Missing or non-enforcing records let anyone spoof your brand — which is why they are part of an external posture assessment.
Shadow IT
Internet-facing assets and services stood up outside the knowledge of the central security or IT team — a marketing microsite, a forgotten staging host, an unmanaged cloud account. Shadow IT is dangerous precisely because it is unmonitored, and finding it is a core job of attack surface management.
CVE & CWE
A CVE (Common Vulnerabilities and Exposures) is a unique identifier for a specific, publicly-known vulnerability in a specific product. A CWE (Common Weakness Enumeration) names the underlying class of flaw — for example, SQL injection or improper authentication. CVEs are instances; CWEs are the categories they belong to.
Maker-Checker (Dual Control)
A control where one person proposes a change or decision and a different person approves it, so no single actor can act unilaterally. In a vulnerability lifecycle it means a finding's status change — accepting a risk, marking a false positive — is reviewed, keeping the record trustworthy and audit-ready.