OWASP SPVS: Lessons from Securing the Software Pipeline

Verify the Whole Software Pipeline: The Friction, the Wins, and the Lessons from Adopting OWASP SPVS

The OWASP Secure Pipeline Verification Standard (SPVS) reached version 1.0 in October 2025. We decided to use the standard across our organization for the reasons explained below.

This post is an honest account of why we took it on, how we adapted it, what hurt, and what we would recommend to anyone walking the same road.

Why a Pipeline Standard, and Why Now

For years, attackers went after applications one at a time.

But their tactics have changed.

Why compromise one application when you can compromise the pipeline that builds many?

Sonatype tracked over 512,000 new malicious packages in 2024 alone, a 156% year-over-year increase. And each high-profile incident from the last few years hit a different link in the software delivery chain.

Each attack exploited a different part of the pipeline:

• Build environments
• CI tooling
• Dependencies
• Developer credentials
• Maintainer trust
• Mutable references to artifacts

Most organizations respond with point controls.

• A scanner in CI
• 2FA on the IdP
• Branch protection on main

We did too.

What was missing was a way to ask:

Are we systematically covered?

Instead of:

Did we remember to enable X after the last incident?

Because application security vendors sit directly in the crosshairs, compromising one vendor can affect every customer that trusts its artifacts. For us, the pressure to move from reactive controls to systematic pipeline protection was not theoretical.

Then we got first-hand experience.

In March 2026, the xygeni-action GitHub Action compromise involved:

• A compromised GitHub App private key
• A poisoned mutable tag
• A C2 implant disguised as telemetry

Branch protection rules and other technical controls did their work, but they were not enough.

Although the real customer impact was zero, reputational damage demands transparency and a structural response. We understood that, as a software security vendor, we needed a radical departure from point, ad-hoc controls toward systematic protection of our software pipelines.

That motivated us to adopt 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 is the ASVS for pipelines?

OWASP ASVS had given application security a comprehensive, verifiable standard. Nothing equivalent existed for CI/CD.

There were useful frameworks and tools, but each covered only part of the problem:

Each covered a piece.

None covered the whole.

That conversation became two years of work. In October 2025, the SPVS working group released v1.0:

• 127 requirements
• Covering the full lifecycle:
  • Plan
  • Develop
  • Integrate
  • Release
  • Operate
• Organized into three maturity levels:
  • L1 Foundational
  • L2 Standard
  • L3 Advanced
• Mapped to:
  • NIST SP 800-53
  • OWASP CI/CD Top 10
  • CWE

The structure is the point.

As the SPVS authors explain:

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.

That was the thesis that justified the effort for us.

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 → L2 → 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 Our Organization

Our first step was a straight audit of our organization and software infrastructure against each requirement.

We captured the audit in a Google Sheet seeded from the official SPVS requirements CSV .

We used three main views:

• Requirements matrix
  Status and owner per control.
• Per-repository heatmap
  Visibility into repository-level gaps.
• Dashboard by stage and level
  Progress across Plan, Develop, Integrate, Release, and Operate.

We also expanded our internal Technical Guidelines for Secure Software Pipelines to cover every stage from plan to operate.

We found that we were already largely at maturity level L2. That was reassuring, though not surprising for a company whose business is software supply-chain security.

That allowed the first phase to focus on closing specific gaps rather than building foundations from scratch.

But a spreadsheet is only a snapshot.

SPVS asks for more.

Some controls require recurring review:

Run manually across the organization, this becomes a half-day of click-tracking every quarter, with a real risk of quiet omissions.

That kind of job either gets automated or is reviewed only after something bad has happened.

So we built xygeni-vcs-audit.

It is an in-house tool that runs under org-owner identity and produces a structured quarterly bundle covering:

• Admin roster
• Branch protection
• CODEOWNERS coverage
• Workflow YAML hygiene
• Pinned actions
• Explicit permissions
• pull_request_target gating
• Member 2FA
• Installed GitHub Apps
• Deploy keys

What used to be a half-day of spreadsheet archaeology is now a single command emitting JSON and Markdown.

The quarterly 30-minute review between the CISO and the organization administrators is now a decision meeting, not a data-gathering meeting.

Actionable findings become backlog issues with severity-based SLAs.

The tool is internal for now, but the pattern is simple: a weekend of scripting against the GitHub API can remove a lot of recurring manual work.

We also added an allow-list policy covering:

• Approved admins
• Approved apps
• Permissions by function for repositories and workflows

This policy lives as YAML inside the tool’s own repository and is gated by PR review from our security team.

Any allowlist change leaves a review trail, so the audit evidence generates itself.

No SaaS.
No third-party rule pack.
No extra credential to manage.

The effect has been to turn aspirational controls into routine controls.

Instead of saying:

We should audit quarterly.

We can now say:

This quarter’s audit landed on Monday.

That gives us a repeatable mechanism for the drift detection that the end-to-end principle demands.

The Frictions We Did Not Plan For

Technical controls are the easy part.

People are harder.

The standout example was CODEOWNERS.

Adding this line on every repository sounds trivial:

.github/workflows/ @xygeni/security

One file.
One line.

But it meant engineers who had been self-merging workflow changes for years now needed a security review.

Even security-conscious people pushed back:

I wrote this workflow. I understand it. Why am I waiting?

It took real conversation to establish the why.

Workflows can:

• Exfiltrate credentials
• Redirect artifacts
• Poison downstream consumers

A second pair of eyes is not distrust. It is the same logic as four-eyes review on production database changes.

The xygeni-action incident helped. Nothing crystallizes a control like a concrete example of what happens when that control is missing.

Other frictions followed the same pattern.

We had used GPG-signed commits in our main repositories from the start. SPVS made it mandatory across every repository and contributor.

The pattern that worked was:

• Introduce each control with the specific threat it blocks.
• Pilot it on one or two repositories.
• Roll it out with allowlisted exceptions.
• Retire the exceptions on a timeline.

Interestingly, the engineers who pushed back hardest often became the strongest advocates once they understood the rationale.

There is also a deeper point.

The end-to-end principle bites here.

We could not pick and choose. Hardening the build stage while leaving release governance loose would have created false confidence, which is exactly the failure mode the SPVS authors warn about.

Every stage had to advance together, even when a specific control felt disproportionate in isolation.

Cost

Phase 1, focused on L2 compliance, took roughly one month of elapsed engineering time, spread thinly across:

• DevOps
• Security
• Engineering reviewers

We are small enough to make that possible, but your mileage may vary.

The investment pays back easily. A single prevented supply-chain incident covers it many times over.

Mapping the Incident to SPVS v1.0

Mapping the xygeni-action incident onto SPVS v1.0 was instructive.

The tag poisoning gap is important.

SPVS v1.0 has no explicit control for tag or release immutability, and no requirement for signed tags.

V3.4.1, signed artifacts, is the nearest neighbor. But signed artifacts help consumers detect tampering. They do not prevent a tag from being moved in the first place.

Tag immutability, and arguably required signed commits and signed tags, are natural candidates for future SPVS revisions.

What Is Next

SPVS v1.5 is on the horizon with AI-related controls, including:

• Provenance of AI-assisted code
• Guardrails for CI workflows that call LLMs
• Review trails for AI-generated pull requests
• Defenses against emerging threats like slopsquatting

Slopsquatting refers to attackers registering package names that AI coding assistants hallucinate.

We already tag Claude-assisted commits and PRs under our internal AI development guidelines, so this adaptation should be incremental rather than a new program of work.

Version 2.0 is expected to deepen:

• Runtime monitoring
• Credential lifecycle requirements

Our own roadmap is clear:

• Close remaining L3 gaps by the end of Q2 2026
• Integrate SLSA provenance into standard CI/CD
• Add manual gates for production deployments
• Centralize identity provider controls
• Shift into maintenance mode

The goal is simple:

Every new repository starts compliant.
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 approach software supply-chain security systematically rather than reactively.

Key Takeaways

A few lessons translate beyond our specific context:

1. Start with the SPVS requirements CSV

Download the SPVS requirements CSV and map your current controls in a spreadsheet.

You will know within a day whether it fits your organization.

2. Pick one target level and ship it

L1 → L2 → L3 is a feature, not a limitation.

Do not try to do everything at once.

3. Treat the pipeline as the target

Application-centric controls are necessary, but not sufficient.

Your pipeline is now a first-class attack surface.

4. Verify the whole pipeline

Strong dependency scanning does not compensate for weak release governance or unmonitored build environments.

5. Automate drift detection

Spreadsheets are snapshots. Drift is continuous.

Even a modest in-house tool can make audits repeatable and actionable.

6. Budget for organizational work

The people side is harder than the technical side.

Explain the specific threat each control blocks, pilot before rollout, and give teams a path to adapt.

To Read More

• OWASP: Secure Pipeline Verification Standard SPVS v1.0
• Farshad Abasi: Why We Created OWASP SPVS
• Farshad Abasi: Pipeline Attacks Are Getting Worse. Here’s How to Prepare
• Farshad Abasi: OWASP SPVS vs. Other Supply Chain Frameworks
• OWASP: Top 10 CI/CD Security Risks
• SLSA: Supply-chain Levels for Software Artifacts
• OpenSSF: Scorecard