The recent Shai‑Hulud 2.0 supply chain attack showed how a compromised npm package can affect an application and even disrupt entire build and deployment pipelines. It’s a reminder that pipeline security deserves the same attention as production environments.
Released earlier this year, OWASP’s Secure Pipeline Verification Standard (SPVS) provides structured guidance for securing software delivery pipelines from start to finish throughout the software development lifecycle.
Understanding SPVS
While application security has well-known standards like the Application Security Verification Standard (ASVS), pipelines haven’t had a proper framework until now. It uses a maturity-based approach with three levels, letting teams start with foundational protections, then move to standard, and build up to more advanced controls as they grow.
SPVS is designed for software developers, DevOps/DevSecOps engineers, security teams, and release managers, and is also platform-agnostic, so the guidance applies no matter what stack is being used.
The framework places an emphasis on verification, rather than just documenting controls to prove they work. For example, with dependency scanning, a company might document “We scan third-party libraries for vulnerabilities.”
However, a more verified approach would include something like: “Scanner runs automatically on every build, results are logged, and vulnerable dependencies block the pipeline from progressing.”
It’s therefore much more evidence-based. SPVS shows how to confirm that security controls are in place and working, making it useful for audits and compliance in the pipeline.
Pipeline Security Risks in Focus
While applicable to any software delivery process, SPVS is particularly relevant for CI/CD environments. Given that pipelines have so many different parts and components, they are attractive targets for attackers, and some of the risks include:
-
Unauthorized access: Attackers or misconfigured permissions could compromise build systems or artifact repositories.
-
Compromised dependencies: Malicious or vulnerable libraries can find their way into production if not carefully managed.
-
Secrets leakage: Hardcoded credentials or environment variables that aren’t managed properly can leak sensitive data.
-
Pipeline misconfigurations: Mistakes in configuration can lead to unauthorized changes or bypassed checks.
-
Incomplete auditing: Lack of traceability can make it hard to detect when something goes wrong.
OWASP has a Top 10 list of CI/CD pipeline risks that shows why security should be an integral part of software delivery.
The Five Stages of SPVS
SPVS divides the pipeline into five lifecycle areas: Plan, Develop, Integrate, Release, and Operate. Each stage includes verification requirements that show what good security looks like at different levels of maturity.
1. Plan
This stage focuses on defining how pipeline security will work before development begins. It covers early risk assessments, selecting trusted tools, initial governance decisions, access expectations, and the rules that guide the rest of the lifecycle.
Threat modeling at this stage helps teams understand potential risks early. Identifying how attackers might target source control, build systems, dependencies, or deployment automation means teams can design controls that prevent vulnerabilities before they appear.
2. Develop
In the Develop stage, the emphasis is on coding securely from the beginning and on creating software in controlled environments.
If developers have practical security training, they’ll be able to recognize insecure patterns, interpret scanner results, and make secure decisions early in the development process. Such training should include:
-
Secure coding: Focus on writing code that prevents vulnerabilities and is easy to test and maintain.
-
Dependency awareness: Use trusted registries, regularly check the health of libraries, and look for insecure components.
-
Secrets handling: Don’t hardcode credentials, store secrets securely, and rely on environment variables where appropriate.
-
Traceability: Make sure every code change is reviewed and approved, as well as being fully auditable.
-
Testing: Use unit and integration tests to verify functionality and reduce security regressions.
These practices support SPVS requirements for the Develop stage.
3. Integrate
The next stage is securely integrating new code into the main codebase.
SPVS evaluates the security of the build process by checking for hardened and reproducible builds. It then verifies artifact integrity, runs automated security analysis, and ensures the pipeline is isolated from tampering or misuse.
These checks make sure that code entering the pipeline remains trustworthy and that attackers cannot interfere with builds, artifacts, or automation.
4. Release
The Release phase ensures that deployments are authenticated, verified, and safe to promote. It includes artifact signing, environment-specific validation, approval workflows, and checks that confirm the build and deployment processes are free from unauthorized changes. This stage also provides compliance validations.
5. Operate
Pipeline security does not stop after software is deployed. It covers monitoring, logging, incident response readiness, and the protections needed to keep environments trustworthy after deployment. SPVS also supports continuous verification and strong separation between runtime systems and the build pipeline.
What SPVS Aims to Solve
Well-organized teams can still struggle with inconsistent pipeline controls. Security checks differ from project to project, automation varies across teams, and it is easy to assume that safeguards exist when they do not. SPVS removes this uncertainty by creating shared expectations across the organization.
Its structure addresses problems such as:
-
Inconsistent practices: Teams may use different patterns, leading to unpredictable security coverage.
-
Poor visibility: Without verification, missed or duplicated controls can go unnoticed.
-
Different expectations: Developers, platform teams, and security groups often disagree on responsibilities.
SPVS aligns these views by providing a shared maturity model.
Main Principles Behind SPVS
Built-in security
SPVS reinforces the idea that pipeline security should be part of everyday workflows. Integrated security reduces bottlenecks and avoids the old pattern where issues pile up at the end of development.
Automation
Automated controls are consistent and resistant to manipulation. SPVS highlights automation as the most reliable way to enforce security across the pipeline.
Verification
Strong auditability, logging, artifact signing, and reproducible builds help teams verify that what they build is precisely what gets deployed.
Supply chain security
SPVS pays much attention to dependencies, registries, and the integrity of external components. Today’s attacks often come from the supply chain, so these protections are vital.
Now that supply chain compromise is on the OWASP Top 10:2025, SPVS gives teams a way to understand what secure pipeline practices should look like.
How SPVS Improves Software Delivery
Using SPVS helps organizations create predictable, secure, and repeatable pipelines. Benefits include:
-
Greater trust in releases: Artifact signing and traceable workflows ensure only approved code moves forward.
-
More reliable automation: Security controls are consistent across every build and release.
-
Better regulatory alignment: Verified controls make compliance checks easier and more accurate.
-
Improved collaboration: With shared expectations, teams work more effectively and reduce friction.
-
Reduced supply chain risk: Verified dependencies and hardened builds limit opportunities for attackers.
Getting Started with SPVS
SPVS usually begins with a gap assessment to understand the current pipeline. From there, teams prioritize improvements that offer the most immediate risk reduction, such as hardening the build system or implementing dependency controls.
Gradual improvement from one maturity level to the next creates lasting progress without overwhelming teams or slowing development. Organizations are not expected to implement every advanced requirement immediately.
The maturity model supports realistic, incremental progress based on risk, resources, and automation capability.
How SecureFlag Supports SPVS
SPVS reinforces pipeline security, but skilled teams are still the most important part of safe software delivery.
SecureFlag supports this by offering practical learning paths and labs, including on CI/CD pipelines, that help developers and engineering teams build secure coding skills and understand how risks emerge.
Our automated threat modeling solution, ThreatCanvas, adds to this by giving organizations a visual way to model threats and map those risks to frameworks like SPVS.
With structured guidance from SPVS and hands-on training and threat modeling from SecureFlag, organizations can build delivery pipelines that are fast, reliable, and secure end-to-end.
