OWASP SPVS: Lessen uit het beveiligen van de software Pipeline

Jarenlang vielen aanvallers applicaties één voor één aan. Ze hebben hun tactiek veranderd: waarom één app compromitteren als je ze allemaal tegelijk kunt compromitteren? pipeline Die bouwt er veel? Xygeni's Vroegtijdige waarschuwing voor malware (MEW) gedetecteerd 4,452 kwaadaardige pakketten in 2025 en Tot nu toe 1,281 meer in 2026.Elk spraakmakend incident van de afgelopen jaren heeft een andere schakel in de softwareleveringsketen getroffen:

• SolarWinds (2020): inbreuk op de bouwomgeving; updates met een achterdeur zijn naar 18,000 klanten verzonden.
• Codecov (2021)Een verkeerd geconfigureerde Docker-image stelde aanvallers in staat een bash-uploadscript aan te passen, waardoor CI-geheimen van meer dan 23,000 klanten werden buitgemaakt.
• CircleCI (2023): diefstal van sessiecookies op de laptop van een engineer leidde tot de verkrijging van toegangstokens voor de productieomgeving; elke klant werd opgedragen om alle geheime gegevens te vernieuwen.
• XZ Maakt gebruik van een achterdeur (2024) Een meerjarige social engineering-campagne die vrijwel elke Linux-distributie bereikte.
• tj-acties (2025) — een ketenprobleem bij GitHub Actions dat een component vergiftigde dat door meer dan 23,000 repositories werd gebruikt.
• Valt aan Aqua Trivy en checkmarx (2026) — De TeamPCP-campagne maakte van twee veelgebruikte beveiligingsscanners aanvalsvectoren en gebruikte vervolgens de gestolen gegevens. CI/CD inloggegevens die vervolgens worden doorgegeven aan npm, OpenVSX en PyPI.

Elke aanval maakte gebruik van een ander onderdeel van de pipeline: bouwomgeving, CI-tools, afhankelijkheden, ontwikkelaarsreferenties, vertrouwen van de beheerder, veranderlijke verwijzingen naar artefacten. De meeste organisaties reageren met puntcontrole, een scanner in CI, 2FA op de identiteitsprovider, branchbeveiliging op mainWat doorgaans ontbreekt, is een manier om te vragen. Zijn we systematisch gedekt? dan Hebben we eraan gedacht om X in te schakelen na het laatste incident?

Leveranciers van applicatiebeveiliging bevinden zich rechtstreeks in het vizier, aangezien een inbreuk op één van deze systemen elke klant treft die op hun producten vertrouwt. De druk om over te stappen van reactieve naar een systematische aanpak is niet theoretisch. Dat is een feit.cisWat was de motivatie om de OWASP SPVS te adopteren? standard als een project met topprioriteit.

Wat SPVS is en waarom de structuur belangrijk is.

Het ontstaan ​​is eenvoudig. Tijdens LASCON 2023 bleven Farshad Abasi en Cameron Walters elkaar dezelfde vraag stellen: waar blijft de ASVS voor pipelines? OWASP ASVS had applicatiebeveiliging een alomvattende, verifieerbare basis gegeven. standardEr bestond niets vergelijkbaars voor CI/CD.

Er was de OWASP Top 10. CI/CD Risks, dat gericht was op bewustwording en niet testbaar was; SLSA, dat zich alleen richtte op de herkomst van de build; S2C2F, dat zich alleen richtte op het gebruik van afhankelijkheden; en OpenSSF Scorecard, die specifieke repository-controles omvatte. Elke controle behandelde een onderdeel. Geen enkele dekte het geheel.

Kader of project	Primaire scope
OWASP-Top 10 CI/CD Risico's	Bewustwording-gericht CI/CD Risicorichtlijnen, geen toetsbare verificatie. standard.
SLSA	Zorg voor een goede herkomst en integriteit van het artefact.
S2C2F	Veilig gebruik van afhankelijkheden.
OpenSSF Score kaart	Specifieke beveiligingscontroles op repositoryniveau.

De kloof: elk raamwerk behandelde een belangrijk onderdeel van software supply chain securitymaar geen van hen bood een volledig verifieerbare oplossing. standard voor het geheel CI/CD pipeline.

Dat gesprek mondde uit in twee jaar werk, en in oktober 2025 publiceerde de SPVS-werkgroep versie 1.0: 127 vereisten voor de gehele levenscyclus (Plan, Ontwikkel, Integreer, Release, Operate), onderverdeeld in drie volwassenheidsniveaus: L1 Fundamenteel, L2 Standarden L3 Advanced. Elke vereiste is gekoppeld aan NIST SP 800-53, OWASP CI/CD Top 10 en CWE.

Dit is waar de meeste organisaties tegenaan lopen. Ze scannen afhankelijkheden, maar negeren het releasebeheer. Ze ondertekenen artefacten, maar voeren geen dreigingsanalyse uit op hun bestanden. pipeline architectuur. Ze houden de productie in de gaten, maar niet hun ontwikkelomgevingen.

Dit is de these die de inspanning rechtvaardigt. Sterke punten in de ene fase compenseren niet voor zwakke punten in een andere. Aanvallers hoeven maar één schakel te breken. Een levenscyclus standard Het dwingt je om ze allemaal te controleren, en de L1 naar L2 naar L3-progressie stelt je in staat dit te doen zonder al te veel moeite. SPVS vervangt SLSA, S2C2F, Scorecard of Sigstore niet; het biedt je de structuur die aangeeft waar elk van deze systemen thuishoort.

Het aanpassen van de Standard aan uw organisatie

De meest logische eerste stap is een grondige audit van uw organisatie en software-infrastructuur aan de hand van alle vereisten. Een Google Sheet, gebaseerd op de officiële documentatie, kan hierbij helpen. SPVS-vereisten CSV Werkt prima als uitgangspunt. Drie weergaven zijn nuttig: een vereistenmatrix met status en eigenaar per beheerelement, een heatmap per repository en een dashboard van de voortgang per fase en niveau. De output wordt op natuurlijke wijze opgenomen in een technische routekaart, een dynamisch document dat elke fase van planning tot uitvoering omvat.

De meeste gevestigde ingenieursbureaus bevinden zich al rond niveau L2 wanneer ze deze eerste inventarisatie uitvoeren. Dat is een goede uitgangspositie: het betekent dat de eerste fase zich kan richten op het dichten van specifieke hiaten in plaats van het helemaal opnieuw opbouwen van een fundament.

Een spreadsheet is echter slechts een momentopname, en SPVS vraagt ​​om meer. Versie 1.1.7 schrijft een driemaandelijkse audit van VCS-beheerders voor; versies 5.1.1 tot en met 5.1.3 voegen regelmatige gebruikersaudits, controle van toegangslogboeken en monitoring van bevoorrechte toegang toe; diverse controles in versies 2.1.x, 3.3.x en 4.2.x vereisen continue workflow-YAML-hygiëne. Handmatig uitvoeren binnen de hele organisatie betekent een halve dag per kwartaal aan het bijhouden van klikken, met een reëel risico op onopgemerkte fouten. Het is het soort werk dat ofwel geautomatiseerd wordt, ofwel pas wordt gecontroleerd nadat er iets mis is gegaan.

Sommige SPVS-controles zijn geen eenmalige checklistpunten. Ze vereisen terugkerende beoordeling, auditbewijs en detectie van afwijkingen in repositories, gebruikers, workflows en bevoorrechte toegang.

SPVS-gebied	Vereistetype
V1.1.7	Driemaandelijkse audit van VCS-beheerders.
V5.1.1–V5.1.3	Regelmatige gebruikersaudits, controle van toegangslogboeken en monitoring van bevoorrechte toegang.
V2.1.x, V3.3.x, V4.2.x	Doorlopende workflow-hygiëne in YAML-bestanden.

De oplossing is om tools te ontwikkelen of te implementeren die draaien onder de identiteit van de organisatie-eigenaar en een gestructureerd kwartaalpakket produceren: beheerderslijst, branchbeveiliging, CODEOWNERS-dekking, workflow YAML-opschoning met vastgezette acties, expliciete machtigingen, pull_request_target gating, 2FA voor leden, geïnstalleerde GitHub-apps en implementatiesleutels. Wat voorheen een halve dag speurwerk in spreadsheets was, wordt nu een enkel commando dat JSON en Markdown genereert. De kwartaalbeoordeling tussen de CISO en org-beheerders worden een decisHet is geen dataverzamelingsvergadering, maar een vergadering waarin concrete bevindingen worden omgezet in achterstanden met op ernst gebaseerde SLA's.

Een whitelist-beleid, inclusief goedgekeurde beheerders, goedgekeurde apps en machtigingen per functie voor repositories en workflows, moet als YAML-bestand worden opgeslagen in een versiebeheerde repository, die wordt gecontroleerd door het beveiligingsteam na een pull request-review. Elke wijziging in de whitelist laat een review-spoor achter, waardoor automatisch auditbewijs wordt gegenereerd. Het effect hiervan is dat controles die voorheen ambitieus waren, zoals "we zouden elk kwartaal een audit moeten uitvoeren", routinematig worden, zoals "de audit van dit kwartaal is maandag binnengekomen", en dat de organisatie een herhaalbaar mechanisme krijgt voor het detecteren van afwijkingen, wat het end-to-end-principe vereist.

De wrijvingen waar je rekening mee moet houden

Technische controles zijn het makkelijke deel. Mensen zijn lastiger.

Het meest sprekende voorbeeld zijn bijna altijd CODEOWNERS. Het toevoegen van .github/workflows/ @your-org/security Het lijkt misschien triviaal om dit in elke repository te doen. Eén bestand, één regel. Maar het betekent dat engineers die al jaren zelf workflowwijzigingen samenvoegen, nu een beveiligingscontrole nodig hebben. Zelfs mensen die zich bewust zijn van beveiliging, reageren hierop: ik heb deze workflow geschreven, ik begrijp hem, waarom moet ik wachten?

Een echt gesprek is nodig om de achterliggende redenen te achterhalen. Werkprocessen kunnen inloggegevens lekken, gegevens omleiden en downstream-gebruikers schade berokkenen. Een tweede paar ogen is geen teken van wantrouwen; het is dezelfde logica als vier ogen bij wijzigingen in productiedatabases. Het is enorm nuttig om een ​​concreet, recent incident in de toeleveringsketen aan te halen, of dat nu uit de branche of uw eigen omgeving komt. Niets maakt een controle zo duidelijk als een concreet voorbeeld van de afwezigheid ervan.

Andere wrijvingen volgen dezelfde vorm:

• Expliciete machtigingen: Blokkades in workflows veroorzaken CI-fouten totdat bijdragers de beperkte machtigingen begrijpen. Dit is geen probleem met machtigingen, maar een probleem met het mentale model.
• Onveranderlijkheid van tags: Het verbreekt de werking van release-tools die al jarenlang stilletjes tags wijzigen.
• Ondertekend commits: Dit zorgt voor wrijving tijdens het onboardingproces totdat GPG- of SSH-sleutels correct zijn ingesteld op alle werkstations. SPVS maakt dit verplicht voor elke repository en bijdrager, niet alleen voor de belangrijkste.
• Vervanging van klassieke persoonlijke toegangstokens: Verspreid over talloze repositories en workflowbestanden, raakt vrijwel elk team.

Het patroon dat werkt: introduceer elke controle met een specifieke dreiging die deze blokkeert, test deze op één of twee repositories, rol deze uit met uitzonderingen op de whitelist en verwijder de uitzonderingen volgens een vastgestelde planning. De engineers die zich aanvankelijk het meest verzetten, worden vaak de grootste voorstanders zodra ze de onderliggende logica begrijpen.

Nog een belangrijk punt: het end-to-end-principe is hier cruciaal. Je kunt niet selectief te werk gaan. Het versterken van de bouwfase terwijl het releasebeheer losgelaten wordt, wekt een vals gevoel van veiligheid, en dat is precies de valkuil waar de SPVS-auteurs op wijzen. Elke fase moet synchroon verlopen, zelfs als een specifieke controle op zichzelf onevenredig belangrijk lijkt.

Kosten: Ongeveer een maand aan engineeringtijd voor Fase 1, gericht op L2-compliance voor een kleine organisatie, verdeeld over DevOps, beveiliging en technische reviewers. De investering betaalt zich gemakkelijk terug. Eén voorkomen incident in de toeleveringsketen dekt de kosten ruimschoots. Grotere organisaties zouden proportioneel meer moeten budgetteren, maar de gefaseerde structuur van L1 naar L2 naar L3 zorgt ervoor dat er al waarde wordt geleverd voordat het programma is afgerond.

Wat volgt?

SPVS v1.5 komt eraan met AI-gerelateerde controles: herkomst van door AI ondersteunde code, guardrails Voor CI-workflows die LLM's aanroepen, bekijk de testresultaten voor door AI gegenereerde gegevens. pull requestsen verdediging tegen opkomende bedreigingen zoals slopsquatting, waarbij aanvallers pakketnamen registreren die AI-codeerassistenten hallucineren, en de operationele, door AI gegenereerde malware die CrowdStrike in de praktijk rapporteert. Organisaties die al AI-ondersteunde software taggen commits en PR's zullen deze aanpassing in hun interne ontwikkelingsrichtlijnen eerder als een stapsgewijze verandering beschouwen dan als een geheel nieuw werkprogramma.

Versie 2.0 zal naar verwachting de runtime-monitoring en de vereisten voor de levenscyclus van inloggegevens verder verbeteren. Een redelijke organisatorische roadmap: de resterende L3-lacunes dichten tegen het einde van het tweede kwartaal van 2026, inclusief SLSA provenance geïntegreerd standard CI/CDHandmatige toegangspoorten voor productie-implementaties en een gecentraliseerde identiteitsprovider, waarna wordt overgeschakeld naar de onderhoudsmodus. Elke nieuwe repository voldoet aan de vereisten en elke kwartaalaudit spoort afwijkingen vroegtijdig op.

Hartelijk dank aan Farshad Abasi, Cameron Walters en de OWASP SPVS-werkgroep. Projecten zoals dit leggen de lat lager voor elke organisatie die de beveiliging van de toeleveringsketen systematisch wil aanpakken in plaats van reactief.

Key Takeaways

Een paar dingen die ook buiten onze specifieke context van toepassing zijn:

• Om het te proberen: Download het CSV-bestand met de SPVS-vereisten en breng uw huidige beheersmaatregelen in kaart in een spreadsheet. U weet binnen een dag of het voldoet.
• Kies één streefniveau en lever dat af voordat je naar het volgende niveau gaat. L1 naar L2 naar L3 is een kenmerk, geen beperking.
• Het pipeline is het doelwit. Toepassingsgerichte controles zijn noodzakelijk, maar niet voldoende; behandel de pipeline als een eersteklas aanvalsoppervlak.
• Controleer het geheel pipeline, niet één stuk. Sterke afhankelijkheidsscans compenseren niet voor zwak releasebeheer of onvoldoende gecontroleerde buildomgevingen.
• Spreadsheets zijn momentopnamen; afwijking is een continu proces. Ontwikkel automatisering, zelfs een bescheiden interne tool, om afwijkingen tussen audits te detecteren.
• Het organisatorische werk is moeilijker dan het technische werk. Plan tijd in voor overleg en een proefimplementatie, en leg uit welke specifieke dreiging elk controlemiddel afweert.

Om meer te lezen

• OWASP: Beveilig Pipeline Verificatie Standard (SPVS) v1.0OWASP-projectpagina.
• Farshad Abasi: Waarom we OWASP SPVS hebben gecreëerdOWASP SPVS-artikelen.
• Farshad Abasi: Pipeline De aanvallen worden steeds erger. Zo kunt u zich voorbereiden.OWASP SPVS-artikelen.
• Farshad Abasi: OWASP SPVS versus andere raamwerken voor de toeleveringsketenOWASP SPVS-artikelen.
• OWASP: Top 10 CI/CD Veiligheidsrisico'sOWASP-projectpagina.
• SLSA: Supply-chain-niveaus voor software-artefactenslsa.dev.
• OpenSSF: Score kaart. securityscorecards.dev.