Տարիներ շարունակ հարձակվողները մեկ առ մեկ հետապնդել են հավելվածները։ Նրանք փոխել են մարտավարությունը. ինչու՞ վտանգել մեկ հավելված, երբ կարող ես վտանգել այն։ pipeline որը շատերն է կառուցում։ Xygeni-ի Վնասակար ծրագրերի վաղ նախազգուշացում (MEW) հայտնաբերվել է 4,452 վնասակար փաթեթ 2025 թվականին և 2026 թվականին մինչ օրս ևս 1,281-ովՎերջին մի քանի տարիների յուրաքանչյուր աղմկահարույց միջադեպ ծրագրային ապահովման մատակարարման շղթայի տարբեր օղակների է դիպչել.
- SolarWinds (2020)կառուցման միջավայրի խախտում; գաղտնի թարմացումները ուղարկվել են 18,000 հաճախորդների։
- Կոդկով (2021)Սխալ կարգավորված Docker պատկերը թույլ տվեց հարձակվողներին փոփոխել bash վերբեռնիչի սկրիպտը՝ գողանալով CI գաղտնիքներ ավելի քան 23,000 հաճախորդներից։
- CircleCI (2023)Ինժեների նոութբուքից սեսիայի cookie-ների գողությունը վերածվեց արտադրության մուտքի տոկենների. յուրաքանչյուր հաճախորդին հրահանգվեց պտտել յուրաքանչյուր գաղտնիքը։
- XZ Utils-ի հետևի դուռը (2024) :բազմամյա սոցիալական ինժեներիայի արշավ, որը հասավ գրեթե բոլոր Linux բաշխումներին։
- tj-գործողություններ (2025) — GitHub Actions մատակարարման շղթայի կասկադ, որը թունավորեց 23,000+ պահոցների կողմից օգտագործվող բաղադրիչը։
- Հարձակումներ Ակվա Թրիվի և Ստուգանիշ (2026) — TeamPCP արշավը երկու լայնորեն օգտագործվող անվտանգության սկաներներ վերածեց հարձակման վեկտորների, այնուհետև օգտագործեց գողացվածը CI/CD հավատարմագրեր՝ npm, OpenVSX և PyPI-ում ներքևի մասում անցնելու համար։
Յուրաքանչյուր հարձակում օգտագործում էր տարբեր մասեր pipelineկառուցման միջավայր, CI գործիքակազմ, կախվածություններ, մշակողի լիազորագրեր, պահպանողի վստահություն, արտեֆակտների փոփոխական հղումներ: Կազմակերպությունների մեծ մասը արձագանքում է կետերի վերահսկմամբ, CI-ում սկաներով, IdP-ի վրա 2FA-ով, ճյուղերի պաշտպանությամբ: mainՍովորաբար բացակայում է հարցնելու միջոցը Մենք համակարգված կերպով լուսաբանվա՞ծ ենք։ այլ Հիշեցի՞նք միացնել X-ը վերջին միջադեպից հետո։
Կիրառական անվտանգության մատակարարները ուղիղ խաչմերուկում են՝ վտանգելով յուրաքանչյուր հաճախորդի, ով վստահում է իր արտեֆակտներին: Ռեակտիվ կառավարումից համակարգված դիրքորոշման անցնելու ճնշումը տեսական չէ: Դա նախնական է:cisինչն էր պատճառը, որ ընդունվեց OWASP SPVS-ը standard որպես գերակա նախագիծ։
Ի՞նչ է SPVS-ը և ինչու է կառուցվածքը կարևոր
Պատմությունը պարզ է։ LASCON 2023-ում Ֆարշադ Աբասին և Քեմերոն Ուոլթերսը անընդհատ նույն հարցն էին տալիս միմյանց. որտե՞ղ է ASVS-ը։ pipelineս? OWASP ASVS-ը կիրառական անվտանգությանը տվել էր համապարփակ, ստուգելի standardՈչ մի համարժեք բան գոյություն չուներ CI/CD.
Կար OWASP-ի լավագույն 10-յակը CI/CD Ռիսկերը, որոնք ուղղված էին իրազեկվածությանը, չէին կարող ստուգել, SLSA-ն, որը կենտրոնանում էր միայն կառուցվածքի ծագման վրա, S2C2F-ը, որը կենտրոնանում էր միայն կախվածության սպառման վրա, և OpenSSF Գնահատականների քարտ, որը ներառում էր պահոցի որոշակի ստուգումներ։ Յուրաքանչյուրը ներառում էր մեկ մաս։ Ոչ մեկը չէր ներառում ամբողջը։
| Շրջանակ կամ նախագիծ | Առաջնային շրջանակ |
|---|---|
| OWASP-ի լավագույն 10-յակը CI/CD Ռիսկերի | Իրազեկության վրա կենտրոնացած CI/CD ռիսկի ուղեցույց, այլ ոչ թե ստուգելի ստուգում standard. |
| SLSA | Կառուցեք ծագումնաբանությունը և արտեֆակտի ամբողջականությունը։ |
| S2C2F | Անվտանգ կախվածության սպառում։ |
| OpenSSF Գոլային փոխանցում | Հատուկ պահոցի մակարդակի անվտանգության ստուգումներ։ |
Բացը. յուրաքանչյուր շրջանակ ներառում էր կարևոր մաս software supply chain security, բայց ոչ մեկը չէր տրամադրում ծայրից ծայր ստուգելի standard ամբողջի համար CI/CD pipeline.
Այդ զրույցը վերածվեց երկու տարվա աշխատանքի, և 2025 թվականի հոկտեմբերին SPVS աշխատանքային խումբը թողարկեց v1.0: 127 պահանջներ ողջ կյանքի ցիկլի համար՝ պլանավորել, մշակել, ինտեգրել, թողարկել, գործարկել, որոնք բաժանված են հասունության երեք մակարդակների՝ L1 Հիմնարար, L2: Standardև L3 Advanced: Յուրաքանչյուր պահանջ համապատասխանում է NIST SP 800-53, OWASP չափանիշներին: CI/CD Լավագույն 10-ը և CWE-ն։
Կառուցվածքն է գլխավորը։ SPVS հեղինակների խոսքերով՝
«Հաստատեք ձեր ամբողջ pipeline, ոչ միայն մեկ կտոր։ Սա այն խնդիրն է, որտեղ կազմակերպությունների մեծ մասը դժվարանում է։ Նրանք սկանավորում են կախվածությունները, բայց անտեսում են թողարկումների կառավարումը։ Նրանք ստորագրում են արտեֆակտներ, բայց չեն մոդելավորում իրենց pipeline ճարտարապետություն։ Նրանք վերահսկում են արտադրությունը, բայց ոչ իրենց կառուցման միջավայրը։
Ահա թե որտեղ են կազմակերպությունների մեծ մասը դժվարանում։ Նրանք սկանավորում են կախվածությունները, բայց անտեսում են թողարկումների կառավարումը։ Նրանք ստորագրում են արտեֆակտներ, բայց չեն մոդելավորում իրենց սպառնալիքները։ pipeline ճարտարապետություն։ Նրանք վերահսկում են արտադրությունը, բայց ոչ իրենց կառուցման միջավայրերը։
Սա այն թեզն է, որը արդարացնում է ջանքերը։ Մեկ փուլի ուժեղ կողմերը չեն փոխհատուցում մյուսի թույլ կողմերը։ Հարձակվողներին անհրաժեշտ է միայն մեկ օղակ՝ կոտրելու համար։ Կյանքի ցիկլ standard ստիպում է ձեզ ստուգել դրանք բոլորը, իսկ L1-ից L2-ից L3 առաջընթացը թույլ է տալիս դա անել առանց օվկիանոսը եռացնելու։ SPVS-ը չի փոխարինում SLSA-ին, S2C2F-ին, Scorecard-ին կամ Sigstore-ին. այն ձեզ տալիս է հիմք, որը ցույց է տալիս, թե դրանցից յուրաքանչյուրը որտեղ է տեղավորվում։
Հարմարեցնելով Standard Ձեր կազմակերպությանը
Բնական առաջին քայլը ձեր կազմակերպության և ծրագրային ենթակառուցվածքի ուղղակի աուդիտն է՝ յուրաքանչյուր պահանջի համար։ Պաշտոնական կայքից վերցված Google աղյուսակ SPVS պահանջներ CSV ֆայլում լավ է աշխատում որպես մեկնարկային կետ: Օգտակար են երեք տեսքեր՝ պահանջների մատրից՝ յուրաքանչյուր կառավարման համար կարգավիճակով և սեփականատիրոջով, յուրաքանչյուր պահոցի համար ջերմային քարտեզ և dashboard առաջընթացի վերլուծություն ըստ փուլերի և մակարդակների: Արդյունքը բնականաբար վերածվում է տեխնիկական ճանապարհային քարտեզի, որը կենդանի փաստաթուղթ է, որը ներառում է յուրաքանչյուր փուլ՝ պլանավորումից մինչև շահագործում:
Այս նախնական քարտեզագրումն անելիս մեծ մասամբ ճարտարագիտական կազմակերպությունները արդեն կհայտնվեն երկրորդ մակարդակի վրա։ Սա իրականում լավ դիրք է. դա նշանակում է, որ առաջին փուլը կարող է կենտրոնանալ որոշակի բացթողումների լրացման վրա, այլ ոչ թե հիմքերը զրոյից կառուցելու վրա։
Սակայն աղյուսակը կարճ պատկեր է, և SPVS-ը ավելին է պահանջում: V1.1.7 տարբերակը պահանջում է VCS ադմինիստրատորների եռամսյակային աուդիտ. V5.1.1-ից մինչև V5.1.3-ը ավելացնում են օգտատերերի կանոնավոր աուդիտներ, մուտքի գրանցամատյանի վերանայում և արտոնյալ մուտքի մոնիթորինգ. մի քանի V2.1.x, V3.3.x և V4.2.x կառավարման համակարգեր պահանջում են աշխատանքային հոսքի շարունակական YAML հիգիենա: Կազմակերպության ողջ տարածքում ձեռքով իրականացվող գործողություն, այսինքն՝ յուրաքանչյուր եռամսյակ կես օր սեղմումների հետևում՝ աննկատ բացթողումների իրական ռիսկով: Սա այնպիսի աշխատանք է, որը կամ ավտոմատացվում է, կամ վերանայվում է միայն վատ բան պատահելուց հետո:
Որոշ SPVS կառավարման տարրեր միանգամյա ստուգաթերթիկ չեն։ Դրանք պահանջում են պարբերական վերանայում, աուդիտի ապացույցներ և շեղումների հայտնաբերում պահոցներում, օգտատերերում, աշխատանքային հոսքերում և արտոնյալ մուտքի իրավունքներով։
| SPVS տարածք | Պահանջների տեսակը |
|---|---|
V1.1.7 | VCS ադմինիստրատորների եռամսյակային աուդիտ։ |
V5.1.1–V5.1.3 | Կանոնավոր օգտատերերի աուդիտներ, մուտքի գրանցամատյանի վերանայում և արտոնյալ մուտքի մոնիթորինգ։ |
V2.1.x, V3.3.x, V4.2.x | YAML հիգիենայի շարունակական աշխատանքային հոսք։ |
Լուծումը կայանում է նրանում, որ ստեղծվեն կամ կիրառվեն գործիքակազմեր, որոնք կաշխատեն կազմակերպության սեփականատիրոջ ինքնության ներքո և կստեղծեն կառուցվածքային եռամսյակային փաթեթ՝ ադմինիստրատորի ցուցակ, մասնաճյուղերի պաշտպանություն, CODEOWNERS ծածկույթ, աշխատանքային հոսքի YAML հիգիենա՝ ամրացված գործողություններով, հստակ թույլտվություններ, pull_request_target դարպասներ, 2FA անդամ, տեղադրեց GitHub հավելվածներ և տեղակայեց բանալիներ: Այն, ինչ նախկինում կեսօրյա աղյուսակային հնագիտություն էր, վերածվեց JSON և Markdown արտանցող մեկ հրամանի: Եռամսյակային վերանայումը CISO և կազմակերպության ադմինիստրատորները դառնում են դեcisիոնային հանդիպում, այլ ոչ թե տվյալների հավաքագրում, և գործնականում կիրառելի արդյունքները վերածվում են ծանրության վրա հիմնված SLA-ների կուտակված խնդիրների։
Թույլատրված ցուցակի քաղաքականությունը, որը ներառում է հաստատված ադմինիստրատորներ, հաստատված հավելվածներ և ֆունկցիայի թույլտվություններ պահոցների և աշխատանքային հոսքերի համար, պետք է լինի որպես 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-ներ, վերանայեք AI-ի կողմից ստեղծված տեղեկությունների համար նախատեսված տեղեկությունները։ pull requestsև պաշտպանություններ այնպիսի ի հայտ եկող սպառնալիքներից, ինչպիսիք են անփույթ կացարանները, որտեղ հարձակվողները գրանցում են փաթեթների անուններ, որոնք արհեստական ինտելեկտի կոդավորման օգնականները հալյուցինացնում են, և CrowdStrike-ի կողմից հայտնաբերված օպերատիվ արհեստական ինտելեկտի կողմից ստեղծված վնասակար ծրագրերը: Կազմակերպություններ, որոնք արդեն պիտակավորում են արհեստական ինտելեկտի կողմից օժանդակվողները commitիրենց ներքին զարգացման ուղեցույցներում ները և PR-ները այս հարմարվողականությունը կհամարեն աստիճանական, այլ ոչ թե աշխատանքային նոր ծրագիր։
2.0 տարբերակը, ինչպես սպասվում է, կխորացնի կատարման ժամանակի մոնիթորինգը և հավատարմագրերի կյանքի ցիկլի պահանջները: Կազմակերպչական ողջամիտ ճանապարհային քարտեզ. 2026 թվականի երկրորդ եռամսյակի վերջում լրացնել մնացած L3 բացերը, ներառյալ SLSA provenance ինտեգրվել standard CI/CD, արտադրական տեղակայումների համար ձեռքով դարպասներ և կենտրոնացված նույնականացման մատակարար, այնուհետև անցում սպասարկման ռեժիմի: Յուրաքանչյուր նոր պահոց սկսում է համապատասխանել պահանջներին, և յուրաքանչյուր եռամսյակային աուդիտ վաղ հայտնաբերում է շեղումները:
Անկեղծ շնորհակալություն Ֆարշադ Աբասիին, Քեմերոն Ուոլթերսին և OWASP SPVS աշխատանքային խմբին: Նման նախագծերը իջեցնում են յուրաքանչյուր կազմակերպության չափանիշները, որը ցանկանում է մատակարարման շղթայի անվտանգությունն իրականացնել համակարգված, այլ ոչ թե ռեակտիվ կերպով:
Հիմնական տուփեր
Մի քանի բան, որոնք թարգմանվում են մեր կոնկրետ համատեքստից դուրս.
- Փորձելու համար՝ Ներբեռնեք SPVS պահանջների CSV ֆայլը և քարտեզագրեք ձեր ընթացիկ կառավարման տարրերը աղյուսակում: Մեկ օրվա ընթացքում կիմանաք՝ համապատասխանում է, թե ոչ:
- Ընտրեք մեկ թիրախային մակարդակ և ուղարկեք այն, նախքան հաջորդին հասնելը։ L1-ից L2-ից L3-ը առանձնահատկություն է, այլ ոչ թե սահմանափակում։
- pipeline թիրախն է։ Կիրառակենտրոն վերահսկողությունը անհրաժեշտ է, բայց ոչ բավարար։ Վերաբերվեք pipeline որպես առաջին կարգի հարձակման հարթակ։
- Հաստատեք ամբողջը pipeline, ոչ թե մեկ կտոր։ Կախվածությունների սկանավորման ուժեղ կողմը չի փոխհատուցում թողարկումների թույլ կառավարումը կամ չմոնիթորինգային կառուցման միջավայրերը։
- Աղյուսակները ակնթարթային պատկերներ են. տեղաշարժը շարունակական է։ Կառուցեք ավտոմատացում, նույնիսկ համեստ ներքին գործիք, աուդիտների միջև շեղումները հայտնաբերելու համար։
- Կազմակերպչական աշխատանքն ավելի դժվար է, քան տեխնիկականը։ Նախատեսեք ժամանակ զրույցի և փորձարկման համար՝ նախքան ներդրումը, և բացատրեք, թե յուրաքանչյուր վերահսկող մարմին ինչ կոնկրետ սպառնալիք է արգելափակում։
Ավելին կարդալու համար
- OWASP: Ապահովել Pipeline Ստուգում Standard (SPVS) v1.0OWASP նախագծի էջ։
- Ֆարշադ Աբասի. Ինչու՞ մենք ստեղծեցինք OWASP SPVS-ըOWASP SPVS հոդվածներ։
- Ֆարշադ Աբասի. Pipeline Հարձակումները վատանում են։ Ահա թե ինչպես պատրաստվելOWASP SPVS հոդվածներ։
- Ֆարշադ Աբասի. OWASP SPVS ընդդեմ այլ մատակարարման շղթայի շրջանակներիOWASP SPVS հոդվածներ։
- OWASP: Top 10 CI/CD Անվտանգության ռիսկերOWASP նախագծի էջ։
- SLSA: Ծրագրային արտեֆակտների մատակարարման շղթայի մակարդակներ. slsa.dev.
- OpenSSF: Գոլային փոխանցում. securityscorecards.dev.
