OWASP SPVS: Лекције из обезбеђивања софтвера Pipeline

Годинама су нападачи нападали апликације једну по једну. Променили су тактику: зашто угрожавати једну апликацију када можете угрожавати pipeline који гради многе? Ксигенијев Рано упозоравање на злонамерни софтвер (MEW) откривен 4,452 злонамерних пакета у 2025. години 1,281 више у 2026. години до садаСваки инцидент високог профила из последњих неколико година погодио је другу карику у ланцу испоруке софтвера:

• Солар Виндс (2020)Компромитовање окружења за изградњу; скривена ажурирања испоручена 18,000 корисника.
• Кодеков (2021)Погрешно конфигурисана Docker слика је омогућила нападачима да измене bash скрипту за отпремање, чиме су украли CI тајне од више од 23,000 корисника.
• CircleCI (2023)Крађа колачића сесије на лаптопу инжењера претворена је у токене за приступ производњи; сваком купцу је речено да ротира сваку тајну.
• КСЗ Утилс бацкдоор (2024) вишегодишња кампања социјалног инжењеринга која је досегла скоро сваку Линукс дистрибуцију.
• тј-акције (2025) — каскада ланца снабдевања GitHub Actions која је отровала компоненту коју користи преко 23,000 репозиторијума.
• Напади на Аква Триви Цхецкмарк (2026) — кампања TeamPCP је претворила два широко коришћена безбедносна скенера у векторе напада, а затим је користила украдене CI/CD акредитиви за каскадно преношење низводно у npm, OpenVSX и PyPI.

Сваки напад је искористио други део pipelineокружење за изградњу, CI алати, зависности, акредитиви програмера, поверење одржаваоца, променљиве референце на артефакте. Већина организација одговара контролом тачака, скенером у CI, 2FA на IdP-у, заштитом гранчица на mainОно што обично недостаје је начин да се пита Да ли смо систематски покривени? више него Да ли смо се сетили да омогућимо X после последњег инцидента?

Произвођачи безбедности апликација су директно на мети, угрожавајући сваког купца који верује њиховим артефактима. Притисак да се пређе са реактивних контрола на систематски став није теоретски. То је претходнаcisшта је мотивисало усвајање OWASP SPVS-а standard као пројекат највишег приоритета.

Шта је СПВС и зашто је структура важна

Прича о пореклу је једноставна. На LASCON-у 2023, Фаршад Абаси и Камерон Волтерс су стално постављали једно другом исто питање: где је ASVS за pipelineс? OWASP ASVS је обезбедио безбедност апликација свеобухватну, проверљиву standardНишта еквивалентно није постојало за CI/CD.

Постојала је OWASP Топ 10 листа CI/CD Ризици, који је био усмерен на свест, није се могао тестирати; SLSA, који се фокусирао само на порекло израде; S2C2F, који се фокусирао само на потрошњу зависности; и OpenSSF Картица резултата, која је покривала специфичне провере спремишта. Свака је покривала део. Ниједна није покривала целину.

Оквир или пројекат	Примари Сцопе
ОВАСП Топ 10 CI/CD Ризици	Оријентисано на свест CI/CD смернице за ризик, а не проверљива верификација standard.
СЛСА	Изградите порекло и интегритет артефаката.
С2Ц2Ф	Безбедна потрошња зависности.
OpenSSF Сцорецард	Специфичне безбедносне провере на нивоу спремишта.

Јаз: сваки оквир је покривао важан део software supply chain security, али ниједан није пружио свеобухватну, проверљиву standard за целину CI/CD pipeline.

Тај разговор је прерастао у две године рада, а у октобру 2025. године радна група SPVS је објавила верзију 1.0: 127 захтева током животног циклуса, Планирање, Развој, Интеграција, Објављивање, Управљање, стратификованих у три нивоа зрелости: L1 Основа, L2 Standardи L3 Advanced. Сваки захтев је мапиран на NIST SP 800-53, OWASP CI/CD Топ 10 и CWE.

Ту се већина организација мучи. Скенирају зависности, али игноришу управљање издањима. Потписују артефакте, али не моделирају претње. pipeline архитектура. Они прате производњу, али не и своја окружења за изградњу.

Ово је теза која оправдава труд. Снаге у једној фази не надокнађују слабости у другој. Нападачима је потребна само једна веза да би је прекинули. Животни циклус standard тера вас да их све проверите, а прогресија од L1 до L2 до L3 вам омогућава да то урадите без кључања океана. SPVS не замењује SLSA, S2C2F, Scorecard или Sigstore; он вам даје скелу која вам говори где се сваки од њих уклапа.

Адаптинг тхе Standard вашој организацији

Природан први корак је директна ревизија ваше организације и софтверске инфраструктуре у односу на сваки захтев. Google табела добијена из званичног CSV са захтевима SPVS-а добро функционише као почетна тачка. Три приказа су корисна: матрица захтева са статусом и власником по контроли, топлотна мапа по спремишту и dashboard напретка по фазама и нивоима. Резултат се природно уклапа у технички план, живи документ који покрива сваку фазу од плана до операције.

Већина зрелих инжењерских организација ће се већ наћи око нивоа L2 када ураде ово почетно мапирање. То је заправо добра позиција: то значи да се прва фаза може фокусирати на затварање одређених празнина, а не на изградњу темеља од нуле.

Међутим, табела је снимак, а SPVS захтева више. V1.1.7 налаже кварталну ревизију VCS администратора; V5.1.1 до V5.1.3 додају редовне ревизије корисника, преглед дневника приступа и праћење привилегованог приступа; неколико V2.1.x, V3.3.x и V4.2.x контрола захтевају континуирану хигијену тока посла - YAML. Ако се то ради ручно у целој организацији, то је пола дана праћења кликова сваког квартала са стварним ризиком од тихих пропуста. То је врста посла која се или аутоматизује или се прегледа тек након што се нешто лоше догоди.

Неке SPVS контроле нису једнократне ставке контролне листе. Оне захтевају понављајуће прегледе, ревизорске доказе и откривање померања између спремишта, корисника, токова рада и привилегованог приступа.

Подручје СПВС-а	Рекуиремент Типе
V1.1.7	Квартална ревизија VCS администратора.
V5.1.1–V5.1.3	Редовне ревизије корисника, преглед евиденције приступа и праћење привилегованог приступа.
V2.1.x, V3.3.x, V4.2.x	Текући ток рада YAML хигијена.

Одговор је изградња или усвајање алата који раде под идентитетом власника организације и производе структурирани квартални пакет: администраторски списак, заштита гранчица, покривеност ВЛАСНИКА КОДОВА, хигијена YAML тока посла са закаченим радњама, експлицитне дозволе, pull_request_target гејтинг, члан другог ауторитета идентитета, инсталирао је GitHub апликације и распоредио кључеве. Оно што је некада била пола дана археологије табела постаје једна команда која емитује JSON и Markdown. Квартални преглед између CISО и организациони администратори постају деcisсастанак за ионизацију, а не састанак за прикупљање података, а применљиви налази постају заостали проблеми са споразумима о нивоу услуге заснованим на озбиљности.

Политика листе дозвољених, укључујући одобрене администраторе, одобрене апликације и дозволе по функцији за репозиторијуме и токове рада, требало би да постоји као YAML у репозиторијуму са контролисаним верзијама, који је проверен путем PR прегледа од стране безбедносног тима. Свака промена листе дозвољених оставља траг прегледа, тако да се докази ревизије сами генеришу. Ефекат је да се контроле које су биле амбициозне, попут „требало би да вршимо ревизију квартално“, претворе у оне које су рутинске, попут „ревизија овог квартала је стигла у понедељак“, и да се организацији пружи понављајући механизам за откривање одступања који захтева принцип од почетка до краја.

Трења за која би требало да планирате

Техничке контроле су лакши део. Људи су тежи.

Истакнути пример су скоро увек ВЛАСНИЦИ КОДОВА. Додавање .github/workflows/ @your-org/security Звучи тривијално да је у питању сваки репозиторијум. Једна датотека, једна линија. Али то значи да инжењери који годинама сами спајају промене у радном току сада требају безбедносну проверу. Чак и људи који су свесни безбедности се буне: Ја сам написао овај радни ток, разумем га, зашто чекам?

Потребан је прави разговор да би се утврдио разлог. Токови посла могу да издају акредитиве, преусмере артефакте и отрују потрошаче низводно. Други пар очију није неповерење; то је иста логика као и „четворо очију“ на промене у бази података у производњи. Имати конкретан, скорашњи инцидент у ланцу снабдевања на који се може указати, било да је из индустрије или из вашег сопственог окружења, помаже изузетно. Ништа не кристализује контролу као прави пример њеног одсуства.

Остала трења прате исти облик:

• Експлицитне дозволе: Блокови у токовима рада узрокују кварове CI-ја док сарадници не разумеју ограничене дозволе. Ово није проблем са дозволама, већ проблем менталног модела.
• Непроменљивост ознаке: прекида алате за објављивање који су годинама тихо поново означавали.
• Потписан commits: створити трење приликом увођења у систем док се GPG или SSH кључеви не подесе исправно на свим радним станицама. SPVS ово чини обавезним за сваки репозиторијум и сарадника, не само за главне.
• Замена класичних токена за лични приступ: у многим спремиштима и датотекама тока посла дотиче се скоро сваког тима.

Образац који функционише: увести сваку контролу са одређеном претњом коју блокира, тестирати на једном или два спремишта, имплементирати са изузецима са дозвољене листе и повући изузетке у дефинисаном временском оквиру. Инжењери који се најјаче супротстављају постају, најчешће него не, најјачи заговорници када виде образложење.

Још једна дубља поента: принцип „од почетка до краја“ је овде битан. Не можете бирати. Пооштравање фазе изградње, док управљање издањем остаје лабаво, даје лажно поверење, што је управо начин неуспеха који аутори SPVS-а истичу. Свака фаза мора да напредује заједно, чак и када се одређена контрола чини несразмерном у изолацији.

Цена: отприлике месец дана прошло је инжењерско време за Фазу 1, фокусирано на усклађеност са L2 за малу организацију, распоређено између DevOps-а, безбедности и инжењерских прегледача. Инвестиција се лако исплати. Један спречени инцидент у ланцу снабдевања покрива то вишеструко. Веће организације би требало да буџетирају пропорционално више, али фазна структура од L1 до L2 до L3 значи да се вредност испоручује пре него што се програм заврши.

Шта је следеће

SPVS v1.5 је на помолу са контролама повезаним са вештачком интелигенцијом: порекло кода потпомогнутог вештачком интелигенцијом, guardrails За CI токове рада који позивају LLM-ове, прегледајте трагове за генерисане од стране вештачке интелигенције pull requests, и одбрану од нових претњи попут „slopsquatting-а“, где нападачи региструју имена пакета која асистенти вештачке интелигенције замишљају, и оперативни малвер генерисан вештачком интелигенцијом о коме CrowdStrike извештава у јавности. Организације које већ означавају вештачки потпомогнуте commitПредставници и ПР ће у својим интерним смерницама за развој сматрати ову адаптацију постепеном, а не новим програмом рада.

Очекује се да ће верзија 2.0 продубити праћење времена извршавања и захтеве за животни циклус акредитива. Разуман организациони план: затворити преостале празнине на нивоу 3 до краја другог квартала 2026. године, укључујући SLSA provenance интегрисан у standard CI/CD, ручне капије за производне инсталације и централизовани добављач идентитета, а затим прелазе на режим одржавања. Свако ново спремиште почиње са прописима, а свака квартална ревизија открије рано одступање.

Искрено хвала Фаршаду Абасију, Камерону Волтерсу и радној групи OWASP SPVS. Пројекти попут овог снижавају летвицу за сваку организацију која жели да се систематски, а не реактивно, бави безбедношћу ланца снабдевања.

Кључне Такеаваис

Неколико ствари које превазилазе наш специфични контекст:

• Да бисте пробали: Преузмите CSV датотеку са захтевима SPVS-а и мапирајте своје тренутне контроле у ​​табелу. У року од једног дана ћете знати да ли вам одговара.
• Изаберите један циљни ниво и пошаљите га пре него што посегнете за следећим. L1 до L2 до L3 је карактеристика, а не ограничење.
• pipeline је циљ. Контроле усмерене на апликације су неопходне, али нису довољне; третирајте pipeline као првокласна нападачка површина.
• Проверите целокупно pipeline, не један комад. Снага у скенирању зависности не надокнађује слабо управљање издањима или ненадгледана окружења за изградњу.
• Табеле су снимци; померање је континуирано. Изградите аутоматизацију, чак и скроман интерни алат, за откривање одступања између ревизија.
• Организациони посао је тежи од техничког посла. Предвидите време за разговор и пилотирање пре имплементације и објасните специфичну претњу коју свака контрола блокира.

Да бисте прочитали више

• ОВАСП: bezbednost Pipeline Верификација Standard (СПВС) в1.0Страница пројекта OWASP.
• Фаршад Абаси: Зашто смо креирали OWASP SPVSЧланци OWASP SPVS-а.
• Фаршад Абаси: Pipeline Напади се погоршавају. Ево како се припремитиЧланци OWASP SPVS-а.
• Фаршад Абаси: OWASP SPVS у односу на друге оквире ланца снабдевањаЧланци OWASP SPVS-а.
• ОВАСП: Врх КСНУМКС CI/CD Безбедносни ризициСтраница пројекта OWASP.
• СЛСА: Нивои ланца снабдевања за софтверске артефакте. slsa.dev.
• OpenSSF: Сцорецард. securityscorecards.dev.