Application Vulnerability Management: From SAST to Runtime Defense

Application vulnerability management is the practice of systematically finding, prioritising, and remediating security weaknesses in your code, dependencies, and running applications before attackers exploit them. It spans everything from static code analysis in a developer’s IDE to runtime threat detection in production, and as of 2026 it has become the operational backbone of any credible DevSecOps programme.

The shift matters because vulnerabilities are no longer discovered only after a pen test or a breach. Modern engineering teams ship code daily, pull hundreds of open-source packages, and deploy across containerised, cloud-native environments where the attack surface grows faster than manual review processes can keep up. A structured programme gives your security team visibility at every stage, not just at the end of the release cycle.

This guide covers the four core scanning disciplines, where each belongs in your CI/CD pipeline, how software supply chain risk fits in, and the practical side of keeping findings manageable without burning out developers.

SAST, DAST, SCA, and IAST: Precise Definitions

SAST (Static Application Security Testing) is the analysis of source code, bytecode, or binary without executing the application. It runs at build time, integrates directly into your IDE or CI pipeline, and surfaces issues like SQL injection patterns, hardcoded credentials, and insecure deserialisations before a single line reaches production. Tools in this category include Semgrep, Checkmarx, and Snyk Code. Because SAST reads the code directly, it produces results specific to your codebase and can pinpoint the exact file and line number.

DAST (Dynamic Application Security Testing) is the analysis of a running application by sending it crafted inputs and observing the outputs. It does not need access to source code, which makes it useful for testing third-party components or APIs where you only have a black-box interface. OWASP ZAP is the canonical open-source DAST tool; commercial alternatives include Burp Suite Enterprise and HCL AppScan. DAST finds issues that only appear at runtime: authentication bypasses, server misconfigurations, and reflected or stored XSS that no static analyser can confirm without an actual HTTP response.

SCA (Software Composition Analysis) is the enumeration and vulnerability assessment of your open-source dependencies. It reads your package manifests, lock files, and container image layers, then cross-references them against vulnerability databases like the National Vulnerability Database and OSV.dev. Dependabot, Trivy, and Snyk Open Source fall into this category. SCA also produces a Software Bill of Materials, which is increasingly a procurement requirement in enterprise and government contracts.

IAST (Interactive Application Security Testing) is instrumentation applied directly inside the running application, usually as an agent or library that hooks into the framework. It monitors real traffic, whether from your automated test suite or QA testers, and flags vulnerabilities as they are triggered. IAST sits between SAST and DAST conceptually: it has the precision of static analysis because it knows the execution path, and the realism of dynamic analysis because it observes live data flows. Contrast Security and Seeker are the dominant commercial offerings. IAST is most effective in organisations that run substantial integration or regression test suites, since coverage depends on traffic variety.

Where Each Method Belongs in the CI/CD Pipeline

Mapping each tool to the right pipeline stage is where most programmes either succeed or create friction that developers work around. The principle is simple: fail fast, fail where the developer can act immediately.

SAST and SCA run at pull request time. A developer opens a PR, the pipeline kicks off both scans, and blocking findings appear as inline review comments before code merges. This is the point where remediation is cheapest: the developer still has the code fresh in mind, no downstream consumers exist yet, and the fix is a single commit away.

DAST runs against a deployed staging environment. You cannot run DAST against source code; you need a live application serving real HTTP. This means DAST results arrive later in the cycle, but the findings it uncovers, server-side request forgery, misconfigured CORS headers, exposed admin endpoints, are often impossible for SAST to detect. Running OWASP ZAP in headless mode as a pipeline step after each staging deployment is a practical starting point.

IAST sits alongside your existing QA automation. If your team runs a suite of Selenium or Playwright tests against a staging environment, an IAST agent passively instruments every request those tests generate. You get security findings without writing a single additional test.

Software Supply Chain Risk and SBOM Requirements

The OWASP Top 10 2021 added A06:2021 Vulnerable and Outdated Components as a named category precisely because dependency risk had become systemic, not incidental. The Log4Shell incident in late 2021 demonstrated that a single transitive dependency buried four levels deep in a Java application could expose critical infrastructure worldwide within hours of disclosure.

Managing this risk starts with knowing what you have. A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in your application, including direct dependencies, transitive dependencies, and their respective version numbers and licences. The two dominant SBOM formats are CycloneDX, which is OWASP-backed and tool-native, and SPDX, which originated as an ISO standard (ISO/IEC 5962:2021) and is common in regulated industries.

Generating an SBOM should be a build artefact, not a one-time manual export. Emit a CycloneDX or SPDX document as part of every CI pipeline run, immediately after the build step that resolves dependencies, and store it alongside the container image in your artefact registry. Trivy produces CycloneDX or SPDX output from container images in a single command; for language-level manifests, Syft covers ecosystems including npm, pip, and Maven. Each stored SBOM is tied to the specific release it describes, so when a new CVE is disclosed six months after a release shipped, you can query every stored SBOM in seconds to identify which deployed versions are affected. Your SCA tooling then watches the full SBOM inventory continuously against NVD and OSV.dev feeds, generating an alert the moment a new vulnerability matches a component already running in production, giving your security team a head start before an attacker runs the same enumeration externally.

The SLSA framework (Supply-chain Levels for Software Artefacts) takes this further by defining build integrity requirements, specifically whether your build system is hermetic, whether artefacts are signed, and whether provenance is auditable. SLSA Level 2 is achievable for most teams using GitHub Actions or similar with signed releases; Level 3 adds hardened build environments and is increasingly expected by enterprise procurement teams and government buyers as of 2026.

Triage and Deduplication: Keeping the Finding Volume Manageable

Running four scanning tools against a mature codebase produces a lot of findings. On projects I have worked on, a first-run SAST scan against a legacy Java service commonly returns three hundred or more findings, of which perhaps forty require immediate attention and the rest are either false positives, accepted risks, or low-severity issues that belong in a backlog rather than a sprint. The challenge is not running the scans; it is preventing the result from demoralising the team or being quietly ignored.

Deduplication is the first problem. SAST and DAST may both flag the same underlying injection vulnerability, one from the code path and one from the HTTP response. Without a correlation layer, a developer sees two tickets for a single fix. Modern application security posture management (ASPM) platforms, and some enterprise-tier SAST vendors, map findings to a common identifier, typically a CVE number or CWE category, and collapse duplicates before they reach the developer queue.

Prioritisation comes next. The raw CVSS score from NVD is a starting point, not a final answer. A CVSS 9.8 in a library used only in an internal batch job with no network exposure is a lower operational priority than a CVSS 6.5 in a public-facing authentication endpoint. Effective triage has three inputs. First, reachability analysis: is the vulnerable function actually called by your application’s execution paths, or does the package exist in your dependency graph but never load at runtime? Tools like Snyk can distinguish a direct, reachable import from a transitive dependency compiled out of the final binary. Second, exposure context: an internet-facing API endpoint that processes untrusted input demands faster remediation than an identical flaw behind a VPN. Third, exploit maturity: a vulnerability with a published, weaponised proof-of-concept is categorically more urgent than one rated theoretical in the NVD record. Some SCA vendors surface a composite risk score that accounts for all three factors, giving teams a single, defensible number to prioritise against.

Velocity thresholds help teams maintain pace. Define a policy that says critical findings block deployment, high findings require a tracked ticket within 48 hours, and medium findings enter the sprint backlog within two weeks. Enforce this in the pipeline rather than relying on manual review.

Developer Workflow Integration: Fix Where Developers Work

Security findings that require developers to leave their normal workflow are findings that get deferred. The most effective programmes surface issues directly inside the tools developers already use: IDE plugins for SAST, PR comments for pipeline scan results, and GitHub or GitLab issues for SCA findings requiring dependency upgrades.

Semgrep, for instance, ships a VS Code extension that runs rules locally as you type. A developer writing a raw SQL query sees a warning before they have even saved the file. That feedback loop cannot be replicated by a weekly security report. Equally, Dependabot generates automated pull requests when a new patch version of a vulnerable dependency is published, so the fix path is a one-click merge rather than a manual package update task.

Training completes the loop. Tools catch patterns, but developers who understand why a pattern is dangerous write safer code by default. The OWASP Top 10 categories, specifically A03:2021 Injection, A02:2021 Cryptographic Failures, and A10:2021 Server-Side Request Forgery, are the high-frequency topics worth covering in your developer security training programme. A team that understands SSRF does not need a tool to catch every instance; they stop writing the vulnerable pattern in the first place.

Runtime Defence: Protection Beyond the Build Pipeline

Your pipeline catches the vulnerabilities you know about when the code ships. Runtime protection handles what gets through, including zero-day exploitation attempts against unpatched components and attacks against your application logic that no static analysis would flag.

Web Application Firewalls remain the standard first layer. A WAF inspects HTTP traffic and blocks known attack signatures, rate-limits suspicious request patterns, and can virtually patch a vulnerability while your team prepares a permanent fix. Virtual patching is particularly valuable for third-party or legacy applications where patching on short notice is not operationally feasible.

Runtime Application Self-Protection (RASP) goes further by instrumenting the application itself. A RASP agent sits inside the running process and terminates or alerts on dangerous operations in real time: a serialisation attack attempting to execute OS commands, for instance, gets blocked at the point of execution rather than at the network perimeter. RASP is not a replacement for fixing the vulnerability, but it closes the window between disclosure and patch deployment.

Container and Kubernetes environments add a further layer of runtime context. Tools like Falco monitor syscall-level behaviour and alert when a container does something outside its expected profile, writing to paths it should not touch, spawning unexpected child processes, or making unusual network connections. Pairing this with your vulnerability management lifecycle gives you a complete picture: known-vulnerability risk from SCA, unknown behavioural anomalies from runtime monitoring.

Vulnerability Density and What a Realistic Programme Looks Like

Most engineering organisations dramatically underestimate their true vulnerability density before running a full programme. A 2024 analysis by Veracode of enterprise Java applications found an average of 1.2 high or critical vulnerabilities per thousand lines of code across direct and transitive dependencies, and that figure rises sharply in applications that have not had a systematic dependency update policy.

The practical implication: do not try to remediate everything at once on day one. A staged approach produces better coverage per unit of effort. Start with SCA because one scan across your dependency manifests and container images surfaces risk across hundreds of components simultaneously, generating SBOMs and establishing a dependency update cadence in the same pass. Once SCA findings are triaged and a policy for critical CVEs is set, introduce SAST tuned to the OWASP Top 10 categories most relevant to your stack: A03 Injection, A02 Cryptographic Failures, and A10 Server-Side Request Forgery cover the majority of high-frequency code-level findings. Run SAST as a non-blocking scan first to build a baseline without halting deployments, then promote critical findings to blocking once false-positive rates are calibrated. DAST follows last, initially as a report-only scan against critical flows in staging, then graduating to a deployment gate on your highest-risk endpoints.

Connect this work to your broader automated penetration testing cadence. Automated pen testing validates that your defences hold against real attack chains, not just individual vulnerability checks. The two disciplines are complementary: AppSec scanning finds the individual weaknesses, automated pen testing proves whether an attacker can chain them into a meaningful breach path. Running both gives your team and your board a defensible, evidence-based security posture.

Application Vulnerability Management: Common Questions

What is application vulnerability management?

Application vulnerability management is the structured process of identifying, assessing, prioritising, and remediating security weaknesses across your application code, open-source dependencies, and runtime environment. It combines static analysis, dynamic testing, and supply chain scanning to reduce exploitable risk before attackers find it first.

What is the difference between SAST and DAST?

SAST analyses your source or compiled code without running the application, catching logic flaws and injection patterns at build time. DAST sends real requests to a running application and tests its responses, finding runtime issues like authentication bypasses and misconfigurations that no static analysis can confirm without live execution.

What is an SBOM?

An SBOM, or Software Bill of Materials, is a machine-readable inventory listing every component inside your application: direct libraries, transitive dependencies, their versions, and licences. The two standard formats are CycloneDX and SPDX. Regulatory bodies and enterprise buyers increasingly require SBOMs as a baseline supply chain security assurance.

How do you manage open-source vulnerabilities?

Start by running SCA tooling such as Trivy or Dependabot against all your dependency manifests and container images. Generate SBOMs so you have a full component inventory. Set automated alerts for new CVEs against your known components, establish remediation SLAs by severity, and use automated pull requests to reduce the friction of applying patches.