Jare lank het aanvallers toepassings een op 'n slag aangeval. Hulle het taktiek verander: hoekom een toepassing kompromitteer as jy die ander kan kompromitteer? pipeline wat baie bou? Xygeni se Vroeë Waarskuwing oor Wanware (MEW) opgespoor 4 452 kwaadwillige pakkette in 2025 en 1 281 meer in 2026 tot dusverElke hoëprofielvoorval van die afgelope paar jaar het 'n ander skakel in die sagteware-leweringsketting getref:
- SolarWinds (2020): bou-omgewing-kompromie; agterdeur-opdaterings gestuur na 18 000 kliënte.
- Kodekov (2021)'n Verkeerd gekonfigureerde Docker-beeld het aanvallers toegelaat om 'n bash-oplaaierskrip te wysig en sodoende KI-geheime van meer as 23 000 kliënte te steel.
- SirkelCI (2023)sessiekoekie-diefstal op 'n ingenieur se skootrekenaar het in produksietoegangstokens omskep; elke kliënt is aangesê om elke geheim te roteer.
- XZ gebruik agterdeur (2024) 'n meerjarige sosiale manipulasieveldtog wat byna elke Linux-verspreiding bereik het.
- tj-aksies (2025) — 'n GitHub Actions-voorsieningskettingkaskade wat 'n komponent wat deur meer as 23 000 bewaarplekke gebruik word, vergiftig het.
- Aanvalle op Aqua Trivy en checkmarx (2026) — die TeamPCP-veldtog het twee wydgebruikte sekuriteitskandeerders in aanvalsvektore omskep en toe die gesteelde gebruik CI/CD geloofsbriewe om stroomaf in npm, OpenVSX en PyPI te kaskadeer.
Elke aanval het 'n ander deel van die pipeline: bou-omgewing, KI-gereedskap, afhanklikhede, ontwikkelaarbewyse, onderhouervertroue, veranderlike verwysings na artefakte. Die meeste organisasies reageer met puntbeheer, 'n skandeerder in KI, 2FA op die IdP, takbeskerming op mainWat gewoonlik ontbreek, is 'n manier om te vra word ons sistematies gedek? eerder as Het ons onthou om X te aktiveer na die laaste voorval?
Verskaffers van toepassingssekuriteit sit vierkantig in die visier, wat kompromitteer dat een elke kliënt bereik wat sy artefakte vertrou. Die druk om van reaktiewe beheermaatreëls na 'n sistematiese houding oor te skakel, is nie teoreties nie. Dit is voorafcispresies wat die aanneming van die OWASP SPVS gemotiveer het standard as 'n topprioriteitsprojek.
Wat SPVS is, en waarom die struktuur saak maak
Die oorsprongsverhaal is eenvoudig. By LASCON 2023 het Farshad Abasi en Cameron Walters mekaar aanhoudend dieselfde vraag gevra: waar is die ASVS vir... pipelines? OWASP ASVS het toepassingssekuriteit 'n omvattende, verifieerbare standardNiks ekwivalent het bestaan vir CI/CD.
Daar was die OWASP Top 10 CI/CD Risiko's, wat bewustheidsgerig was, nie toetsbaar nie; SLSA, wat slegs op bou-herkoms gefokus het; S2C2F, wat slegs op afhanklikheidsverbruik gefokus het; en OpenSSF Telkaart, wat spesifieke bewaarplekkontroles gedek het. Elkeen het 'n stukkie gedek. Geeneen het die geheel gedek nie.
| Raamwerk of Projek | Primêre Bestek |
|---|---|
| OWASP Top 10 CI/CD Risiko's | Bewustheidsgerig CI/CD risiko-leiding, nie 'n toetsbare verifikasie nie standard. |
| SLSA | Bou herkoms- en artefak-integriteit. |
| S2C2F | Veilige afhanklikheidsverbruik. |
| OpenSSF telkaart | Spesifieke sekuriteitskontroles op bewaarplekvlak. |
Die gaping: elke raamwerk het 'n belangrike stuk gedek software supply chain security, maar geeneen het 'n end-tot-end, verifieerbare verskaf nie standard vir die geheel CI/CD pipeline.
Daardie gesprek het twee jaar se werk geword, en in Oktober 2025 het die SPVS-werkgroep v1.0 vrygestel: 127 vereistes oor die lewensiklus, Beplan, Ontwikkel, Integreer, Vrystel, Bedryf, gestratifiseer in drie volwassenheidsvlakke: L1 Fundamenteel, L2 Standard, en L3 Gevorderd. Elke vereiste is gekarteer na NIST SP 800-53, OWASP CI/CD Top 10, en CWE.
Die struktuur is die punt. In die SPVS-outeurs se eie woorde:
"Verifieer jou hele pipeline, nie net een stuk nie. Dit is waar die meeste organisasies sukkel. Hulle skandeer afhanklikhede, maar ignoreer vrystellingsbestuur. Hulle teken artefakte, maar bedreigingsmodelleer nie hul pipeline argitektuur. Hulle monitor produksie, maar nie hul bou-omgewings nie.”
Dit is waar die meeste organisasies sukkel. Hulle skandeer afhanklikhede, maar ignoreer vrystellingsbeheer. Hulle teken artefakte, maar bedreigingsmodelleer nie hul ... pipeline argitektuur. Hulle monitor produksie, maar nie hul bou-omgewings nie.
Dit is die tesis wat die poging regverdig. Sterkpunte in een stadium vergoed nie vir swakpunte in 'n ander nie. Aanvallers benodig slegs een skakel om te breek. 'n Lewensiklus standard dwing jou om almal na te gaan, en die L1 na L2 na L3 progressie laat jou dit doen sonder om die see te kook. SPVS vervang nie SLSA, S2C2F, Scorecard of Sigstore nie; dit gee jou die steierwerk wat jou vertel waar elkeen van hulle pas.
Die aanpassing van die Standard aan u organisasie
Die natuurlike eerste stap is 'n direkte oudit van jou organisasie en sagteware-infrastruktuur teenoor elke vereiste. 'n Google Sheet afgelei van die amptelike SPVS-vereistes CSV werk goed as 'n beginpunt. Drie aansigte is nuttig: 'n vereistematriks met status en eienaar per kontrole, 'n hittekaart per bewaarplek, en 'n dashboard van vordering per stadium en vlak. Die uitset word natuurlik in 'n tegniese padkaart ingesluit, 'n lewende dokument wat elke stadium van plan tot bedryf dek.
Die meeste volwasse ingenieursorganisasies sal hulself reeds rondom L2 bevind wanneer hulle hierdie aanvanklike kartering doen. Dit is eintlik 'n goeie posisie: dit beteken dat die eerste fase kan fokus op die sluiting van spesifieke gapings eerder as om fondamente van nuuts af te bou.
'n Sigblad is egter 'n momentopname, en SPVS vra vir meer. V1.1.7 vereis 'n kwartaallikse oudit van VCS-administrateurs; V5.1.1 tot V5.1.3 voeg gereelde gebruikersoudits, toegangslogboekhersiening en monitering van bevoorregte toegang by; verskeie V2.1.x-, V3.3.x- en V4.2.x-kontroles vereis deurlopende werkvloei-YAML-higiëne. Dit word met die hand regdeur die organisasie uitgevoer, dit is 'n halfdag van klikopsporing elke kwartaal met 'n werklike risiko van stil weglatings. Dit is die soort werk wat óf outomaties word óf eers hersien word nadat iets slegs gebeur het.
Sommige SPVS-kontroles is nie eenmalige kontrolelysitems nie. Hulle vereis herhalende hersiening, ouditbewyse en drywingsopsporing oor bewaarplekke, gebruikers, werkvloeie en bevoorregte toegang.
| SPVS-gebied | Tipe vereiste |
|---|---|
V1.1.7 | Kwartaallikse oudit van VCS-administrateurs. |
V5.1.1–V5.1.3 | Gereelde gebruikersoudits, toegangslogboekhersiening en monitering van bevoorregte toegang. |
V2.1.x, V3.3.x, V4.2.x | Deurlopende werkvloei YAML-higiëne. |
Die antwoord is om gereedskap te bou of aan te neem wat onder die organisasie-eienaar-identiteit loop en 'n gestruktureerde kwartaallikse bundel produseer: administrateurlys, takbeskerming, KODE-EIENAARS-dekking, werkvloei YAML-higiëne met vasgespelde aksies, eksplisiete toestemmings, pull_request_target poortbeheer, lid 2FA, GitHub-programme geïnstalleer en sleutels ontplooi. Wat voorheen 'n halfdag van sigbladargeologie was, word 'n enkele opdrag wat JSON en Markdown uitstuur. Die kwartaallikse oorsig tussen die CISO- en organisasie-administrateurs word 'n decis'n Ioonvergadering, nie 'n data-insamelingsvergadering nie, en aksiebare bevindinge word agterstandkwessies met ernstigheidsgebaseerde SLA's.
'n Toelaatlysbeleid, insluitend goedgekeurde administrateurs, goedgekeurde toepassings en toestemmings per funksie vir bewaarplekke en werkvloeie, moet as YAML in 'n weergawe-beheerde bewaarplek leef, gekontroleer deur PR-hersiening van die sekuriteitspan. Enige verandering aan die toelaatlys laat 'n hersieningsspoor agter, sodat ouditbewyse homself genereer. Die effek is om kontroles wat aspirasioneel was, soos "ons moet kwartaalliks oudit," te omskep in kontroles wat roetine is, soos "hierdie kwartaal se oudit het Maandag plaasgevind," en om die organisasie 'n herhaalbare meganisme te gee vir die drywingsopsporing wat die end-tot-end-beginsel vereis.
Die wrywings waarvoor jy moet beplan
Tegniese beheermaatreëls is die maklike deel. Mense is moeiliker.
Die uitstaande voorbeeld is amper altyd KODE-EIENAARS. .github/workflows/ @your-org/security op elke repository klink triviaal. Een lêer, een reël. Maar dit beteken ingenieurs wat jare lank self werkvloeiveranderinge saamsmelt, benodig nou 'n sekuriteitshersiening. Selfs sekuriteitsbewuste mense weerspreek: Ek het hierdie werkvloei geskryf, ek verstaan dit, hoekom wag ek?
Dit verg ware gesprek om die rede vas te stel. Werkvloei kan geloofsbriewe steel, artefakte herlei en verbruikers stroomaf vergiftig. 'n Tweede paar oë is nie wantroue nie; dit is dieselfde logika as vier oë op produksiedatabasisveranderinge. Om 'n konkrete, onlangse voorsieningskettingvoorval te hê om na te wys, hetsy uit die bedryf of jou eie omgewing, help geweldig. Niks kristalliseer 'n beheermaatreël soos 'n werklike voorbeeld van sy afwesigheid nie.
Ander wrywings volg dieselfde vorm:
- Eksplisiete toestemmings: blokke in werkvloei veroorsaak CI-mislukkings totdat bydraers die omvang van toestemmings verstaan. Dit is nie 'n toestemmingsprobleem nie, maar 'n mentale-model probleem.
- Etiket onveranderlikheid: breek vrystellingsgereedskap wat jare lank stilweg hermerk het.
- onderteken commits: skep wrywing tydens aanboord totdat GPG- of SSH-sleutels korrek oor werkstasies opgestel is. SPVS maak dit verpligtend oor elke bewaarplek en bydraer, nie net die hoofbewaarplekke nie.
- Vervanging van klassieke persoonlike toegangstokens: oor baie bewaarplekke en werkvloeilêers raak byna elke span.
Die patroon wat werk: stel elke kontrole bekend met 'n spesifieke bedreiging wat dit blokkeer, loods dit op een of twee bewaarplekke, rol dit uit met uitsonderings op 'n toegelate lys, en tree die uitsonderings terug op 'n gedefinieerde tydlyn. Die ingenieurs wat die hardste terugdruk, word meer dikwels as nie die sterkste voorstanders sodra hulle die rasionaal sien.
Een dieper punt: die end-tot-end-beginsel raak hier. Jy kan nie kies en keur nie. Om die boufase te verhard terwyl vrystellingsbeheer losgelaat word, gee valse vertroue, wat presies die mislukkingsmodus is wat die SPVS-outeurs uitwys. Elke fase moet saam vorder, selfs wanneer 'n spesifieke beheer in isolasie disproporsioneel voel.
Koste: ongeveer 'n maand se ingenieurstyd vir Fase 1, gefokus op L2-nakoming vir 'n klein organisasie, versprei oor DevOps-, Sekuriteits- en ingenieursbeoordelaars. Die belegging betaal maklik terug. 'n Enkele voorkomende voorsieningskettingvoorval dek dit baie keer oor. Groter organisasies behoort proporsioneel meer te begroot, maar die gefaseerde L1-na-L2-na-L3-struktuur beteken dat waarde gelewer word voordat die program voltooi is.
Wat is volgende?
SPVS v1.5 is op die horison met KI-verwante beheermaatreëls: herkoms van KI-ondersteunde kode, guardrails vir KI-werkvloeie wat LLM's aanroep, hersien roetes vir KI-gegenereerde pull requests, en verdediging teen opkomende bedreigings soos slopsquatting, waar aanvallers pakketname registreer wat KI-koderingsassistente hallusineer, en die operasionele KI-gegenereerde wanware wat CrowdStrike in die natuur rapporteer. Organisasies wat reeds KI-ondersteunde commits en PR's in hul interne ontwikkelingsriglyne sal hierdie aanpassing inkrementeel eerder as 'n nuwe werkprogram vind.
Weergawe 2.0 sal na verwagting looptydmonitering en die vereistes vir geloofsbriewe se lewensiklus verdiep. 'n Redelike organisatoriese padkaart: sluit die oorblywende L3-gapings teen die einde van K2 2026, insluitend SLSA provenance diens in standard CI/CD, handmatige hekke vir produksie-ontplooiings, en gesentraliseerde identiteitsverskaffer, en skakel dan oor na instandhoudingsmodus. Elke nuwe bewaarplek begin voldoenend, en elke kwartaallikse oudit vang vroegtydig afdrywing op.
'n Opregte dankie aan Farshad Abasi, Cameron Walters, en die OWASP SPVS-werkgroep. Projekte soos hierdie verlaag die lat vir elke organisasie wat voorsieningskettingsekuriteit sistematies eerder as reaktief wil doen.
Belangrike take
'n Paar dinge wat verder as ons spesifieke konteks vertaal:
- Om dit te probeer: Laai die SPVS-vereistes CSV af en karteer jou huidige beheermaatreëls in 'n sigblad. Jy sal binne 'n dag weet of dit pas.
- Kies een teikenvlak en stuur dit voordat jy na die volgende reik. L1 tot L2 tot L3 is 'n kenmerk, nie 'n beperking nie.
- Die pipeline is die teiken. Toepassingsgesentreerde beheermaatreëls is nodig, maar nie voldoende nie; behandel die pipeline as 'n eersteklas aanvalsoppervlak.
- Verifieer die geheel pipeline, nie een stuk nie. Sterkte in afhanklikheidskandering maak nie op vir swak vrystellingsbeheer of ongemonitorde bou-omgewings nie.
- Sigblaaie is momentopnames; drywing is aanhoudend. Bou outomatisering, selfs 'n beskeie interne instrument, om verskille tussen oudits op te spoor.
- Die organisatoriese werk is moeiliker as die tegniese werk. Begroot tyd vir gesprek en loodsprojek voor uitrol, en verduidelik die spesifieke bedreiging wat elke beheermaatreël blokkeer.
Om Meer te Lees
- OWASP: Beveilig Pipeline Verifikasie Standard (SPVS) v1.0OWASP Projek Bladsy.
- Farshad Abasi: Waarom ons OWASP SPVS geskep hetOWASP SPVS Artikels.
- Farshad Abasi: Pipeline Aanvalle word erger. Hier is hoe om voor te berei.OWASP SPVS Artikels.
- Farshad Abasi: OWASP SPVS teenoor ander voorsieningskettingraamwerkeOWASP SPVS Artikels.
- OWASP: Top 10 CI/CD Sekuriteitsrisiko'sOWASP Projek Bladsy.
- SLSA: Voorsieningskettingvlakke vir sagteware-artefakteslsa.dev.
- OpenSSF: telkaart. sekuriteitstelkaarte.ontwikkeling.
