Application Security Guide: SAST, DAST, SCA and IAST

Most organisations own several application security scanners and still ship the same classes of vulnerability release after release, because tools without a programme produce findings, not fixes. Application security (AppSec) is the set of practices that keeps flaws out of software and gets the remaining ones fixed: secure design, testing at the right stage, triage, remediation SLAs and developer enablement. This guide covers the secure software development lifecycle using NIST SSDF (SP 800-218), threat modelling, OWASP SAMM, BSIMM and ASVS, how SAST, DAST, IAST, SCA, secrets scanning and RASP fit together, triage and metrics, security champions, and the impact of AI coding assistants. It is for AppSec leads, engineering managers and security architects building or reviewing a programme. Dependency, build provenance and pipeline identity topics are covered in the linked guides.

Key takeaways

• Start from a framework, not a tool. NIST SSDF defines what a secure SDLC must do; OWASP SAMM or BSIMM measures how well you do it; ASVS defines what "secure" means for a given application.
• Each testing type sees a different slice. SAST reads code, DAST attacks the running app, IAST watches it from inside, SCA inventories components and secrets scanning finds credentials; none finds business logic flaws on its own.
• Triage capacity is the real constraint. Gate only on high-confidence, high-impact findings, deduplicate across tools and set remediation SLAs by severity and exposure.
• Design flaws are cheapest to fix before code exists. Threat model new features and trust boundary changes; scanners cannot find a missing control that was never designed.
• AI coding assistants raise volume and change the threat model. More code, faster, written partly by a tool that can be prompt-injected and that holds credentials, needs the same gates plus controls on the agent itself.

The secure SDLC: what NIST SSDF asks for

NIST SP 800-218 (SSDF version 1.1, February 2022) does not replace your SDLC. It is a set of high-level practices to integrate into whatever lifecycle teams already use, and it gives buyers and suppliers a common vocabulary; US federal software attestation builds on it. The four practice groups map directly to programme workstreams:

CISA's Secure by Design work sets the outcome: the security of customers should be "a core business requirement, not just a technical feature", and products should be secure by default, for example with MFA and intrusion logging available without extra configuration or cost.

Secure design: requirements and threat modelling

• Set a verification level per application: OWASP ASVS 5.0.0 defines testable requirements at three levels of increasing rigour. Use L1 as the floor for everything, L2 for applications handling sensitive or personal data, and L3 for the most critical systems. Cite requirements in version-qualified form (for example v5.0.0-1.2.5) because identifiers change between versions.
• Threat model early and keep it current: the OWASP threat modelling cheat sheet frames the work as four questions: "What are we working on?", "What can go wrong?", "What are we going to do about it?" and "Did we do a good enough job?". Draw a data flow diagram that shows trust boundaries, which "often represent possible attack points".
• Use STRIDE as the prompt list: spoofing (authentication), tampering (integrity), repudiation (accountability), information disclosure (confidentiality), denial of service (availability) and elevation of privilege (authorisation). Add LINDDUN for privacy, and attack trees or abuse cases for business logic.
• Know when to trigger a model: new internet-facing services, new trust boundaries (a third-party integration, a new identity provider, an AI agent with tool access), authentication or payment changes, and new sensitive data stores. Small changes inside an existing boundary need a checklist, not a workshop. For agent features, see the AI Agent Threat Modelling Guide.
• Turn threats into tickets: each mitigation becomes a backlog item with an ASVS reference and a test.
• Use the current lists for awareness, not as a programme: the OWASP Top 10:2025 leads with A01 Broken Access Control, A02 Security Misconfiguration and A03 Software Supply Chain Failures; the 2025 CWE Top 25 is led by CWE-79 (cross-site scripting), CWE-89 (SQL injection), CWE-352 (CSRF) and CWE-862 (missing authorisation). Both are good inputs to secure coding training and SAST rule tuning.

The testing toolbox: SAST, DAST, IAST, SCA, secrets scanning and RASP

Each technique, from code scanning to runtime protection, looks at a different artefact at a different time. Coverage comes from combining them, not from buying the "best" one; NIST's Static Analysis Tool Exposition (SATE) states that its purpose is "NOT to evaluate nor choose the "best" tools", because tools have different strengths.

Decision guidance

• SAST or DAST first: SAST first when you control the source and want feedback in pull requests; DAST first for legacy or third-party applications without source, or when the main risk is configuration. Most programmes need both within a year.
• When IAST is worth it: when you have strong automated functional tests and a few dominant languages. IAST only sees code your tests exercise, so poor test coverage means poor IAST coverage.
• RASP is a compensating control: use it for legacy applications that cannot be fixed quickly or to buy time on a critical finding, not as a substitute for remediation.
• Scan production or QA with DAST: run active scans against a production-like test environment. The OWASP ZAP documentation warns that active scanning is a real attack and "actual damage can be done to a site's functionality, data, etc."; it creates records, sends emails and triggers workflows. In production, limit DAST to passive or safe checks with change approval and a test account.
• Authenticated scanning: configure authentication so the scanner reaches pages behind login, and use two accounts with different roles; otherwise DAST tests only the login page. Modern JavaScript applications need browser-driven crawling; ZAP notes its older AJAX spider is "no longer recommended in most cases" in favour of its client spider.
• Business logic flaws: no scanner reliably finds them. Use abuse-case tests written from the threat model, authorisation tests with multiple users, and manual testing.
• Small and large organisations: a small team can cover most ground with open source SAST, SCA and secrets scanning in CI plus an annual penetration test. Large estates with many scanners usually need an application security posture management (ASPM) layer to deduplicate findings and route them to owners; the trade-offs are covered in the Open Source Security Guide.

Where each control runs in the pipeline

Pipeline hardening and the credentials CI jobs hold are covered in the CI/CD Pipeline Identity Security Guide.

Triage, false positives and remediation SLAs

A scanner that blocks builds on noise gets switched off. SAST false positives are the most common complaint, and the answer is tuning and scoping, not abandoning static analysis.

• Start in audit mode: run new rules or tools without blocking for two to four weeks, measure the false positive rate per rule, disable or rewrite noisy rules, then enforce.
• Gate on new findings in changed code: legacy findings go to a backlog with SLAs, so delivery is not stopped by debt that predates the tool.
• Deduplicate across tools: the same injection may appear in SAST, DAST and IAST. Correlate by CWE and location so developers get one ticket.
• Record triage decisions: "false positive" and "accepted risk" need a reason, an approver and an expiry, mirroring the bypass reasons GitHub records for push protection ("It's used in tests", "It's a false positive", "I'll fix it later").
• Route to owners automatically: map repositories to teams so findings land in the team's own tracker, not in a security queue.
• Prioritise by exploitability and exposure: a reachable injection in an internet-facing service ranks above a theoretical issue in an internal batch job. See the Vulnerability Management Guide.

These SLA values are an example starting point, not a standard; set your own with risk owners and publish them in the AppSec policy.

Security champions and developer enablement

An AppSec team rarely exceeds a small fraction of engineering headcount, so scale comes from developers. The OWASP Security Champions Guide sets out ten principles, including "Secure management support", "Nominate a dedicated captain", "Reward responsibility" and "Anticipate personnel changes", and notes that "One size will not fit all".

• Selection and time: one volunteer per team or service area, with a protected allocation (often a few hours a week) agreed with their manager, or the role lapses at the first deadline.
• Responsibilities: first-line triage of findings, joining threat models, reviewing security-relevant changes and passing on guidance.
• Enablement: SSDF PO.2.2 calls for role-based training; give champions deeper training, a channel to the AppSec team and recognition in performance reviews.
• Paved roads: secure defaults in frameworks and templates (authentication middleware, parameterised data access, output encoding, secret retrieval from a vault) prevent whole classes of bugs, which is what RV.3.3 aims for.

Measuring maturity: SAMM, BSIMM and metrics

Both measure software security assurance at programme level. Many organisations assess with SAMM (Software Assurance Maturity Model) to plan and use BSIMM (Building Security In Maturity Model) data to justify investment. Re-assess yearly. Signs of a mature programme include threat models for most new features, gates that developers trust, findings fixed within SLA without escalation, root cause analysis that removes vulnerability classes, and AppSec metrics reported alongside delivery metrics.

Metrics that show the programme is working:

• Coverage: share of production applications with SAST, SCA, secrets scanning and authenticated DAST running, weighted by criticality.
• Mean time to remediate confirmed critical and high findings, and SLA attainment by team.
• Escape rate: vulnerabilities found in production (penetration tests, bug reports, incidents) per release, against those caught before release.
• Recurrence: repeat findings of the same CWE in the same codebase; falling numbers show root cause work is effective.
• False positive rate per rule and the share of findings developers dismiss.
• Design coverage: share of qualifying changes with a threat model.

AI coding assistants and agents

AI coding assistants raise the volume of code and pull requests, and AI-generated code can contain the same injection, authorisation and secrets flaws as human code while looking plausible to a reviewer. Coding agents also read untrusted content, run commands and hold tokens.

• Keep gates tool-agnostic: the same SAST, SCA, secrets and review rules apply whoever wrote the code; label AI-assisted pull requests if you want to measure their findings rate.
• Watch dependency suggestions: assistants can suggest packages that do not exist or are outdated; dependency admission controls from the Open Source Security Guide apply.
• Constrain the agent's identity: scope its repository and cloud tokens and keep secrets out of its context. The Amazon Q Developer extension compromise showed an over-scoped GitHub token shipping a malicious prompt to an AI coding agent. See the AI Coding Agents Security Guide.

Where identity fits: secrets in code and tool credentials

• Secrets in source: enable push protection or pre-commit scanning, restrict who can bypass, and revoke (not just delete) any secret that reached a repository. The Sourcegraph breach began with a site-admin token leaked in a commit. See the Secrets Management Guide.
• Scanner credentials are privileged NHIs: DAST test accounts, SAST tokens with read access to every repository and ASPM integrations need owners, least privilege, vaulting and rotation.
• Authentication and authorisation flaws dominate: broken access control tops the OWASP Top 10:2025, so identity design belongs in threat models. See the Authorisation Models Guide.

Implementing an AppSec programme

1. Baseline (month 1): inventory applications with owners, criticality and ASVS target level; run a SAMM self-assessment; publish an AppSec policy with SLAs.
2. Quick wins (months 1 to 3): secrets push protection and SCA on all repositories; revoke exposed secrets found in history.
3. SAST in audit mode (months 2 to 4): deploy to a pilot ring of three to five teams, tune rules, then enable pull request gates on new critical findings. Rollback is switching the gate back to advisory, not removing the scan.
4. Champions and threat modelling (months 3 to 6): recruit champions, train them, and require threat models for the triggers above.
5. Dynamic testing (months 4 to 9): authenticated DAST against staging for internet-facing applications, IAST where test suites are strong, and penetration testing for critical applications.
6. Consolidate and measure (months 6 to 12): correlate findings, route them to owners, report the metrics above monthly and re-assess with SAMM.

Common failure patterns

• Buying scanners before defining triage: thousands of untriaged findings, no owners, and a tool that is switched off within a year.
• Blocking builds on legacy debt: developers learn to bypass the gate; gate on new findings and burn down the backlog separately.
• Unauthenticated DAST: reports a clean login page while every endpoint behind it goes untested. In the McKinsey AI platform hack, an autonomous agent found SQL injection in unauthenticated APIs, a flaw class every testing layer should catch.
• Deleting rather than revoking leaked secrets: the secret lives on in history, forks and clones. The Toyota T-Connect key exposure left an access key on public GitHub for five years.
• Champions without time: a named champion with no allocation is a mailing list, not a programme.
• No root cause work: fixing the same CWE ticket by ticket instead of fixing the framework or template that produces it.

Framework mapping

Practitioner checklist

• Inventory applications with owner, criticality and an ASVS target level.
• Publish an AppSec policy mapped to NIST SSDF, with remediation SLAs by severity and exposure.
• Enable secrets push protection and SCA on every repository, and restrict who can bypass.
• Run SAST in audit mode, tune rules, then gate pull requests on new high-confidence critical findings.
• Run authenticated DAST against production-like environments, with two roles, and passive checks only in production.
• Threat model new services, trust boundary changes and AI agent features using the four questions and STRIDE.
• Appoint security champions with protected time and a dedicated captain.
• Deduplicate findings across tools and route them to owning teams automatically.
• Apply the same gates to AI-generated code and scope the credentials of coding agents.
• Assess with OWASP SAMM yearly and report coverage, MTTR, escape rate and recurrence monthly.

Standards and references

• NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
• OWASP: Software Assurance Maturity Model (SAMM) 2.0
• OWASP: Application Security Verification Standard (ASVS)
• OWASP: Top 10:2025
• OWASP: Threat Modeling Cheat Sheet
• OWASP: Security Champions Guide
• CISA: Secure by Design
• NIST: Static Analysis Tool Exposition (SATE)

Related NHI Mgmt Group resources: Open Source Security Guide · SLSA and Build Provenance Guide · CI/CD Pipeline Identity Security Guide · AI Coding Agents Security Guide · Vulnerability Management Guide