Verification and release gates
By the end of this module you will be able to:
- Distinguish SAST, DAST, and SCA and identify the appropriate pipeline stage for each
- Explain the SBOM formats SPDX and CycloneDX and identify where each is required
- Configure a CI/CD security gate that fails a build on critical severity findings
- Describe shift-left security and its practical implications for development teams
Apache Log4j CVE-2021-44228 (Log4Shell), December 2021
Log4Shell: when you do not know what is in your software
On 9 December 2021, a proof-of-concept exploit was published for CVE-2021-44228, a remote code execution vulnerability in Apache Log4j 2, the near-ubiquitous Java logging library. The vulnerability received a CVSS Base Score of 10.0. Within 72 hours, attackers were actively exploiting it against Apple iCloud, Microsoft, Twitter, and Cloudflare.
The fundamental problem for most organisations was not that they lacked a patch: it was that they did not know Log4j was in their systems. It arrived as a transitive dependency, a library their library depended on, without appearing in any manual inventory.
An SBOM (Software Bill of Materials) would have answered the question 'are we affected?' within seconds of the CVE being published. Organisations running software composition analysis in their CI pipeline received actionable build failures the same day the vulnerability was disclosed. Organisations without SCA spent days manually auditing Maven and Gradle dependency trees.
Shift-left security
Shift-left security moves security testing and validation earlier in the software development lifecycle, towards the design and coding phases, rather than performing security checks only at release or post-deployment. The name derives from the left-to-right representation of a development timeline.
A NIST study referenced in SP 800-218 found that fixing a defect in production costs approximately 30 times more than fixing it during the design or coding phase. In practice, shift-left means: threat modelling during sprint planning, not post-release; SAST running on every pull request, not weekly; SCA blocking dependency upgrades that introduce critical CVEs; and security unit tests covering authentication and authorisation boundaries.
With an understanding of shift-left security in place, the discussion can now turn to sast, dast, and sca, which builds directly on these foundations.
SAST, DAST, and SCA
SAST (Static Application Security Testing) analyses source code, bytecode, or binary without executing the programme. SAST tools traverse the code's abstract syntax tree and data flow to identify patterns associated with security vulnerabilities: SQL injection sinks, XSS output paths, and insecure cryptographic function calls. Representative tools: SonarQube (broad language support, quality gate integration), Semgrep (custom rule creation, fast PR scanning), Snyk Code (AI-assisted fix suggestions), and Checkmarx (enterprise compliance reporting).
SAST cannot detect runtime misconfigurations, authentication bypass via logical flaws, or infrastructure vulnerabilities. It also struggles with taint analysis across dynamic dispatch boundaries. Treat SAST as a continuous automated floor, not a complete security programme.
DAST (Dynamic Application Security Testing) tests a running application by sending crafted HTTP requests and analysing responses. DAST does not require source code access and observes the application from the outside, as an attacker would. It detects vulnerabilities that only manifest at runtime, including server-side misconfigurations and injection flaws not visible in static analysis. OWASP ZAP is the industry-standard open-source DAST tool, supporting active scanning (attack payloads), passive scanning (traffic analysis without injection), and API scanning via OpenAPI import. DAST is run against staging or pre-production, not production, as active scanning sends attack payloads.
SCA (Software Composition Analysis) automatically inspects a project's dependency manifest (package.json, requirements.txt, pom.xml) to identify open-source components, their versions, associated CVEs, and their licences. SCA detects both direct and transitive dependencies. The Log4Shell vulnerability was a transitive dependency: SCA tools scanning the full dependency graph would have flagged every instance of Log4j 2.x within seconds of the CVE being published. Representative SCA tools: Snyk Open Source, Dependabot (GitHub-native, free), OWASP Dependency-Check (open source), and JFrog Xray (commercial).
With an understanding of sast, dast, and sca in place, the discussion can now turn to sbom: software bill of materials, which builds directly on these foundations.
SBOM: Software Bill of Materials
An SBOM is a machine-readable inventory of all software components, libraries, and their versions within a software artefact. It makes it possible to answer "which of our products contain component X?" in response to a newly disclosed vulnerability, in seconds rather than days.
Two dominant formats: SPDX 2.3 (ISO/IEC 5962:2021, governed by the Linux Foundation, used for licence compliance and US Executive Order compliance) and CycloneDX 1.5 (OWASP, used for vulnerability management and supply chain security). The 2021 US Executive Order 14028 on Improving the Nation's Cybersecurity mandated SBOM provision for all software sold to the US federal government. CISA's Minimum Elements guidance defines seven required fields: supplier name, component name, version, component hash, relationship, author, and timestamp.
SBOMs must be regenerated whenever dependencies change, not just at major releases. Automate SBOM generation as part of every build artefact, store it alongside the artefact in the registry, and feed it into your vulnerability management system for continuous monitoring.
With an understanding of sbom: software bill of materials in place, the discussion can now turn to ci/cd security gates, which builds directly on these foundations.
“The organization prepares the software to be built in a way that reduces defects and maintains the software's integrity. This includes establishing security requirements, protecting the build environment, and reviewing code for security vulnerabilities.”
NIST SP 800-218 (SSDF), Section 2: Practice Group PW (Produce Well-Secured Software)
“Security verification must be integrated throughout the software development lifecycle, not applied as a final gate before release. Earlier detection of security defects reduces the cost and complexity of remediation significantly.”
NIST SP 800-64r2: Security Considerations in the System Development Life Cycle, Section 2.2 (2008)
CI/CD security gates
A security gate is a policy enforcement point in a CI/CD pipeline that can block a build from progressing if defined security thresholds are not met. Typical gate stages: at pull request, Semgrep or SonarQube fails the build on any HIGH or CRITICAL SAST finding in changed code; at dependency update, Snyk or Dependabot fails the build if a dependency introduces a CVSS 9.0+ vulnerability; at container build, Trivy fails if the base image contains a CRITICAL OS CVE; before deployment to staging, OWASP ZAP active scanning fails on any HIGH or CRITICAL web finding; at release, SBOM generation fails if components are unlicensed.
Gate thresholds must be tuned. Setting ALL findings as blocking immediately floods teams with false positives and creates pressure to disable the gate entirely. A maturity-level approach: begin by blocking only CRITICAL findings, refine rules over 60-90 days, then extend to HIGH.
Common misconception
“Generating an SBOM at release time completes the software bill of materials requirement.”
SBOMs must be regenerated whenever dependencies change, not just at major releases. A dependency update in a patch release can introduce a new vulnerability. Automate SBOM generation as part of every build artefact and store it alongside the artefact in the registry. Without this, an SBOM generated at release time will be stale within days of the next routine dependency update.
Common misconception
“A clean SAST scan result proves the code has no security vulnerabilities.”
SAST tools have both false positives (findings that are not real vulnerabilities) and false negatives (real vulnerabilities the tool does not detect). SAST is particularly weak at detecting logic-level access control flaws, insecure API usage patterns, and authentication bypass conditions that require understanding the application's business logic. DAST, manual code review, and penetration testing are complementary controls. A clean SAST scan means the tool found no issues it is designed to find; it does not mean the code is secure.
A development team wants to detect SQL injection patterns introduced in a new pull request before merge, and also be alerted when a package.json dependency has a known CVE. Which combination of tools addresses both concerns?
A software team releases a critical security patch for an authentication bypass vulnerability (CVSS 9.1). The security gate requires DAST scan results before deployment. The DAST scan takes 4 hours. The patch needs to be deployed within 2 hours to meet the SLA for internet-facing systems. What is the correct resolution?
A software vendor delivers a CycloneDX SBOM alongside their product binary. Three months later, CVE-2024-12345 is published for a library listed in the SBOM at version 3.1.0. As the customer's security team, what does the SBOM enable that would not otherwise be possible?
Key takeaways
- Shift-left security moves security testing into the coding and pull-request phases. Earlier detection is cheaper and faster to remediate: NIST SP 800-218 cites a 30x cost difference between fixing a defect in production versus design.
- SAST analyses source code for vulnerability patterns at pull-request time. DAST analyses a running application; run it against staging before every deployment. They complement each other and neither replaces the other.
- SCA identifies known CVEs in dependencies including transitive ones. The Log4Shell incident demonstrated that organisations without SCA could not answer 'are we affected?' quickly.
- SBOMs in SPDX or CycloneDX format provide a machine-readable component inventory. Generate and store an SBOM with every build artefact, not just at major releases.
- Security gates in CI/CD pipelines enforce thresholds automatically. Start by blocking CRITICAL findings only and increase strictness as your tooling matures.
You now understand how to verify security before release. But even verified code runs in production - and attackers probe production systems. How do you detect when something goes wrong in a live environment? Module 15 covers logging and detection basics.
Standards and sources cited in this module
NIST SP 800-218: Secure Software Development Framework (SSDF)
Practice groups PW (Produce Well-Secured Software) and RV (Respond to Vulnerabilities) for pipeline security requirements.
Software Assurance Maturity Model: security testing stream and maturity level guidance for CI/CD integration.
CISA SBOM Minimum Elements Guidance (2021)
Seven required SBOM fields as defined by CISA under US Executive Order 14028.
Log4Shell vulnerability: the case study showing the critical value of SCA and SBOMs.
SBOM format specification for licence compliance and US federal supply chain requirements.