OWASP SPVS: Lärdomar från att säkra programvaran Pipeline

I åratal gick angripare efter en app i taget. De har bytt taktik: varför kompromettera en app när man kan kompromettera hela pipeline som bygger många? Xygenis Tidig varning om skadlig kod (MEW) detekterad 4 452 skadliga paket år 2025 och 1 281 fler hittills under 2026Varje uppmärksammad händelse under de senaste åren har träffat en annan länk i programvaruleveranskedjan:

• SolarWinds (2020): kompromiss med byggmiljön; bakdörrsuppdateringar levererade till 18 000 kunder.
• Codecov (2021)En felkonfigurerad Docker-avbildning lät angripare modifiera ett bash-uppladdningsskript och stjäla CI-hemligheter från fler än 23 000 kunder.
• CircleCI (2023)Stöld av sessionscookies på en ingenjörs bärbara dator förvandlades till åtkomsttokens för produktion; varje kund ombads att rotera varje hemlighet.
• XZ Använder bakdörr Lagring :en flerårig social ingenjörskonstkampanj som nådde nästan alla Linuxdistributioner.
• tj-åtgärder Lagring — en kaskad i GitHub Actions-leveranskedjan som förgiftade en komponent som används av fler än 23 000 arkiv.
• Attacker på Aqua Trivy och checkmarx Lagring — TeamPCP-kampanjen förvandlade två allmänt använda säkerhetsskannrar till attackvektorer och använde sedan den stulna CI/CD autentiseringsuppgifter för att kaskadbehandlas nedströms till npm, OpenVSX och PyPI.

Varje attack utnyttjade en annan del av pipeline: byggmiljö, CI-verktyg, beroenden, utvecklaruppgifter, förtroende hos underhållare, föränderliga referenser till artefakter. De flesta organisationer svarar med punktkontroll, en skanner i CI, 2FA på IdP:n, grenskydd på mainDet som vanligtvis saknas är ett sätt att fråga Är vi systematiskt täckta? snarare än Kom vi ihåg att aktivera X efter den senaste incidenten?

Leverantörer av applikationssäkerhet sitter direkt i siktet och komprometterar att man når alla kunder som litar på dess artefakter. Pressen att gå från reaktiva kontroller till en systematisk hållning är inte teoretisk. Det är förutbestämt.cisvad som motiverade införandet av OWASP SPVS standard som ett högprioriterat projekt.

Vad SPVS är, och varför strukturen är viktig

Ursprungshistorien är enkel. På LASCON 2023 ställde Farshad Abasi och Cameron Walters varandra samma fråga: var är ASVS för pipelines? OWASP ASVS hade gett applikationssäkerhet en omfattande, verifierbar standardIngen motsvarande existerade för CI/CD.

Där fanns OWASP Topp 10 CI/CD Risker, som var medvetenhetsorienterade, inte testbara; SLSA, som endast fokuserade på byggproveniens; S2C2F, som endast fokuserade på beroendekonsumtion; och OpenSSF Poängkort, som täckte specifika kontroller av arkivet. Varje täckte en del. Ingen täckte helheten.

Ramverk eller projekt	Primärt omfattning
OWASP Topp 10 CI/CD Risker	Medvetenhetsorienterad CI/CD riskvägledning, inte en testbar verifiering standard.
SLSA	Bygg upp proveniens och artefaktintegritet.
S2C2F	Säker beroendekonsumtion.
OpenSSF Score-kort	Specifika säkerhetskontroller på arkivnivå.

Gapet: varje ramverk täckte en viktig del av software supply chain security, men ingen tillhandahöll en heltäckande, verifierbar standard för det hela CI/CD pipeline.

Det samtalet blev två års arbete, och i oktober 2025 släppte SPVS-arbetsgruppen v1.0: 127 krav över hela livscykeln, Planera, Utveckla, Integrera, Release, Drift, uppdelade i tre mognadsnivåer: L1 Grundläggande, L2 Standardoch L3 Advanced. Alla krav är mappade till NIST SP 800-53, OWASP CI/CD Topp 10 och CWE.

Det är här de flesta organisationer kämpar. De skannar beroenden men ignorerar releasestyrning. De signerar artefakter men hotmodellerar inte sina pipeline arkitektur. De övervakar produktion men inte sina byggmiljöer.

Det är denna tes som rättfärdigar ansträngningen. Styrkor i ett skede kompenserar inte för svagheter i ett annat. Angripare behöver bara en länk för att bryta. En livscykel standard tvingar dig att kontrollera alla, och progressionen från L1 till L2 till L3 låter dig göra det utan att koka havet. SPVS ersätter inte SLSA, S2C2F, Scorecard eller Sigstore; det ger dig den struktur som talar om för dig var var och en av dem passar in.

Anpassning av Standard till din organisation

Det naturliga första steget är en direkt granskning av din organisation och programvaruinfrastruktur mot varje krav. Ett Google Sheet hämtat från den officiella SPVS-krav CSV fungerar bra som utgångspunkt. Tre vyer är användbara: en kravmatris med status och ägare per kontroll, en värmekarta per arkiv och en dashboard av framsteg per steg och nivå. Resultatet matas naturligt in i en teknisk färdplan, ett levande dokument som täcker varje steg från plan till drift.

De flesta mogna ingenjörsorganisationer kommer redan att befinna sig runt nivå 2 när de gör denna inledande kartläggning. Det är faktiskt en bra position: det innebär att den första fasen kan fokusera på att täcka specifika luckor snarare än att bygga grunden från grunden.

Ett kalkylblad är dock en ögonblicksbild, och SPVS kräver mer. V1.1.7 kräver en kvartalsvis granskning av VCS-administratörer; V5.1.1 till V5.1.3 lägger till regelbundna användargranskningar, granskning av åtkomstloggar och övervakning av privilegierad åtkomst; flera V2.1.x-, V3.3.x- och V4.2.x-kontroller kräver kontinuerlig arbetsflödeshygien för YAML. Körs manuellt över hela organisationen, det vill säga en halvdags klickspårning varje kvartal med en verklig risk för tysta utelämnanden. Det är den typen av jobb som antingen automatiseras eller bara granskas efter att något dåligt har hänt.

Vissa SPVS-kontroller är inte engångspunkter på checklistan. De kräver återkommande granskning, revisionsbevis och avvikelsedetektering mellan databaser, användare, arbetsflöden och privilegierad åtkomst.

SPVS-området	Kravtyp
V1.1.7	Kvartalsvis revision av VCS-administratörer.
V5.1.1–V5.1.3	Regelbundna användargranskningar, granskning av åtkomstloggar och övervakning av privilegierad åtkomst.
V2.1.x, V3.3.x, V4.2.x	Löpande arbetsflöde YAML-hygien.

Svaret är att bygga eller implementera verktyg som körs under organisationsägarens identitet och producerar ett strukturerat kvartalsvis paket: administratörsregister, filialskydd, KODÄGARENS täckning, arbetsflödes-YAML-hygien med fästa åtgärder, explicita behörigheter, pull_request_target gating, medlem 2FA, installerade GitHub-appar och distribuerade nycklar. Det som brukade vara en halvdags kalkylarksarkeologi blir ett enda kommando som skickar JSON och Markdown. Kvartalsöversynen mellan CISO- och organisationsadministratörer blir en decisionmöte, inte ett datainsamlingsmöte, och handlingsbara resultat blir eftersläpningsproblem med allvarlighetsgradsbaserade servicenivåavtal.

En policy för tillåtelselistor, inklusive godkända administratörer, godkända appar och behörigheter per funktion för databaser och arbetsflöden, bör finnas som YAML i ett versionskontrollerat databaser, kontrollerat av PR-granskning från säkerhetsteamet. Varje ändring av tillåtelselistan lämnar ett granskningsspår, så revisionsbevis genereras av sig själva. Effekten är att kontroller som var ambitiösa, till exempel "vi borde granska kvartalsvis", omvandlas till rutinmässiga, till exempel "denna kvartals revision kom på måndag", och att ge organisationen en repeterbar mekanism för den avvikelsedetektering som end-to-end-principen kräver.

Friktionerna du bör planera för

Tekniska kontroller är den enkla delen. Människor är svårare.

Det mest framträdande exemplet är nästan alltid KODÄGARE. .github/workflows/ @your-org/security på varje repo låter trivialt. En fil, en rad. Men det betyder att ingenjörer som har sammanfogat arbetsflödesändringar i åratal nu behöver en säkerhetsgranskning. Även säkerhetsmedvetna personer motsätter sig: Jag skrev det här arbetsflödet, jag förstår det, varför väntar jag?

Det krävs en riktig konversation för att fastställa varför. Arbetsflöden kan stjäla inloggningsuppgifter, omdirigera artefakter och förgifta konsumenter nedströms. Ett andra par ögon är inte misstro; det är samma logik som att ha fyra ögon på förändringar i produktionsdatabasen. Att ha en konkret, aktuell incident i leveranskedjan att peka på, oavsett om det är från branschen eller din egen miljö, hjälper enormt mycket. Inget kristalliserar en kontroll som ett verkligt exempel på dess frånvaro.

Andra friktioner följer samma form:

• Explicita behörigheter: Block i arbetsflöden orsakar CI-fel tills bidragsgivarna förstår begränsade behörigheter. Detta är inte ett behörighetsproblem, utan ett problem med den mentala modellen.
• Taggens oföränderlighet: bryter lanseringsverktyg som i tysthet har omtaggats i åratal.
• Signerad commits: skapa onboarding-friktion tills GPG- eller SSH-nycklar är korrekt konfigurerade på alla arbetsstationer. SPVS gör detta obligatoriskt för alla repositories och bidragsgivare, inte bara de huvudsakliga.
• Ersätta klassiska personliga åtkomsttokens: över många databaser och arbetsflödesfiler berör nästan alla team.

Mönstret som fungerar: introducera varje kontroll med ett specifikt hot som den blockerar, pilotera på ett eller två repositories, rulla ut med undantag på tillåtelselistan och ta bort undantagen enligt en definierad tidslinje. De ingenjörer som protesterar hårdast blir oftast de starkaste förespråkarna när de väl ser logiken.

En djupare poäng: principen om att allt fungerar är relevant här. Man kan inte välja och vraka. Att hårdna byggfasen samtidigt som man lämnar releasestyrningen lös ger falskt förtroende, vilket är precis det felläge som SPVS-författarna pekar ut. Varje steg måste utvecklas tillsammans, även när en specifik kontroll känns oproportionerlig i sig.

Kostnad: Ungefär en månads förbrukad ingenjörstid för fas 1, med fokus på nivå 2-efterlevnad för en liten organisation, fördelad över DevOps-, säkerhets- och ingenjörsgranskare. Investeringen betalar sig lätt. En enda förhindrad incident i leveranskedjan täcker det mångdubbelt. Större organisationer borde budgetera proportionellt mer, men den fasuppdelade strukturen från nivå 1 till nivå 2 till nivå 3 innebär att värde levereras innan programmet är slutfört.

Vad är nästa steg?

SPVS v1.5 är på gång med AI-relaterade kontroller: ursprunget av AI-assisterad kod, guardrails För CI-arbetsflöden som anropar LLM:er, granska spår för AI-genererade pull requestsoch försvar mot nya hot som slopsquatting, där angripare registrerar paketnamn som AI-kodningsassistenter hallucinerar, och den operativa AI-genererade skadliga programvaran som CrowdStrike rapporterar i omlopp. Organisationer som redan taggar AI-assisterade commits och PR:er i sina interna utvecklingsriktlinjer kommer att uppleva denna anpassning som en stegvis snarare än ett nytt arbetsprogram.

Version 2.0 förväntas fördjupa övervakningen av körtid och kraven för livscykeln för autentiseringsuppgifter. En rimlig organisatorisk färdplan: täcka återstående luckor på nivå 3 i slutet av andra kvartalet 2026, inklusive SLSA provenance integreras i standard CI/CD, manuella grindar för produktionsdistributioner och centraliserad identitetsleverantör, och sedan övergå till underhållsläge. Varje nytt datalager börjar fungera korrekt, och varje kvartalsvis granskning upptäcker avvikelser tidigt.

Ett uppriktigt tack till Farshad Abasi, Cameron Walters och OWASP SPVS-arbetsgruppen. Projekt som detta sänker ribban för alla organisationer som vill arbeta systematiskt med leveranskedjesäkerhet snarare än reaktivt.

Key Takeaways

Några saker som översätts bortom vår specifika kontext:

• För att prova det: Ladda ner CSV-filen med SPVS-kraven och kartlägg dina nuvarande kontroller i ett kalkylblad. Du vet inom en dag om det passar.
• Välj en målnivå och skicka den innan du sträcker dig mot nästa. L1 till L2 till L3 är en funktion, inte en begränsning.
• Ocuco-landskapet pipeline är målet. Applikationscentrerade kontroller är nödvändiga men inte tillräckliga; behandla pipeline som en förstklassig anfallsyta.
• Verifiera helheten pipeline, inte ett stycke. Styrkan i beroendeskanningen kompenserar inte för svag releasestyrning eller oövervakade byggmiljöer.
• Kalkylblad är ögonblicksbilder; avdriften är kontinuerlig. Bygg automation, även ett blygsamt internt verktyg, för att upptäcka avvikelser mellan revisioner.
• Det organisatoriska arbetet är svårare än det tekniska arbetet. Budgetera tid för samtal och pilotprojekt före utrullning, och förklara det specifika hotet som varje kontroll blockerar.

Att läsa mer

• OWASP: Säkra Pipeline Verifiering Standard (SPVS) v1.0OWASP-projektsida.
• Farshad Abasi: Varför vi skapade OWASP SPVSOWASP SPVS-artiklar.
• Farshad Abasi: Pipeline Attackerna blir värre. Så här förbereder du digOWASP SPVS-artiklar.
• Farshad Abasi: OWASP SPVS jämfört med andra ramverk för leveranskedjorOWASP SPVS-artiklar.
• OWASP: Top 10 CI/CD SäkerhetsriskerOWASP-projektsida.
• SLSA: Leveranskedjans nivåer för programvaruartefakterslsa.dev.
• OpenSSF: Score-kortsecurityscorecards.dev.