Napadalci so leta napadali aplikacije eno za drugo. Spremenili so taktiko: zakaj bi ogrozili eno aplikacijo, ko lahko ogrozite pipeline ki gradi veliko? Xygenijev Zgodnje opozorilo o zlonamerni programski opremi (MEW) Zaznali 4,452 zlonamernih paketov v letu 2025 in 1,281 več v letu 2026 doslejVsak odmevnejši incident iz zadnjih nekaj let je zadel drugačen člen v verigi dobave programske opreme:
- SolarWinds (2020)ogrožanje okolja za gradnjo; posodobitve z zakulisjem so bile poslane 18,000 strankam.
- Codecov (2021)Napačno konfigurirana slika Dockerja je napadalcem omogočila spreminjanje skripte za nalaganje v bash in s tem odkritje skrivnosti CI več kot 23,000 strank.
- CircleCI (2023): kraja sejnih piškotkov na prenosniku inženirja se je spremenila v žetone za dostop do produkcije; vsaki stranki je bilo naročeno, naj posreduje vse skrivnosti.
- Zadnja vrata XZ Utils (2024) Večletna kampanja socialnega inženiringa, ki je dosegla skoraj vse distribucije Linuxa.
- tj-akcije (2025) — kaskada dobavne verige GitHub Actions, ki je zastrupila komponento, ki jo uporablja več kot 23,000 repozitorijev.
- Napadi na Vodni kviz in checkmarkx (2026) — kampanja TeamPCP je dva široko uporabljena varnostna skenerja spremenila v vektorja napada, nato pa ukradena CI/CD poverilnice za kaskadno prenos v npm, OpenVSX in PyPI.
Vsak napad je izkoristil drugačen del pipeline: okolje za gradnjo, orodja za CI, odvisnosti, poverilnice razvijalca, zaupanje vzdrževalca, spremenljive reference na artefakte. Večina organizacij se odziva s točkovnim nadzorom, skenerjem v CI, 2FA na ponudniku identitetnih storitev (IdP), zaščito vej na mainObičajno manjka način, kako vprašati. Ali smo sistematično pokriti? ne Smo se spomnili omogočiti X po zadnjem incidentu?
Ponudniki varnosti aplikacij so trdno v središču pozornosti in ogrožajo doseg vsakega kupca, ki zaupa njegovim artefaktom. Pritisk za prehod z reaktivnih kontrol na sistematično držo ni teoretičen. To je vnaprejciskaj je motiviralo sprejetje OWASP SPVS standard kot projekt najvišje prioritete.
Kaj je SPVS in zakaj je struktura pomembna
Zgodba o nastanku je preprosta. Na LASCON 2023 sta se Farshad Abasi in Cameron Walters nenehno spraševala isto vprašanje: kje je ASVS za pipelines? OWASP ASVS je varnosti aplikacij zagotovil celovito in preverljivo standardNič enakovrednega ni obstajalo za CI/CD.
Tam je bila lestvica OWASP Top 10 CI/CD Tveganja, ki so bila usmerjena v ozaveščanje in niso bila preizkušljiva; SLSA, ki se je osredotočala le na izvor gradnje; S2C2F, ki se je osredotočala le na porabo odvisnosti; in OpenSSF Preglednica rezultatov, ki je zajemala specifične preglede repozitorija. Vsak je zajemal en del. Noben ni zajemal celote.
| Okvir ali projekt | Primarni obseg |
|---|---|
| 10 najboljših OWASP CI/CD Tveganja | Ozaveščeno usmerjeno CI/CD smernice za ugotavljanje tveganja, ne pa preverljivo preverjanje standard. |
| SLSA | Zgradite izvor in integriteto artefaktov. |
| S2C2F | Varna poraba odvisnosti. |
| OpenSSF Preglednica | Specifična varnostna preverjanja na ravni repozitorija. |
Vrzel: vsak okvir je zajemal pomemben del software supply chain security, vendar noben ni zagotovil preverljivega celovitega standard za celoto CI/CD pipeline.
Ta pogovor se je razvil v dveletno delo in oktobra 2025 je delovna skupina SPVS izdala različico 1.0: 127 zahtev v celotnem življenjskem ciklu: načrtovanje, razvoj, integracija, izdaja, upravljanje, stratificirano v tri stopnje zrelosti: L1 temeljna, L2 Standardin L3 Advanced. Vsaka zahteva je preslikana v NIST SP 800-53, OWASP CI/CD Top 10 in CWE.
Bistvo je struktura. Po besedah avtorjev SPVS:
"Preverite celotno pipeline, ne le en kos. Tukaj se večina organizacij spopada s težavami. Skenirajo odvisnosti, vendar ignorirajo upravljanje izdaj. Podpisujejo artefakte, vendar ne modelirajo groženj za svoje pipeline arhitektura. Spremljajo produkcijo, ne pa tudi gradbenih okolij.“
Tukaj se večina organizacij spopada s težavami. Pregledujejo odvisnosti, vendar ignorirajo upravljanje izdaj. Podpisujejo artefakte, vendar ne modelirajo groženj za svoje pipeline arhitekturo. Spremljajo produkcijo, ne pa tudi gradbenih okolij.
To je teza, ki upravičuje trud. Prednosti v eni fazi ne nadomestijo slabosti v drugi. Napadalci potrebujejo le eno povezavo, da jo pretrgajo. Življenjski cikel standard Prisili vas, da preverite vse, napredovanje od L1 do L2 do L3 pa vam omogoča, da to storite, ne da bi pri tem zavreli ocean. SPVS ne nadomešča SLSA, S2C2F, Scorecard ali Sigstore; ponuja vam ogrodje, ki vam pove, kam vsak od njih spada.
Prilagajanje Standard vaši organizaciji
Naraven prvi korak je neposredna revizija vaše organizacije in programske infrastrukture glede na vsako zahtevo. Google Preglednica, ki je bila uporabljena iz uradne Zahteve SPVS v obliki CSV deluje dobro kot izhodišče. Uporabni so trije pogledi: matrika zahtev s statusom in lastnikom za vsak kontrolnik, toplotni zemljevid za vsak repozitorij in dashboard napredka po fazah in ravneh. Rezultat se naravno vključi v tehnični načrt, živi dokument, ki zajema vse faze od načrta do delovanja.
Večina zrelih inženirskih organizacij se bo ob tem začetnem kartiranju že znašla nekje na drugi ravni. To je pravzaprav dober položaj: pomeni, da se lahko prva faza osredotoči na zapolnitev določenih vrzeli in ne na gradnjo temeljev iz nič.
Preglednica pa je le posnetek stanja, SPVS pa zahteva več. V1.1.7 predpisuje četrtletno revizijo skrbnikov VCS; V5.1.1 do V5.1.3 dodajajo redne revizije uporabnikov, pregled dnevnika dostopov in spremljanje privilegiranega dostopa; več kontrolnikov V2.1.x, V3.3.x in V4.2.x zahteva stalno higieno poteka dela v YAML. Izvaja se ročno po vsej organizaciji, kar pomeni pol dneva sledenja klikom vsako četrtletje z resničnim tveganjem tihih opustitev. To je vrsta dela, ki se bodisi avtomatizira bodisi pregleda šele, ko se zgodi kaj slabega.
Nekateri kontrolniki SPVS niso enkratni elementi kontrolnega seznama. Zahtevajo ponavljajoče se preglede, revizijske dokaze in zaznavanje premikov med repozitoriji, uporabniki, delovnimi tokovi in privilegiranim dostopom.
| Območje SPVS | Vrsta zahteve |
|---|---|
V1.1.7 | Četrtletna revizija administratorjev VCS. |
V5.1.1–V5.1.3 | Redni pregledi uporabnikov, pregled dnevnika dostopov in spremljanje privilegiranega dostopa. |
V2.1.x, V3.3.x, V4.2.x | Higiena YAML v teku dela. |
Odgovor je v izgradnji ali uvedbi orodij, ki delujejo pod identiteto lastnika organizacije in ustvarjajo strukturiran četrtletni paket: skrbniški seznam, zaščita vej, pokritost CODEOWNERS, higiena poteka dela YAML s pripetimi dejanji, eksplicitna dovoljenja, pull_request_target gating, član 2FA, nameščene aplikacije GitHub in uvajanje ključev. Kar je bilo prej pol dneva arheologije preglednic, se zdaj spremeni v en sam ukaz, ki oddaja JSON in Markdown. Četrtletni pregled med CISO in skrbniki organizacij postanejo decissestanek za ionologijo in ne sestanek za zbiranje podatkov, ugotovitve, na podlagi katerih je mogoče ukrepati, pa postanejo zaostanki pri sporazumih o ravni storitev, ki temeljijo na resnosti.
Pravilnik o dovoljenem seznamu, vključno z odobrenimi skrbniki, odobrenimi aplikacijami in dovoljenji po funkcijah za repozitorije in poteke dela, bi moral obstajati kot YAML v repozitoriju z nadzorom različic, ki ga varnostna ekipa pregleda s strani oddelka za odnose z javnostmi. Vsaka sprememba dovoljenega seznama pusti sled pregleda, zato se revizijski dokazi ustvarijo sami. Učinek je, da se nadzor, ki je bil ambiciozen, kot je »revidirati bi morali četrtletno«, spremeni v rutinske kontrole, kot je »revizija tega četrtletja je pristala v ponedeljek«, in da se organizaciji zagotovi ponovljiv mehanizem za zaznavanje odstopanj, ki ga zahteva načelo od začetka do konca.
Trenja, na katera morate biti pozorni
Tehnične kontrole so lažji del. Ljudje so težji.
Izstopajoč primer so skoraj vedno LASTNIKI KODE. Dodajanje .github/workflows/ @your-org/security "Na vsakem repozitoriju" se sliši nepomembno. Ena datoteka, ena vrstica. Ampak to pomeni, da inženirji, ki že leta sami združujejo spremembe delovnega toka, zdaj potrebujejo varnostni pregled. Celo ljudje, ki se zavedajo varnosti, se upira: "Ta delovni tok sem napisal jaz, razumem ga, zakaj čakam?"
Za ugotavljanje vzroka je potreben resen pogovor. Poteki dela lahko izvlečejo poverilnice, preusmerijo artefakte in zastrupijo potrošnike na nižji stopnji. Drugi par oči ni nezaupanje; gre za isto logiko kot štiri oči pri spremembah produkcijske baze podatkov. Če imate konkreten, nedavni incident v dobavni verigi, na katerega se lahko opozorite, bodisi iz panoge bodisi iz lastnega okolja, to izjemno pomaga. Nič ne kristalizira nadzora tako kot resničen primer njegove odsotnosti.
Druga trenja sledijo isti obliki:
- Izrecna dovoljenja: Bloki v delovnih procesih povzročajo napake CI, dokler sodelavci ne razumejo omejenih dovoljenj. To ni težava z dovoljenji, temveč težava z miselnim modelom.
- Nespremenljivost oznake: prekine orodje za izdajo, ki je leta tiho ponovno označevalo.
- Podpisano commits: ustvarjajo trenja pri uvajanju, dokler ključi GPG ali SSH niso pravilno nastavljeni na vseh delovnih postajah. SPVS to zahteva v vseh repozitorijih in prispevkih, ne le v glavnih.
- Zamenjava klasičnih žetonov za osebni dostop: v številnih repozitorijih in datotekah delovnega toka se dotakne skoraj vsake ekipe.
Vzorec, ki deluje: vsak nadzor predstavite s specifično grožnjo, ki jo blokira, ga preizkusite v enem ali dveh repozitorijih, ga uvedite z izjemami na seznamu dovoljenih in izjeme umaknite v določenem časovnem okviru. Inženirji, ki se najbolj upirajo, postanejo najmočnejši zagovorniki, ko enkrat vidijo utemeljitev.
Še globlja točka: tukaj je ključnega pomena načelo od začetka do konca. Ne morete izbirati. Zaostritev faze gradnje ob hkratnem ohlapnem upravljanju izdaje daje lažno zaupanje, kar je ravno tisti način neuspeha, ki ga izpostavljajo avtorji SPVS. Vsaka faza mora napredovati skupaj, tudi če se določen nadzor zdi nesorazmeren sam po sebi.
Cena: Približno mesec dni je porabljenega inženirskega časa za 1. fazo, osredotočenega na skladnost z L2 za majhno organizacijo, razdeljenega med oddelke DevOps, varnost in inženirske pregledovalce. Naložba se zlahka povrne. En sam preprečen incident v dobavni verigi pokrije stroške večkrat. Večje organizacije bi morale sorazmerno povečati proračun, vendar fazna struktura od L1 do L2 do L3 pomeni, da je vrednost dosežena, še preden je program končan.
Kaj sledi
SPVS v1.5 je na obzorju z nadzorom, povezanim z umetno inteligenco: izvor kode, podprte z umetno inteligenco, guardrails za delovne procese CI, ki kličejo LLM-je, preglejte sledi za ustvarjene z umetno inteligenco pull requestsin obrambo pred novimi grožnjami, kot je površno prisilno prisvajanje (slopsquatting), kjer napadalci registrirajo imena paketov, ki si jih asistenti za kodiranje z umetno inteligenco predstavljajo, in operativno zlonamerno programsko opremo, ki jo ustvari umetna inteligenca in o kateri CrowdStrike poroča v praksi. Organizacije, ki že označujejo programsko opremo s pomočjo umetne inteligence commitDirektorji in osebni referenti bodo v svojih smernicah za notranji razvoj to prilagoditev ocenili kot postopno in ne kot nov program dela.
Pričakuje se, da bo različica 2.0 poglobila spremljanje izvajanja in zahteve glede življenjskega cikla poverilnic. Razumen organizacijski načrt: odprava preostalih vrzeli na ravni L3 do konca drugega četrtletja 2026, vključno z SLSA provenance vključiti v standard CI/CD, ročna vrata za produkcijske uvedbe in centraliziran ponudnik identitet, nato pa preklopijo v način vzdrževanja. Vsak nov repozitorij se začne skladati s predpisi in vsaka četrtletna revizija odkrije prezgodnje odmike.
Iskrena zahvala Farshadu Abasiju, Cameronu Waltersu in delovni skupini OWASP SPVS. Takšni projekti znižujejo standarde za vsako organizacijo, ki želi sistematično in ne reaktivno zagotavljati varnost dobavne verige.
Ključni izdelki
Nekaj stvari, ki presegajo naš specifični kontekst:
- Če želite poskusiti: Prenesite datoteko CSV z zahtevami SPVS in v preglednico vnesite svoje trenutne kontrole. V enem dnevu boste vedeli, ali ustreza.
- Izberi eno ciljno raven in jo pošlji, preden se lotiš naslednje. Od L1 do L2 do L3 je funkcija, ne omejitev.
- Naš pipeline je cilj. Kontrole, osredotočene na aplikacije, so potrebne, vendar ne zadostne; obravnavajte pipeline kot prvovrstna napadalna površina.
- Preverite celoto pipeline, ne enega kosa. Moč pri skeniranju odvisnosti ne nadomesti šibkega upravljanja izdaj ali nenadzorovanih okolij za gradnjo.
- Preglednice so posnetki; premik je neprekinjen. Zgradite avtomatizacijo, četudi skromno interno orodje, za zaznavanje odstopanj med revizijami.
- Organizacijsko delo je težje od tehničnega. Pred uvedbo načrtujte čas za pogovor in pilotni projekt ter pojasnite specifično grožnjo, ki jo posamezen nadzor blokira.
Več informacij
- OWASP: Varnost Pipeline Preverjanje Standard (SPVS) v1.0Stran projekta OWASP.
- Faršad Abasi: Zakaj smo ustvarili OWASP SPVSČlanki OWASP SPVS.
- Faršad Abasi: Pipeline Napadi se stopnjujejo. Pripravite se nanje.Članki OWASP SPVS.
- Faršad Abasi: OWASP SPVS v primerjavi z drugimi okviri dobavne verigeČlanki OWASP SPVS.
- OWASP: Top 10 CI/CD Varnostna tveganjaStran projekta OWASP.
- SLSA: Ravni dobavne verige za programske artefakteslsa.dev.
- OpenSSF: Preglednicavarnostni-rezultati.dev.
