DevSecOps: How to Use SAST, DAST and SCA

DevSecOps builds security checks into every step of writing and releasing software instead of leaving them to the end. Automated tools inspect the code and the running system each time the team changes something. Three kinds of tools are used most: SAST (static application security testing) reads source code without running it, DAST (dynamic application security testing) probes a running application from outside the way an attacker would, and SCA (software composition analysis) checks the third-party libraries the software uses for known vulnerabilities. This article explains how the three differ, where they fit in the pipeline, and how to start without flooding the team with alerts.

DevSecOps in practice

Most development teams already have a CI/CD pipeline (an automated chain that builds, tests and releases software every time code changes). DevSecOps inserts security checks into that chain. In general, a flaw found while the code is being written is easier to fix than one found after the system is live. The idea is often called shift left, meaning the checks move toward the start of the work.

How SAST, DAST and SCA differ

The three tools look at software from different angles, so each answers a different question.

• SAST: inspects the source code the team wrote itself, without running the program. It works from the moment code is written and looks for vulnerabilities, programming errors and code that breaks coding standards.
• DAST: sends simulated attack input to a running application, like an attacker who cannot see the source code (black-box testing). It looks for flaws such as SQL injection and XSS (cross-site scripting), plus authentication problems and server misconfiguration. It does not need the source code.
• SCA: checks the open-source and third-party libraries the software calls, for publicly disclosed vulnerabilities and for the license each one carries.

No single tool covers everything. SCA finds only disclosed vulnerabilities in components it recognizes, and does not examine the code the team wrote. SAST cannot see how the system behaves when it runs, and some of its findings may not be real vulnerabilities (false positives), so a person has to triage them. DAST can test only an application that is running, and often cannot point to the line of code behind a problem. That is why organizations use them together.

Where each check fits in the pipeline

The arrangement below is a common pattern, not a requirement; teams adapt it to their tools and time. The idea is to put fast checks that do not need a running application early, and checks that need a running application after deployment to a test environment. The OWASP DevSecOps Guideline says automation can be added progressively and adapted to your own development process. Its basic-pipeline list puts SCA second, after repository secret scanning and ahead of SAST and DAST, without calling that a required order.

• While writing code: scan for passwords or tokens accidentally committed to the code (secrets scanning) before it reaches the shared repository.
• When code is submitted for review (a pull request is the request to merge code that the author sends to the team to review first): run SCA and SAST and show the results to the author right away.
• At build time: check the libraries again and generate a software bill of materials (SBOM, a list of the software's components) stored with the build output.
• During testing in a staging environment: run DAST against the deployed application, possibly on a nightly schedule.
• After going live: keep watching for new vulnerabilities in the libraries in use, because new ones are announced every day even when our own code has not changed.

Other checks in the same pipeline

The OWASP DevSecOps Guideline also covers other checks that can be added later.

• IaC scanning (infrastructure as code is the files used to build infrastructure automatically): checks files such as Terraform and Helm charts before they are used to create real systems.
• IAST (interactive application security testing): checks from inside the application while it runs and is being tested, because the sensor is embedded in the application.
• Software supply chain security: for example SBOMs, signing of build outputs, and securing the CI/CD pipeline. See SBOM and Software Supply Chain Security.
• API security: checks the APIs the application exposes, separately from its web pages.

Code written with AI help should pass the same checks as code written by people. See AI Coding Assistant Security and Vibe Coding Risks. The most common web application vulnerability types are summarized in OWASP Top 10 for Web Applications: A Summary.

Measuring maturity with reference frameworks

NIST SP 800-218, the SSDF (Secure Software Development Framework, a set of practices for developing software securely), groups its practices into four: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). Code review and software testing fall mainly under PW.

SSDF version 1.1 is final (February 2022). NIST released a draft of version 1.2 (SP 800-218 Rev. 1) on 17 December 2025 and closed comments on 30 January 2026. The SSDF publications page, checked on 27 October 2026, still listed 1.2 as a draft. Check the NIST website for the latest status before citing it.

OWASP SAMM (Software Assurance Maturity Model, a model for measuring how mature an organization's secure development is) helps an organization see where it stands and where to go next. It has 5 business functions, Governance, Design, Implementation, Verification and Operations, each with 3 practices, for 15 practices in all. Security Testing sits under Verification. The OWASP project page lists the latest version as 2.2.0.

Common mistakes

• Turning on every rule of the tool on day one: hundreds of findings flood the team and nobody reads them.
• Failing the build on every finding without ever trialing it: the team will find ways to switch the tool off instead of fixing problems.
• Treating every SAST finding as a real vulnerability: there is no triage step and nobody decides whether a finding is real.
• Using one kind of tool and assuming it covers everything: for example having SCA but no check of the code the team wrote.
• Scanning with no owner responsible for fixing: reports pile up with no assignee and no deadline.
• Scanning only before the final release: new vulnerabilities in the libraries in use can be announced after release.

Start today

• List the systems: note the applications the team builds, the languages used and each application's build pipeline.
• Start with SCA in report-only mode: show results without blocking builds, to see how many vulnerabilities the libraries in use carry.
• Scan for passwords and tokens in code: switch it on at the central code repository to catch secrets added by accident.
• Add SAST for new code first: choose the rules for serious vulnerabilities first, then widen.
• Set up DAST in a test environment: scan only systems the organization owns and is authorized to test.
• Agree the rules and the owners: which severity blocks a build, who triages, who fixes and within how many days. For prioritization, see the vulnerability management program.

To see where your software development and testing stand against common practice, try the self-assessment.

References and further reading

• NIST SP 800-218: SSDF Version 1.1: the final framework.
• NIST SP 800-218 Rev. 1 (SSDF 1.2) initial public draft: the December 2025 draft.
• NIST SSDF project page: the PO, PS, PW and RV practice groups.
• OWASP SAMM: overview and latest version.
• OWASP SAMM model: the 5 business functions and 15 practices.
• OWASP DevSecOps Guideline: overview of checks that can be added to a pipeline.
• OWASP DevSecOps Guideline: SAST: source code analysis.
• OWASP DevSecOps Guideline: DAST: testing a running application.
• OWASP DevSecOps Guideline: SCA: checking third-party libraries.