DevSecOps Pipeline Vocabulary: SAST, DAST, and Shift-Left Security Language

Security in the Pipeline: A Growing Vocabulary

DevSecOps — the integration of security practices into the DevOps pipeline — has generated a rich set of vocabulary that security engineers, developers, and operations teams all need to understand. Security scanning, vulnerability management, and supply chain security are no longer the sole domain of the security team; they are embedded in every pull request and deployment pipeline. This guide covers the core terms.

Static and Dynamic Analysis

SAST (Static Application Security Testing)

SAST analyses source code or compiled binaries without executing the application. It examines code structure, data flows, and known vulnerability patterns to identify potential security issues.

“SAST runs on every pull request and flags potential SQL injection patterns in the new query builder before the code reaches review.”

SAST tools are language-specific — a tool for Java will not analyse Python. Common SAST tools include Semgrep, SonarQube, CodeQL, and Checkmarx.

True positive — a SAST finding that represents a real vulnerability. False positive — a SAST finding that flags safe code as vulnerable. “We tuned the Semgrep ruleset to reduce false positives in our test files, where simulated attack patterns were triggering security rules incorrectly.”

DAST (Dynamic Application Security Testing)

DAST tests a running application by sending it inputs and observing its responses, looking for vulnerabilities that manifest at runtime — such as injection flaws, authentication bypasses, or insecure headers.

“We run the OWASP ZAP DAST scan against the staging environment on every release candidate before promotion to production.”

DAST does not require access to source code, which makes it useful for testing third-party components or black-box systems.

IAST (Interactive Application Security Testing)

IAST uses agents or instrumentation inside the running application to monitor its behaviour during test execution. It combines aspects of SAST (code awareness) and DAST (runtime observation).

Dependency and Supply Chain Security

SCA (Software Composition Analysis)

SCA analyses a project’s third-party dependencies to identify known vulnerabilities, licence compliance issues, and outdated packages. It is the primary tool for managing open-source risk.

“SCA discovered that the logging library we inherited from the legacy codebase had a known critical vulnerability — it had been patched three months earlier but we hadn’t updated the dependency.”

CVE (Common Vulnerabilities and Exposures) — a standardised identifier for publicly known security vulnerabilities. “The SCA scan flagged CVE-2024-XXXXX in the HTTP client library — we need to upgrade to version 4.2.1 or above.”

CVSS score — a numerical score (0–10) indicating the severity of a vulnerability. “The finding has a CVSS score of 9.8, which is classified as Critical — remediation is required before the next deployment.”

SBOM (Software Bill of Materials)

An SBOM is a comprehensive, machine-readable inventory of all software components in a system — direct dependencies, transitive dependencies, and their versions and licences.

“We generate an SBOM as part of the release pipeline and store it alongside the build artefact. In the event of a supply chain incident, we can immediately query which of our products are affected.”

Supply Chain Security

Software supply chain security encompasses the practices and tools used to verify the integrity and trustworthiness of the code, tools, and infrastructure used to build software.

SLSA (Supply-chain Levels for Software Artefacts) — a framework of security levels for software supply chain integrity, with four progressive levels. “Our current CI configuration achieves SLSA Level 2, meaning builds are scripted and artefacts include provenance metadata.”

Provenance — verifiable metadata describing how a software artefact was built — what source code, tools, and environment were used. “Signed provenance attestations allow downstream consumers to verify that our release artefacts were built in a trusted CI environment.”

Shift-Left Security

Shift-left security is the principle of moving security testing and review earlier in the development lifecycle — towards the developer’s workstation and pull request stage, rather than waiting for a dedicated pre-release security review.

“By shifting security left with automated SAST and SCA in the IDE and CI pipeline, we catch the majority of issues during development rather than in the security review gate — where fixes are far more expensive.”

Security champion — a developer within an engineering team who has additional security knowledge and advocates for secure development practices within their team.

Threat modelling — a structured process for identifying potential threats, attack vectors, and mitigations for a system during the design phase. Shifting threat modelling left means doing it during architecture design rather than after implementation.

Security Gate Language

A security gate is a point in the CI/CD pipeline where the build is stopped or blocked if security criteria are not met.

“The security gate in our pipeline blocks promotion to staging if any Critical or High CVSS findings are present in the SCA or SAST results.”

Policy as code — expressing security and compliance policies as machine-readable code that can be version-controlled and enforced automatically. “We use OPA (Open Policy Agent) policies as code to enforce security gate criteria consistently across all pipelines.”

Waiver / exception — a documented, approved decision to proceed despite a failing security finding, typically for a defined period. “The team submitted a waiver for the medium-severity finding in the legacy module because it is not exposed to user input — the waiver expires in 90 days and requires a compensating control.”

Five Example Sentences

1. “The SAST scan on the pull request flagged a potential path traversal vulnerability in the file upload handler — we added input validation before the code was merged.”
2. “Our SCA pipeline detected a transitive dependency with a critical CVE score of 9.1; we escalated to the team immediately and patched the dependency within four hours.”
3. “Shifting security left has meant that our quarterly penetration test now finds significantly fewer issues, because the easy wins are caught automatically in the CI pipeline.”
4. “We generate and sign an SBOM for every release artefact, which allows us to respond to supply chain incidents like Log4Shell within hours rather than days.”
5. “The security gate policy blocks production deployment of any image containing a Critical vulnerability unless an approved waiver is on record in the exception register.”

A Word on Communication

Security findings can create tension between security engineers and development teams. When writing or discussing findings in English, be precise and objective. Avoid alarmist language. State the finding, the evidence, the risk, and the remediation clearly. “This endpoint accepts unsanitised user input that is passed directly to a SQL query, which enables SQL injection attacks against the database” is more useful and less inflammatory than “this code is dangerously insecure.”