Application vulnerability scanning – DAST, SAST, SCA, IaC and containers: what each method finds and where scanning ends and penetration testing begins

What is application vulnerability scanning? Application vulnerability scanning is a family of automated methods for finding flaws in software an organisation builds or deploys: DAST probes a running application from outside, SAST analyses source code, SCA checks third-party libraries, and IaC and container scans inspect infrastructure definitions and images.

Each method sees a different layer and a different class of defect, so a mature programme combines several in the CI/CD pipeline. Infrastructure scanning (hosts, network, ASV) is covered in a separate asset – Infrastructure vulnerability scanning; this article deals only with the application layer.

Canonical definition: Application vulnerability scanning is the automated analysis of software – its code, dependencies, deployment artefacts or running instance – to detect known classes of security defects before they are exploited.

Application vulnerability scanning – key takeaways:

1. DAST tests the running application like an attacker (no code), SAST reads source code, SCA identifies vulnerable libraries – three methods, three disjoint sets of detectable defects.
2. PCI DSS v4.0.1 requires from 31 March 2025 an inventory of software components (6.3.2) and an automated technical solution protecting public-facing web applications (6.4.2).
3. DORA (RTS 2024/1774, Article 10) requires tracking of third-party libraries, including open source, in services supporting critical functions; the Cyber Resilience Act requires manufacturers to maintain an SBOM and a vulnerability handling process.
4. No scanner finds business-logic flaws, object-level authorisation errors (IDOR/BOLA) or vulnerability chains – that is the domain of penetration testing.
5. Application scans should run in the CI/CD pipeline with deployment-blocking thresholds, not as a quarterly report.
6. Patronusec combines application scanning with web application and API penetration testing to OWASP ASVS, delivering reports acceptable for PCI DSS and DORA assessments.

---

---

What types of application vulnerability scan exist, and what does each detect?

The five core application scan types are DAST (dynamic analysis of the running application), SAST (static code analysis), SCA (software composition analysis of dependencies), IaC scanning (infrastructure templates) and container/image scanning. IAST (an agent inside the test application) and secret scanning complement them. Each operates at a different stage of the lifecycle and detects a different class of defect.

Method	What it analyses	Where in the lifecycle	Typical findings	What it cannot see
SAST	source code or bytecode, without execution	commit, pull request	SQL injection, XSS, unsafe functions, hard-coded secrets, validation errors	environment misconfiguration, library vulnerabilities, runtime-only issues
SCA	dependency manifests, lockfiles, artefacts	build	known CVEs in libraries, licences, outdated versions, missing signatures	flaws in your own code; whether the vulnerable function is ever called
IaC scan	Terraform, CloudFormation, Helm, Kubernetes YAML, Dockerfile	pull request, plan	open security groups, missing encryption, wildcard permissions, containers as root	actual cloud state (configuration drift)
Container scan	images (layers, OS packages, libraries), registry	build, registry push, runtime	CVEs in base packages, secrets in layers, no non-root user	application vulnerabilities in the image, orchestration errors
DAST	running application over HTTP, no code	staging, production	reflected XSS, header issues, information disclosure, some injections, weak TLS	business logic, authorisation flaws, functions behind complex authentication, APIs without a specification
IAST	instrumented application during tests	integration tests	SAST- and DAST-type findings with fewer false positives	paths not covered by tests
Secret scan	repository and git history	commit, periodic	API keys, passwords, tokens in code and history	secrets shared outside the repository

DAST (Dynamic Application Security Testing) tests a running application from the perspective of an external user without access to code, whereas SAST (Static Application Security Testing) analyses source code without executing it – the two methods detect disjoint classes of defects.

The most important consequence of this table: there is no single application scanner. An organisation with a “web application scanner” (DAST) that considers the topic closed cannot see vulnerable libraries (SCA), hard-coded secrets (SAST, secret scanning) or misconfigured containers. For an overview of all test methods in a security programme, see IT security testing methods.

In practice, that means at least three scans for every internally developed application: SAST and SCA at build time and DAST on the test environment – plus container scanning if it runs on Kubernetes.

Why have SCA and SBOM become regulatory requirements rather than good practice?

SCA and SBOM became requirements because vulnerabilities in third-party components – Log4Shell (CVE-2021-44228) and the run of incidents in npm and NuGet packages – showed that organisations did not know what they were running in production. PCI DSS 6.3.2, DORA RTS Article 10(2)(d) and the Cyber Resilience Act (Annex I Part II) now require component inventories and vulnerability tracking.

Three requirements that move SCA from “good practice” to “obligation”:

• PCI DSS v4.0.1, requirement 6.3.2 (mandatory from 31 Mar 2025): maintain an inventory of bespoke and custom software, including third-party components, to facilitate vulnerability and patch management. In practice – an SBOM for every application in CDE scope.
• DORA, RTS 2024/1774, Article 10(2)(d): track the use of third-party libraries, including open source, in ICT services supporting critical or important functions, and monitor their versions and updates, where appropriate together with the ICT provider.
• Cyber Resilience Act, Annex I Part II: manufacturers of products with digital elements identify and document components, including drawing up an SBOM in a commonly used machine-readable format covering at least top-level dependencies, and address vulnerabilities without delay. The obligation to report actively exploited vulnerabilities applies from 11 Sep 2026 – see Cyber Resilience Act obligations and deadlines.

An SBOM (Software Bill of Materials) is a machine-readable list of software components with their versions and dependencies, required by the Cyber Resilience Act from manufacturers of products with digital elements and indirectly by PCI DSS 6.3.2 and DORA RTS Article 10.

Two SBOM formats dominate: CycloneDX (OWASP) and SPDX (Linux Foundation, standardised as ISO/IEC 5962:2021). SCA tools generate them automatically at build time; the challenge is not generating an SBOM but maintaining one for every version deployed to production and linking it to the process for responding to new CVEs.

In practice, when the next “Log4Shell” appears, an organisation with a current SBOM answers “does this affect us?” in minutes; one without an SBOM answers in days, after searching repositories and servers.

How does DAST work, and why does it not replace an application penetration test?

DAST sends crafted HTTP requests to a running application and analyses responses for error signatures: reflected XSS, database error messages, missing headers, exposed files. It does not understand the application’s logic, does not know who should access which resource, and usually cannot get past multi-step authentication – which is why it finds a fraction of what a penetration tester finds.

Classes of defect DAST will not find, or finds only sporadically:

1. Authorisation flaws (IDOR, BOLA in APIs) – the scanner does not know that user A should not see user B’s order.
2. Business logic – a discount applied twice, a skipped verification step, a negative quantity in the basket.
3. Vulnerability chains – information disclosure + weak password reset + no rate limiting = account takeover; each element alone is low priority.
4. Functions behind complex authentication – MFA, SSO and short-lived session tokens stop the scanner at the login page.
5. APIs without a specification – without OpenAPI/Swagger the scanner does not know the endpoints and parameters.
6. Identity and session attacks – JWT manipulation, race conditions, OAuth flaws.

An application penetration test differs from a DAST scan in that the tester understands the application’s permission model and business logic, verifies every finding manually and chains individual weaknesses into a realistic attack path.

The reference for manual test scope is OWASP ASVS (Application Security Verification Standard) version 5.0 (2025) – a list of verification requirements in three levels, of which automated scanners reliably cover only part of level 1. The OWASP Top 10 categories relating to access control and insecure design require manual verification.

DAST’s role differs from a pentest’s: it is a daily or weekly regression guard (did the latest deployment open a known class of flaw?), not an annual resilience assessment. PCI DSS requirement 11.4 (application pentest at least annually and after significant change) and DORA Article 25 distinguish the two. Patronusec delivers web application and API penetration testing to ASVS, treating the client’s DAST and SAST output as a starting point rather than a substitute.

In practice: DAST weekly on staging and after every deployment, a pentest annually and after significant functional change – both on the schedule, neither replacing the other.

How do you scan containers, images and infrastructure as code?

You scan containers at three points: the base image and Dockerfile in the pull request, the built image on publication to the registry (blocking images with critical CVEs), and running containers in the cluster (drift, new CVEs in old images). You scan infrastructure as code before applying the plan – Terraform, Helm and Kubernetes manifests – against CIS benchmarks and organisational policies.

Container scan layers and typical findings:

Layer	What you scan	Typical findings	Requirement
Dockerfile	build instructions	latest base image, no USER, secrets copied in, unnecessary packages	CIS Docker Benchmark
Image	OS packages and libraries in layers	CVEs in base packages (glibc, openssl), outdated base image	PCI DSS 6.3.1, DORA RTS Art. 10
Registry	admission policy	unsigned images, unscanned images, images older than X days	“only scanned and signed images reach production”
Runtime (cluster)	running containers and pod configuration	root containers, no limits, hostPath, privileged mode, new CVEs in running images	CIS Kubernetes Benchmark, PCI DSS 2.2

IaC scanning has one distinguishing feature: it finds the flaw before the resource exists. A world-open security group or an unencrypted bucket stopped at terraform plan never becomes an incident. Its limitation is drift: what is defined in code is not necessarily what runs in the cloud after manual changes – hence IaC scanning is complemented by scanning actual state (CSPM).

Container scanning covers three moments – the image definition in code, the built artefact in the registry and the running instance in the cluster – because a vulnerability can appear at any of those stages, including in an image that was clean when published.

PCI DSS in container environments has additional specifics – CDE scope, segmentation between pods and evidence for the assessor – covered in PCI DSS in containerised environments.

In practice, a policy of “no image with a critical CVE reaches the production registry”, enforced in the CI/CD pipeline, replaces hundreds of pages of procedure – and is the evidence an assessor will check in the pipeline configuration, not in a document.

How do you wire application scans into CI/CD so they block rather than merely report?

You wire application scans into the pipeline as quality gates: SAST and secret scanning in the pull request, SCA and image scanning at build, IaC scanning before the plan is applied, DAST after deployment to the test environment. Each gate has a blocking threshold (e.g. no new critical or high vulnerabilities with an available fix) and an exception process with an owner and expiry date.

Pipeline with gates:

1. Pre-commit / pull request: secret scanning (unconditional block), SAST with language-specific rules (block on critical), code review.
2. Build: SCA – block on critical and high CVEs with an available fix; generate the SBOM and store it as a versioned artefact.
3. Artefact: container image scan – block on critical; sign the image.
4. Infrastructure: IaC scan on plan – block on policy violations (public access, no encryption, excessive permissions).
5. Deploy to test: authenticated DAST – report, block on selected classes (e.g. injections).
6. Production: continuous runtime container scanning and CSPM; re-run SCA against the SBOM whenever a new CVE is published.

Three rules without which gates get ignored:

• “New vs existing” threshold – the gate blocks only new vulnerabilities introduced by the change; historical debt goes to a separate plan, otherwise the first run blocks everything for months.
• Exceptions with expiry – every “accepted” has an owner, justification and re-assessment date; open-ended exceptions are a hole in the process.
• Scan duration – SAST over 10 minutes in a pull request will be switched off by developers; run full scans overnight and incremental scans in PRs.

A security quality gate in a CI/CD pipeline is an automated threshold that halts deployment when a scan detects a vulnerability above an agreed level – as distinct from a reporting scan, whose results do not affect the deployment flow.

PCI DSS v4.0.1 requirement 6.4.2 (mandatory from 31 Mar 2025) requires, for public-facing web applications, an automated technical solution that detects and prevents attacks (e.g. a WAF) – a runtime protection layer independent of scanning but fed by its results (virtual patching until a fix ships).

Patronusec Insight: In our project experience, assessors – QSAs and ISO 27001 auditors alike – increasingly ask for evidence in the form of pipeline configuration and gate execution history rather than a procedure in Word. Three things worth having ready: the blocking-threshold policy (what blocks, what only reports), the exception register with dates, and an SBOM tied to the specific version in production. During application penetration testing, Patronusec also reviews the client’s pipeline configuration and identifies which vulnerability classes from the pentest report should become SAST or DAST rules so they do not return in the next test.

How much does application scanning cost, and how do you choose between open-source and commercial tools?

Application scanning cost has three components: tool licences or subscriptions, team time for configuration and triage, and optionally an external service. Open-source tools cover all five scan categories with no licence cost but require more in-house effort; commercial platforms integrate results and reduce false positives for a subscription fee.

Category	Open-source examples	Commercial model	Indicative annual cost (20-50 developers)
SAST	Semgrep (open-source rules), CodeQL (free for open source), Bandit, SpotBugs	per developer or per repository	GBP 0 (OSS) to 12,000-20,000
SCA / SBOM	OWASP Dependency-Check, Trivy, Grype, Syft (SBOM), Dependency-Track	per developer or per project	GBP 0 to 8,000-10,000
IaC scan	Checkov, tfsec, KICS, Kubescape	usually bundled with a platform	GBP 0 to 6,000-10,000
Container scan	Trivy, Grype, Clair	per node or per image	GBP 0 to 8,000-10,000
DAST	OWASP ZAP, Nuclei (templates)	per application or per scan	GBP 0 to 6,000-15,000
External service (configuration + triage + reporting)	–	monthly retainer or project	GBP 6,000-20,000 per year

Selection criteria that matter more than licence price:

• False positives – a tool generating 80 % noise gets switched off; triage cost exceeds licence cost.
• Language and framework coverage – a Java SAST tool does not help a Go project; check coverage of your own stack.
• Pipeline and ticketing integration – a finding that does not become a ticket does not get fixed.
• Deduplication across tools – the same CVE reported by SCA, image scan and DAST is three tickets or one, depending on the platform.

The cost of an application scanning programme depends more on team time spent triaging false positives and maintaining rules than on tool licence prices – which is why signal quality is a more important selection criterion than the number of supported checks.

In practice, a 20-developer team can stand up a complete scan set on open-source tools in 2-4 weeks of one person’s effort, but without someone reviewing results weekly and maintaining rules, the programme dies within a quarter.

What do practitioners usually get wrong with application scanning?

The most common mistakes involve confusing methods, “report-only” mode, no plan for historical debt, and treating a clean scan as proof the application is secure.

❌ One scanner as “application security” – DAST cannot see libraries, SCA cannot see your own code, SAST cannot see configuration; PCI DSS 6.3.2 (component inventory) and 6.2.4 (code) address different layers.

❌ Report-only scanning without gates – results land on a dashboard nobody reads; the assessor will ask what happened to March’s critical finding.

❌ A first gate that blocks all historical debt – the pipeline stalls, the team disables the scanner; the threshold should apply to new vulnerabilities, with debt on a separate plan.

❌ Unauthenticated DAST – the scanner tests the login page and the footer; 90 % of functionality goes untested.

❌ An SBOM generated once and never updated – the SBOM must match the production version; otherwise “does the new CVE affect us?” is guesswork.

❌ Scanning as a substitute for penetration testing – a clean DAST and SAST report does not mean no IDOR, no logic flaws and no vulnerability chains; PCI DSS 11.4 and DORA Article 25 require a pentest regardless of scans.

Auditor’s checklist – what will a QSA or auditor check on application scanning?

1. Is there an inventory of bespoke and custom software listing third-party components (PCI DSS 6.3.2, DORA RTS Art. 10(2)(d))?
2. Is the SBOM generated automatically for every version and tied to the production deployment?
3. Do SAST, SCA and image-scan gates run in the CI/CD pipeline with documented thresholds?
4. Is there an exception register with owner, justification and expiry date?
5. Does DAST run authenticated and cover APIs (from an OpenAPI specification)?
6. Are component vulnerabilities fixed within the procedure’s timeframes (PCI DSS 6.3.3: critical and high within one month of patch release)?
7. Are public-facing web applications protected by an automated technical solution (PCI DSS 6.4.2)?
8. Are application pentest findings turned into scanner rules to prevent regression?
9. Do production container images come only from a registry with scanning and signing policies?
10. Have developers received secure coding training (PCI DSS 6.2.2)?

---

FAQ – application vulnerability scanning

---

Recommended reading

1. Infrastructure vulnerability scanning – the vulnerability scan definition hub; hosts, network, ASV, CVSS/EPSS/KEV prioritisation.
2. Vulnerability scanning and compliance requirements – mapping DORA, NIS2, CRA, PCI DSS, ISO 27001, SOC 2.
3. IT security testing methods – how application scans connect with penetration testing and red teaming.
4. PCI DSS in containerised environments – CDE scope, segmentation and audit evidence for Kubernetes.
5. CRA for software houses – manufacturer obligations, including SBOM and vulnerability handling.
6. Malicious NuGet package StripeAPI.NET – an example of supply-chain risk that SCA detects.

---

Application vulnerability scanning – consultation

Patronusec delivers web application and API penetration testing to OWASP ASVS and advises on configuring SAST, SCA and DAST gates in CI/CD pipelines so that results meet PCI DSS 6.x and DORA requirements. If you want to check whether your application scanning programme would pass an assessment, book a free call.

Penetration testing | Vulnerability scanning | PCI DSS certification