For years, attackers went after applications one at a time. They have changed tactics: why compromise one app when you can compromise the pipeline that builds many? Xygeni’s Malware Early Warning (MEW) detected 4,452 malicious packages in 2025 and 1,281 more in 2026 so far. Each high-profile incident from the last few years has hit a different link in the software delivery chain:
- SolarWinds (2020): build-environment compromise; backdoored updates shipped to 18,000 customers.
- Codecov (2021): a misconfigured Docker image let attackers modify a bash uploader script, exfiltrating CI secrets from more than 23,000 customers.
- CircleCI (2023): session-cookie theft on an engineer’s laptop turned into production access tokens; every customer was told to rotate every secret.
- XZ Utils backdoor (2024) :a multi-year social engineering campaign that almost reached nearly every Linux distribution.
- tj-actions (2025) — a GitHub Actions supply-chain cascade that poisoned a component used by 23,000+ repositories.
- Attacks on Aqua Trivy and Checkmarx (2026) — the TeamPCP campaign turned two widely used security scanners into attack vectors, then used the stolen CI/CD credentials to cascade downstream into npm, OpenVSX, and PyPI.
Each attack exploited a different part of the pipeline: build environment, CI tooling, dependencies, developer credentials, maintainer trust, mutable references to artifacts. Most organizations respond with point control, a scanner in CI, 2FA on the IdP, branch protection on main. What is typically missing is a way to ask are we systematically covered? rather than did we remember to enable X after the last incident?
Application security vendors sit squarely in the crosshair, compromising one reaches every customer that trusts its artifacts. The pressure to move from reactive controls to a systematic posture is not theoretical. That is precisely what motivated adopting the OWASP SPVS standard as a top-priority project.
What SPVS Is, and Why the Structure Matters
The origin story is simple. At LASCON 2023, Farshad Abasi and Cameron Walters kept asking each other the same question: where’s the ASVS for pipelines? OWASP ASVS had given application security a comprehensive, verifiable standard. Nothing equivalent existed for CI/CD.
There was the OWASP Top 10 CI/CD Risks, which was awareness-oriented, not testable; SLSA, which focused on build provenance only; S2C2F, which focused on dependency consumption only; and OpenSSF Scorecard, which covered specific repository checks. Each covered a piece. None covered the whole.
| Framework or Project | Primary Scope |
|---|---|
| OWASP Top 10 CI/CD Risks | Awareness-oriented CI/CD risk guidance, not a testable verification standard. |
| SLSA | Build provenance and artifact integrity. |
| S2C2F | Secure dependency consumption. |
| OpenSSF Scorecard | Specific repository-level security checks. |
The gap: each framework covered an important piece of software supply chain security, but none provided an end-to-end, verifiable standard for the whole CI/CD pipeline.
That conversation became two years of work, and in October 2025 the SPVS working group released v1.0: 127 requirements across the lifecycle, Plan, Develop, Integrate, Release, Operate, stratified into three maturity levels: L1 Foundational, L2 Standard, and L3 Advanced. Every requirement is mapped to NIST SP 800-53, OWASP CI/CD Top 10, and CWE.
The structure is the point. In the SPVS authors’ own words:
“Verify your entire pipeline, not just one piece. This is where most organizations struggle. They scan dependencies but ignore release governance. They sign artifacts but don’t threat model their pipeline architecture. They monitor production but not their build environments.”
This is where most organizations struggle. They scan dependencies but ignore release governance. They sign artifacts but don’t threat model their pipeline architecture. They monitor production but not their build environments.
This is the thesis that justifies the effort. Strengths in one stage do not compensate for weaknesses in another. Attackers only need one link to break. A lifecycle standard forces you to check all of them, and the L1 to L2 to L3 progression lets you do it without boiling the ocean. SPVS does not replace SLSA, S2C2F, Scorecard, or Sigstore; it gives you the scaffolding that tells you where each of them fits.
Adapting the Standard to Your Organization
The natural first step is a straight audit of your organization and software infrastructure against each requirement. A Google Sheet seeded from the official SPVS requirements CSV works well as a starting point. Three views are useful: a requirements matrix with status and owner per control, a per-repository heatmap, and a dashboard of progress by stage and level. The output feeds naturally into a technical roadmap, a living document covering every stage from plan to operate.
Most mature engineering organizations will find themselves already around L2 when they do this initial mapping. That is actually a good position: it means the first phase can focus on closing specific gaps rather than building foundations from scratch.
A spreadsheet, though, is a snapshot, and SPVS asks for more. V1.1.7 mandates a quarterly audit of VCS administrators; V5.1.1 through V5.1.3 add regular user audits, access-log review, and privileged-access monitoring; several V2.1.x, V3.3.x, and V4.2.x controls require ongoing workflow-YAML hygiene. Run by hand across the organization, that is a half-day of click-tracking every quarter with a real risk of quiet omissions. It is the kind of job that either gets automated or only gets reviewed after something bad has happened.
Some SPVS controls are not one-time checklist items. They require recurring review, audit evidence, and drift detection across repositories, users, workflows, and privileged access.
| SPVS Area | Requirement Type |
|---|---|
V1.1.7 |
Quarterly audit of VCS administrators. |
V5.1.1–V5.1.3 |
Regular user audits, access-log review, and privileged-access monitoring. |
V2.1.x, V3.3.x, V4.2.x |
Ongoing workflow YAML hygiene. |
The answer is to build or adopt tooling that runs under org-owner identity and produces a structured quarterly bundle: admin roster, branch protection, CODEOWNERS coverage, workflow YAML hygiene with pinned actions, explicit permissions, pull_request_target gating, member 2FA, installed GitHub Apps, and deploy keys. What used to be a half-day of spreadsheet archaeology becomes a single command emitting JSON and Markdown. The quarterly review between the CISO and org administrators becomes a decision meeting, not a data-gathering one, and actionable findings become backlog issues with severity-based SLAs.
An allow-list policy, including approved admins, approved apps, and permissions by function for repositories and workflows, should live as YAML in a version-controlled repository, gated by PR review from the security team. Any allowlist change leaves a review trail, so audit evidence generates itself. The effect is to turn controls that were aspirational, such as “we should audit quarterly,” into ones that are routine, such as “this quarter’s audit landed on Monday,” and to give the organization a repeatable mechanism for the drift-detection that the end-to-end principle demands.
The Frictions You Should Plan For
Technical controls are the easy part. People are harder.
The standout example is almost always CODEOWNERS. Adding .github/workflows/ @your-org/security on every repo sounds trivial. One file, one line. But it means engineers who have been self-merging workflow changes for years now need a security review. Even security-conscious people push back: I wrote this workflow, I understand it, why am I waiting?
It takes real conversation to establish the why. Workflows can exfiltrate credentials, redirect artifacts, and poison downstream consumers. A second pair of eyes is not distrust; it is the same logic as four-eyes on production database changes. Having a concrete, recent supply-chain incident to point to, whether from the industry or your own environment, helps enormously. Nothing crystallizes a control like a real example of its absence.
Other frictions follow the same shape:
- Explicit permissions: blocks in workflows cause CI failures until contributors understand scoped permissions. This is not a permissions problem, but a mental-model problem.
- Tag immutability: breaks release tooling that has been silently retagging for years.
- Signed commits: create onboarding friction until GPG or SSH keys are set up correctly across workstations. SPVS makes this mandatory across every repository and contributor, not just main ones.
- Replacing classic personal-access tokens: across many repositories and workflow files touches almost every team.
The pattern that works: introduce each control with a specific threat it blocks, pilot on one or two repositories, roll out with allowlisted exceptions, and retire the exceptions on a defined timeline. The engineers who push back hardest become, more often than not, the strongest advocates once they see the rationale.
One deeper point: the end-to-end principle bites here. You cannot pick and choose. Hardening the build stage while leaving release governance loose gives false confidence, which is exactly the failure mode the SPVS authors call out. Every stage has to advance together, even when a specific control feels disproportionate in isolation.
Cost: roughly a month of elapsed engineering time for Phase 1, focused on L2 compliance for a small organization, spread across DevOps, Security, and engineering reviewers. The investment pays back easily. A single prevented supply-chain incident covers it many times over. Larger organizations should budget proportionally more, but the phased L1 to L2 to L3 structure means value is delivered before the programme is complete.
What Is Next
SPVS v1.5 is on the horizon with AI-related controls: provenance of AI-assisted code, guardrails for CI workflows that call LLMs, review trails for AI-generated pull requests, and defenses against emerging threats like slopsquatting, where attackers register package names that AI coding assistants hallucinate, and the operational AI-generated malware that CrowdStrike reports in the wild. Organizations that already tag AI-assisted commits and PRs in their internal development guidelines will find this adaptation incremental rather than a new programme of work.
Version 2.0 is expected to deepen runtime monitoring and the credential lifecycle requirements. A reasonable organizational roadmap: close remaining L3 gaps by end of Q2 2026, including SLSA provenance integrated into standard CI/CD, manual gates for production deployments, and centralized identity provider, then shift to maintenance mode. Every new repository starts compliant, and every quarterly audit catches drift early.
A sincere thank-you to Farshad Abasi, Cameron Walters, and the OWASP SPVS working group. Projects like this lower the bar for every organization that wants to do supply-chain security systematically rather than reactively.
Key Takeaways
A few things that translate beyond our specific context:
- To try it: download the SPVS requirements CSV and map your current controls in a spreadsheet. You’ll know within a day whether it fits.
- Pick one target level and ship it before reaching for the next. L1 to L2 to L3 is a feature, not a limitation.
- The pipeline is the target. Application-centric controls are necessary but not sufficient; treat the pipeline as a first-class attack surface.
- Verify the whole pipeline, not one piece. Strength in dependency scanning does not make up for weak release governance or unmonitored build environments.
- Spreadsheets are snapshots; drift is continuous. Build automation, even a modest in-house tool, to detect drift between audits.
- The organizational work is harder than the technical work. Budget time for conversation and pilot-before-rollout, and explain the specific threat each control blocks.
To Read More
- OWASP: Secure Pipeline Verification Standard (SPVS) v1.0. OWASP Project Page.
- Farshad Abasi: Why We Created OWASP SPVS. OWASP SPVS Articles.
- Farshad Abasi: Pipeline Attacks Are Getting Worse. Here’s How to Prepare. OWASP SPVS Articles.
- Farshad Abasi: OWASP SPVS vs. Other Supply Chain Frameworks. OWASP SPVS Articles.
- OWASP: Top 10 CI/CD Security Risks. OWASP Project Page.
- SLSA: Supply-chain Levels for Software Artifacts. slsa.dev.
- OpenSSF: Scorecard. securityscorecards.dev.
