Godinama su napadači napadali aplikacije jednu po jednu. Promijenili su taktiku: zašto ugroziti jednu aplikaciju kada možete ugroziti pipeline koji gradi mnoge? Xygenijev Rano upozorenje o zlonamjernom softveru (MEW) otkriveno 4,452 zlonamjernih paketa u 2025. godini i 1,281 više u 2026. godini do sadaSvaki istaknuti incident iz posljednjih nekoliko godina pogodio je drugu kariku u lancu isporuke softvera:
- SolarWinds (2020)Kompromitovanje okruženja za izgradnju; skrivena ažuriranja poslana su 18,000 korisnika.
- Codecov (2021)Pogrešno konfigurirana Docker slika omogućila je napadačima da modificiraju bash skriptu za uploader, čime su ukradene CI tajne od više od 23,000 korisnika.
- CircleCI (2023)Krađa kolačića sesije na laptopu inženjera pretvorena je u tokene za pristup produkciji; svakom kupcu je rečeno da rotira svaku tajnu.
- XZ Utils backdoor (2024) višegodišnja kampanja socijalnog inženjeringa koja je dosegla gotovo svaku Linux distribuciju.
- tj-akcije (2025) — kaskada lanca snabdijevanja GitHub Actions koja je otrovala komponentu koju koristi više od 23,000 repozitorija.
- Napadi na Aqua Trivy i checkmarkx (2026) — kampanja TeamPCP pretvorila je dva široko korištena sigurnosna skenera u vektore napada, a zatim iskoristila ukradene podatke CI/CD akreditacije za kaskadno slanje nizvodno u npm, OpenVSX i PyPI.
Svaki napad je iskoristio drugačiji dio pipelineOkruženje za izgradnju, CI alati, zavisnosti, akreditacije programera, povjerenje održavatelja, promjenjive reference na artefakte. Većina organizacija odgovara kontrolom tačaka, skenerom u CI, 2FA na IdP-u, zaštitom grana na mainOno što obično nedostaje je način da se postavi pitanje. Jesmo li sistematski pokriveni? više nego Jesmo li se sjetili omogućiti X nakon posljednjeg incidenta?
Proizvođači sigurnosnih rješenja za aplikacije su u centru pažnje, kompromitujući svakog kupca koji vjeruje njegovim artefaktima. Pritisak da se pređe sa reaktivnih kontrola na sistematski pristup nije teoretski. To je prethodno...cisŠta je motivisalo usvajanje OWASP SPVS-a? standard kao projekat najvišeg prioriteta.
Šta je SPVS i zašto je struktura važna
Priča o porijeklu je jednostavna. Na LASCON-u 2023, Farshad Abasi i Cameron Walters su stalno postavljali jedno drugom isto pitanje: gdje je ASVS za pipelines? OWASP ASVS je dao sigurnosti aplikacija sveobuhvatnu, provjerljivu standardNišta ekvivalentno nije postojalo za CI/CD.
Postojala je OWASP Top 10 lista CI/CD Rizici, koji je bio orijentisan na svijest, nije se mogao testirati; SLSA, koji se fokusirao samo na porijeklo izgradnje; S2C2F, koji se fokusirao samo na potrošnju zavisnosti; i OpenSSF Kartica rezultata, koja je pokrivala specifične provjere repozitorija. Svaka je pokrivala jedan dio. Nijedna nije pokrivala cjelinu.
| Okvir ili projekat | Primary Scope |
|---|---|
| OWASP Top 10 CI/CD rizici | Orijentisan na svijest CI/CD smjernice o riziku, a ne provjerljiva verifikacija standard. |
| SLSA | Izgradite porijeklo i integritet artefakta. |
| S2C2F | Sigurna potrošnja ovisnosti. |
| OpenSSF score card | Specifične sigurnosne provjere na nivou repozitorija. |
Razlika: svaki okvir pokrivao je važan dio software supply chain securityali nijedan nije pružio sveobuhvatnu, provjerljivu standard za cijelu CI/CD pipeline.
Taj razgovor se pretvorio u dvogodišnji rad, a u oktobru 2025. godine radna grupa SPVS-a objavila je verziju 1.0: 127 zahtjeva kroz cijeli životni ciklus: Planiranje, Razvoj, Integracija, Objavljivanje, Upravljanje, stratificirano u tri nivoa zrelosti: L1 Osnovni, L2 Standardi L3 Advanced. Svaki zahtjev je mapiran na NIST SP 800-53, OWASP CI/CD Top 10 i CWE.

Struktura je poenta. Riječima autora SPVS-a:
"Provjerite cijeli svoj pipeline, ne samo jedan dio. Tu se većina organizacija bori. Skeniraju zavisnosti, ali ignorišu upravljanje izdanjima. Potpisuju artefakte, ali ne modeliraju prijetnje svojim pipeline arhitektura. Oni prate produkciju, ali ne i svoja okruženja za izgradnju.
Ovdje se većina organizacija bori. Skeniraju zavisnosti, ali ignoriraju upravljanje izdanjima. Potpisuju artefakte, ali ne modeliraju prijetnje za svoje... pipeline arhitektura. Oni prate produkciju, ali ne i svoja okruženja za izgradnju.
Ovo je teza koja opravdava trud. Snage u jednoj fazi ne kompenziraju slabosti u drugoj. Napadačima je potrebna samo jedna karika da prekinu. Životni ciklus standard prisiljava vas da ih sve provjerite, a progresija od L1 do L2 do L3 vam omogućava da to uradite bez ključanja okeana. SPVS ne zamjenjuje SLSA, S2C2F, Scorecard ili Sigstore; daje vam skelu koja vam govori gdje se svaki od njih uklapa.
Prilagođavanje Standard vašoj organizaciji
Prirodan prvi korak je direktna revizija vaše organizacije i softverske infrastrukture u odnosu na svaki zahtjev. Google tabela preuzeta sa službenog CSV zahtjevi SPVS-a dobro funkcionira kao početna tačka. Tri prikaza su korisna: matrica zahtjeva sa statusom i vlasnikom po kontroli, mapa topline po repozitoriju i dashboard napredak po fazama i nivoima. Rezultat se prirodno uklapa u tehnički plan, živi dokument koji pokriva svaku fazu od plana do rada.
Većina zrelih inženjerskih organizacija će se već naći oko L2 nivoa kada izvrše ovo početno mapiranje. To je zapravo dobra pozicija: znači da se prva faza može fokusirati na zatvaranje specifičnih praznina, a ne na izgradnju temelja od nule.
Međutim, tabela je snimak stanja, a SPVS traži više. V1.1.7 nalaže kvartalnu reviziju VCS administratora; V5.1.1 do V5.1.3 dodaju redovne korisničke revizije, pregled dnevnika pristupa i praćenje privilegovanog pristupa; nekoliko V2.1.x, V3.3.x i V4.2.x kontrola zahtijevaju kontinuiranu higijenu radnog toka i YAML-a. Ručno se izvršava u cijeloj organizaciji, što znači pola dana praćenja klikova svakog kvartala sa stvarnim rizikom od tihih propusta. To je vrsta posla koja se ili automatizuje ili se pregleda tek nakon što se nešto loše dogodi.
Neke SPVS kontrole nisu jednokratne stavke kontrolne liste. One zahtijevaju ponovljene preglede, revizorske dokaze i otkrivanje pomjeranja između repozitorija, korisnika, tokova rada i privilegovanog pristupa.
| SPVS područje | Vrsta zahtjeva |
|---|---|
V1.1.7 | Tromjesečna revizija VCS administratora. |
V5.1.1–V5.1.3 | Redovne revizije korisnika, pregled dnevnika pristupa i praćenje privilegovanog pristupa. |
V2.1.x, V3.3.x, V4.2.x | Higijena tekućeg radnog procesa u YAML formatu. |
Rješenje je izgraditi ili usvojiti alate koji rade pod identitetom vlasnika organizacije i proizvode strukturirani kvartalni paket: administratorski spisak, zaštita grana, pokrivenost VLASNIKA KODOVA, higijena YAML toka rada sa zakačenim akcijama, eksplicitne dozvole, pull_request_target gating, član 2FA, instalirao GitHub aplikacije i implementirao ključeve. Ono što je nekada bila pola dana arheologije tabela postaje jedna komanda koja emituje JSON i Markdown. Kvartalni pregled između CISO i administratori organizacije postaju decissastanak za prikupljanje podataka, a ne sastanak za prikupljanje podataka, a praktični nalazi postaju zaostali problemi kod SLA-ova zasnovanih na ozbiljnosti.
Politika liste dozvoljenih, uključujući odobrene administratore, odobrene aplikacije i dozvole po funkciji za repozitorije i tokove rada, trebala bi postojati kao YAML u repozitoriju s kontroliranim verzijama, koji je zaštićen PR pregledom od strane sigurnosnog tima. Svaka promjena liste dozvoljenih ostavlja trag pregleda, tako da se dokazi revizije sami generiraju. Efekat je da se kontrole koje su bile aspirativne, poput „trebali bismo vršiti reviziju kvartalno“, pretvore u rutinske, poput „revizija ovog kvartala završila je u ponedjeljak“, i da se organizaciji da ponovljivi mehanizam za otkrivanje odstupanja koji zahtijeva princip od početka do kraja.
Trenja za koja biste trebali biti spremni
Tehničke kontrole su lakši dio. Ljudi su teži.
Istaknuti primjer su gotovo uvijek VLASNICI KODA. Dodavanje .github/workflows/ @your-org/security Zvuči trivijalno u vezi sa svakim repozitorijem. Jedna datoteka, jedna linija. Ali to znači da inženjeri koji godinama sami spajaju promjene u radnom procesu sada trebaju sigurnosni pregled. Čak i ljudi koji su svjesni sigurnosti se bune: Ja sam napisao ovaj radni proces, razumijem ga, zašto čekam?
Potreban je pravi razgovor da bi se utvrdio razlog. Tokovi rada mogu ukrasti vjerodajnice, preusmjeriti artefakte i otrovati potrošače u budućnosti. Drugi par očiju nije nepovjerenje; to je ista logika kao i četverooki nadzor nad promjenama u produkcijskoj bazi podataka. Imati konkretan, nedavni incident u lancu snabdijevanja na koji se može ukazati, bilo da je iz industrije ili vašeg vlastitog okruženja, izuzetno pomaže. Ništa ne kristalizira kontrolu kao pravi primjer njenog odsustva.
Ostala trenja slijede isti oblik:
- Eksplicitne dozvole: Blokovi u radnim tokovima uzrokuju kvarove CI-ja sve dok saradnici ne shvate ograničene dozvole. Ovo nije problem dozvola, već problem mentalnog modela.
- Nepromjenjivost oznake: prekida alate za izdavanje koji su godinama tiho ponovo označavali.
- potpisan commits: stvoriti trenje pri uvođenju sistema dok se GPG ili SSH ključevi ne postave ispravno na svim radnim stanicama. SPVS ovo čini obaveznim za svaki repozitorij i saradnika, ne samo za glavne.
- Zamjena klasičnih tokena za lični pristup: u mnogim repozitorijima i datotekama radnog procesa dotiče se gotovo svakog tima.
Obrazac koji funkcionira: uvedite svaku kontrolu sa specifičnom prijetnjom koju blokira, testirajte je na jednom ili dva repozitorija, implementirajte je s izuzecima s dozvoljene liste i povucite izuzetke u definiranom vremenskom okviru. Inženjeri koji se najžešće protive postaju, najčešće, najjači zagovornici kada vide opravdanje.
Još jedna dublja poenta: princip "od početka do kraja" ovdje je bitan. Ne možete birati. Pooštravanje faze izgradnje, a istovremeno labavo upravljanje izdavanjem, daje lažno samopouzdanje, što je upravo način neuspjeha koji autori SPVS-a ističu. Svaka faza mora napredovati zajedno, čak i kada se određena kontrola čini nesrazmjernom u izolaciji.
trošak: Otprilike mjesec dana uloženo je u inženjering prve faze, fokusiran na usklađenost s drugim nivoom (L2) za malu organizaciju, raspoređeno na DevOps, sigurnost i inženjerske preglednike. Investicija se lako isplati. Jedan spriječeni incident u lancu snabdijevanja pokriva to višestruko. Veće organizacije bi trebale proporcionalno planirati veći budžet, ali fazna struktura od L1 do L2 do L3 znači da se vrijednost isporučuje prije nego što je program završen.
Šta je sljedeće
SPVS v1.5 je na vidiku sa kontrolama povezanim sa vještačkom inteligencijom: porijeklo koda potpomognutog vještačkom inteligencijom, guardrails Za CI tokove rada koji pozivaju LLM-ove, pregledajte tragove za generirane od strane umjetne inteligencije pull requestsi odbranu od novih prijetnji poput skvotiranja, gdje napadači registruju nazive paketa koje asistenti umjetne inteligencije zamišljaju, i operativni zlonamjerni softver generiran umjetnom inteligencijom o kojem CrowdStrike izvještava u praksi. Organizacije koje već označavaju programe potpomognute umjetnom inteligencijom commitDirektori i primarni predstavnici će u svojim internim smjernicama za razvoj smatrati ovu prilagodbu postepenom, a ne novim programom rada.
Očekuje se da će verzija 2.0 produbiti praćenje vremena izvođenja i zahtjeve za životni ciklus akreditiva. Razuman organizacijski plan: zatvoriti preostale nedostatke na L3 nivou do kraja drugog kvartala 2026. godine, uključujući SLSA provenance integriran u standard CI/CD, ručne kapije za produkcijske implementacije i centralizirani pružatelj identiteta, a zatim prelaze na način održavanja. Svaki novi repozitorij počinje biti usklađen s propisima, a svaka kvartalna revizija otkrije da se odstupa ranije.
Iskreno hvala Farshadu Abasiju, Cameronu Waltersu i radnoj grupi OWASP SPVS. Projekti poput ovog snižavaju ljestvicu za svaku organizaciju koja želi sistematski, a ne reaktivno, provoditi sigurnost lanca snabdijevanja.
Key Takeaways

Nekoliko stvari koje prevazilaze naš specifični kontekst:
- Da probate: Preuzmite CSV datoteku sa zahtjevima SPVS-a i mapirajte svoje trenutne kontrole u tabelu. U roku od jednog dana ćete znati da li vam odgovara.
- Odaberite jedan ciljni nivo i pošaljite ga prije nego što posegnete za sljedećim. Od L1 do L2 do L3 je karakteristika, a ne ograničenje.
- The pipeline je meta. Kontrole usmjerene na aplikacije su neophodne, ali nisu dovoljne; tretirajte pipeline kao prvoklasna napadačka površina.
- Provjerite cijelu pipeline, ne jedan komad. Snaga u skeniranju zavisnosti ne nadoknađuje slabo upravljanje izdanjima ili nenadgledana okruženja za izgradnju.
- Proračunske tabele su snimci; pomak je kontinuiran. Izgradite automatizaciju, čak i skroman interni alat, za otkrivanje odstupanja između revizija.
- Organizacijski posao je teži od tehničkog. Predvidite vrijeme za razgovor i pilot-projekt prije implementacije, te objasnite specifičnu prijetnju koju svaka kontrola blokira.
Za više informacija
- OWASP: Secure Pipeline verifikacija Standard (SPVS) v1.0Stranica projekta OWASP.
- Faršad Abasi: Zašto smo kreirali OWASP SPVSČlanci OWASP SPVS-a.
- Faršad Abasi: Pipeline Napadi se pogoršavaju. Evo kako se pripremitiČlanci OWASP SPVS-a.
- Faršad Abasi: OWASP SPVS u odnosu na druge okvire lanca snabdijevanjaČlanci OWASP SPVS-a.
- OWASP: Top 10 CI/CD Sigurnosni riziciStranica projekta OWASP.
- SLSA: Nivoi lanca snabdijevanja za softverske artefakte.slsa.dev.
- OpenSSF: score card. securityscorecards.dev.
o autoru
Suosnivač i direktor za društvene odgovornosti
Luis Rodriguez je suosnivač i glavni istraživač za sigurnost u Xygeni Securityju. Sa preko 20 godina iskustva u sigurnosti aplikacija, fokusira se na AppSec zaštitu i napredne mogućnosti analize koda koje pomažu timovima da smanje stvarni rizik isporuke.




