Ի՞նչը կարող է սխալ լինել CI/CD pipelines?

Շարունակական ինտեգրում և շարունակական մատակարարում (CI/CD) pipelines-ը ցանկացած ծրագրային ապահովման կազմակերպության հիմքն է, որը ծրագրային ապահովում է ստեղծում «ժամանակակից» ձևով: Ավտոմատացումը մեծ հզորություն է տալիս, բայց մշակողների մեծ մասը չի գիտակցում դրա հետ կապված պատասխանատվությունը:

ԵրեվակիչԱյո, մենք վերցնում ենք CI/CD անվտանգություն լրջորեն և ուժեղ վերահսկողություն ունենալ կոդի պահպանողների նկատմամբ, վերանայել commitմիաձուլումներից առաջ; աշխատատեղեր և pipelineները պահպանվում են ավագ անձնակազմի կողմից, նրանք հոգ են տանում գաղտնիքներ չարտահոսքի մասին pipelineներ։ Եվ գործիքը տեղադրվել է այդ գործին տիրապետող անձնակազմի կողմից։ Ի՞նչը կարող է սխալ լինել։

Հարգելի՛ մշակող, CI/CD Համակարգերը բարդ են։ Դրա լայն հարձակման մակերեսը գրավում էր չարամիտ գործողներին։ Ավելի լավ է զգույշ լինել և երբեք չափազանց ինքնավստահ չլինել։

Երբեմն լռելյայն կարգավորումը պահպանվում է և դառնում հաքերների լավագույն ընկերը։ Կարող են առկա լինել կարևոր թերություններ։ CI/CD pipeline աղբյուրների, համակարգի կոնֆիգուրացիայի մեջ կամ գործընթացի և համատեքստի շուրջ pipeline և ինչպես է այն ակտիվանում։

Այս գրառման մեջ մենք կդնենք մեզ վատ դերասանների տեղը։ Պատկերացրեք, որ կարդում ենք նրա մտորումները։ M3M3N70 (Memento Mori?) և Ճահճի զայրույթ մութ ցանցի որևէ հատվածում, հավանաբար ոչ արևմտյան լեզվով, բայց մի մոռացեք, որ չարիքը տարածվում է ամբողջ աշխարհում։

 

Հին ու բարի ժամանակներում դա այնքան հեշտ էր…

M3M3N70Վերադառնալով հին ու բարի ժամանակներին՝ մեր գործը շատ հեշտ էր… Զրոյական օրերը հեշտ հասանելի էին, հավելվածները լայնորեն բաց էին՝ հեշտությամբ շահագործվող խոցելիություններով, և մենք կարող էինք ակնթարթորեն կողքից շարժվել։

Ճահճի զայրույթ: Ֆու#@Դժոխք։ Ոմանք դեռ խելագարվել են, բայց ամեն ինչ փոխվել է։ Մեծ տղաները մեծ գումարներ են ծախսել այդ AppSec-ի վրա։

M3M3N70Այո։ Բայց նոր հիմարները մշակողներն են։ Մեզ համար ավելի հեշտ է եղել ընտրել այս տղաների կողմից օգտագործվող գործիքները։ Մասնավորապես, CI-ն ոսկու հանք է։ Ամպային մուտքի տոկեններ, SCM մուտքի տվյալներ, արտադրական տվյալների բազայի գաղտնաբառեր, SSH մասնավոր բանալիներ, CI այլ օգտատերերի մուտքի տվյալներ… Ձանձրալի մշակողների հարցերից իրականությանը անցնելը բավականին պարզ էր։

Ծրագրային ապահովման կառուցման, փորձարկման և տեղակայման ավտոմատացում՝ օգտագործելով CI/CD Գործիքը հաճախ անհրաժեշտություն է ունենում հրամաններին գաղտնիքներ փոխանցելու քայլ առ քայլ։ Եվ հաճախ դրանք արտահոսում են՝ ունենալով տխրահռչակ հետևանքներ։

Pipelineկարիք ունեն գաղտնիքների, որոնք երբեմն արտահոսում են

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Հնարավոր է՝ հին լավ ժամանակները Գիտի պատմության մեջ գտնելն էր .env ֆայլ (մշակողը մոռացել է այն ավելացնել) .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

որը օգտագործվել է GitHub-ի աշխատանքային հոսքում .github/deploy.yaml որը պարունակում էր այսպիսի բան՝

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: վա՜յ։ Այդ AWS ստեղները աշխատում էին։ Մենք նախ փորձարկեցինք հավելվածում inocuos-ի փոփոխությունը, ապա ավելացրինք sting-ը, քանի որ այդ տղաները, կարծես, անտեղյակ էին։ Բինգո։ Ի՜նչ արշավ…

Չարագործը պարզապես օգտագործել է AWS բանալիները՝ վնասակար ծրագրով փոփոխված հավելվածը վերբեռնելու համար, ապա գործարկել է deploy հրամանը՝ օգտագործելով այդ տվյալները։ Արտահոսած գաղտնիքները, ինչպես նաև դրանցում պարունակվող տեղեկատվությունը pipeline«Ի՜նչ արշավանք!» հավանաբար նշանակում է, որ Մեմենտոն քաոս է պատճառել խեղճ զոհին։

Memento-ն մեզ այստեղ ասում է, որ գաղտնի արտահոսքի դեպքում, ինչպես օրինակ՝ AWS մուտքի բանալիներում, դուք պետք է չեղարկեք գաղտնիքը (պտտեք վերը նշված բանալիները): անհապաղՄիշտ կա մի էքսպոզիցիայի պատուհան արտահոսքի միջև commit և գաղտնի անվավերացումը։ Git-ի պատմությունը վերաշարադրելը դժվար է (նույնիսկ ամենակոշտ ավտորիտար պետությունը փորձեց նման պատմության վերաշարադրում, բայց ապարդյուն) և, հավանաբար, անարդյունավետ (մեր ընկերները կարող էին կլոնավորել գաղտնի արտահոսքի պահոցից առաջ) commit)։ Անմիջապես պտտեք ստեղները և աղոթեք՝ միաժամանակ կարդալով թիրախային հաշվի գործունեության գրանցամատյանները ազդեցության պատուհանի ընթացքում։

Հավանաբար կազմակերպությունները պետք է արգելել երկարաժամկետ գաղտնիքների օգտագործումը CI/CD pipelines, և փոխարինել դրանք ժամանակային մուտքագրումներով: Նախորդ օրինակում, որտեղ GitHub գործողություններում AWS բանալիներ կային, ավելի անվտանգ է օգտագործել OpenID Connect (OIDC) մատակարար գործողությունների համար անհրաժեշտ կարճաժամկետ լիազորագրեր ստանալու համար։

Ճահճի զայրույթԴուք շատ բախտավոր էիք։ Հին ժամանակներում կոշտ կոդավորված բանալիներով սկրիպտների արտահոսքը տարածված պրակտիկա էր, նույնիսկ հանրությանը հասանելի S3 փաթեթներում։ Ձեզ անհրաժեշտ էր միայն անցնել փաթեթի օբյեկտների միջով և որոշ grepping անել՝ հետաքրքիր բաներ գտնելու համար։

Երբեմն տեղակայման համար օգտագործվող տարածքը (այս օրինակում՝ AWS S3 դույլը) բաց էր արտաքին օգտատերերի կողմից ընթերցման համար՝ կարգավորման թերության պատճառով (որը չէր հայտնաբերվել): Ճահճի զայրույթ օգտագործվածը մոտավորապես այսպիսի բան էր՝

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

Բուքետը, հավանաբար, ստեղծվել է նախապատրաստման ձևանմուշում, որը կարող էր ավտոմատ կերպով սկանավորվել անվտանգության թերությունների համար։

Գործիքի լռելյայն կարգավորումը մեզ համար խաղալիք էր

Կոնկրետ օրինակներ բերելու համար եկեք խոսենք Jenkins, ամենատարածված CI գործիքներից մեկը։

Ճահճի զայրույթՀիշո՞ւմ եք Ջենկինսում «Միացնել անվտանգությունը» նշման վանդակը, և քանի՞ կազմակերպություն որոշեց չակտիվացնել այն հարմարության համար։ Եվ այդ «Ամեն մեկը կարող է անել ամեն ինչ«թույլտվությունների համադրություններ որպես լռելյայն՞»: Եվ այդ նյարդայնացնող Jenkins պլագինները, ինչպիսիք են GitHub OAuth հավելվածԱյն կարգավորողը ընտրել է և՛ «Տրամադրել կարդալու թույլտվություններ բոլոր հաստատված օգտատերերին», և՛ «Օգտագործել GitHub պահոցի թույլտվությունները» տարբերակները՝ մեզ հասանելիություն տալով իրենց բոլոր նախագծերին։

(Ներողություն, Ջենկինս, որ քեզ օրինակ բերեցի 😉)

Պահպանեք անվտանգության սկզբունքների հմուտ լինելը (նույնիսկ կախվածություն): Մեկը Անվտանգ է լռելյայնորեն սկզբունք. կառավարման համակարգը պետք է լռելյայնորեն լինի հնարավորինս անվտանգ կարգավորումների վրա։ Անվտանգությունը պետք է ներկառուցված լինի CI/CD Գործիքներ եւ pipelineսկզբից մինչև վերջ, այլ ոչ թե երկրորդական մտածողություն։ Սակայն օգտագործողի համար հարմարությունը և հարմարավետությունը հաճախ բախվում են անվտանգության հետ։

Ջենկինսի դեպքում ներկառուցված նույնականացումը չափազանց փխրուն է. երբեք մի օգտագործեք Jenkins-ի ներկառուցված նույնականացման մեխանիզմներըԱվելի լավ է ընտրել երրորդ կողմի մեխանիզմ (SAML, LDAP, Google…)՝ դերերի վրա հիմնված լիազորման ռազմավարության («RBAC») հավելվածով։ Եվ չափազանց զգույշ եղեք դրա հետ։ admin հաշիվ.

Հոգ տանել աշխատանքի և pipeline Jenkins-ում ֆայլերը մշակվում են։ Նույնը վերաբերում է նաև «Կարգավորում-որպես-Կոդ» հավելված և դրա կարգավորման ֆայլերը, որոնք վերաբերում են Jenkins կոնֆիգուրացիային։

Անցում ինքնասպասարկման ռեժիմից CI/CD համակարգերի ամպային SaaS համակարգերին անցնելը վերացնում է որոշ պոտենցիալ ռիսկեր, որոնք թույլ են տալիս կողմնային տեղաշարժ կազմակերպության ցանցի ներսում, բայց ավելացնում է այլ ռիսկեր, ինչպիսիք են առկա ներքին համակարգերի և արտաքինացված համակարգերի միջև արտաքին կապերի բացման անհրաժեշտությունը։ CI/CD գործիք.

Կազմակերպությունները պետք է իրականացնենcisկարծրացման ժամանակ անհրաժեշտ զգուշություն ցուցաբերեք CI/CD համակարգ՝ սկսած ամենախստապահանջ կարգավորումներից և աստիճանաբար բացվելով նվազագույն պահանջվող թույլտվություններով pipeline քայլեր:

Անվտանգության կարգավորումը CI/CD Գործիքները կարող են բարդ լինել։ Շատերն ունեն պլագիններ կամ ընդլայնումներ, որոնք ունեն խոցելիությունների մեծ մասը և պետք է թարմացվեն։

Նման բարդ գործիքների անվտանգության սխալ կարգավորման սկաներները կամ չափորոշիչները կարող են օգնել։

Կոդի ներարկում pipeline հրամաններ զվարճանքի և շահույթի համար

M3M3N70Դուք երբևէ օգտագործե՞լ եք Untrusted Code Checkouts-ը, որը խոցելի է հրամանների ներարկման նկատմամբ։

Այս բաժինը ցույց է տալիս, որ pipeline ինքնին կարող է ունենալ կոդավորման սխալներ, որոնք թույլ են տալիս չարագործներին ներարկել կամայական կոդի կատարում pipeline առանց փոխելու pipeline աղբյուրը ինքնինՕրինակ՝ PR-ի միջոցով

Առաջին օրինակը անհաջող GitHub աշխատանքային հոսք:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

Համադրելով pull_request_target Անվստահելի PR-ի բացահայտ ստուգմամբ աշխատանքային հոսքի ակտիվացումը վտանգավոր պրակտիկա է, որը կարող է հանգեցնել պահոցի վտանգի։ Օրինակում՝ հետևյալ դժբախտ համադրությունը.

• pull_request_target իրադարձություն, որն ըստ լռելյայնի ունի գրելու թույլտվություն նպատակային պահոցում և նպատակային պահոցի գաղտնիքներում, նույնիսկ արտաքին fork-ներից, և աշխատում է PR-ի նպատակային պահոցի համատեքստում,
• Ստուգեք PR կոդը աղբյուրից, անվստահելի պահոց,
• գործարկել ցանկացած սկրիպտ, որը կարող է գործել PR-ի կողմից վերահսկվող բովանդակության վրա, ինչպես օրինակ՝ npm install, եւ
• պայման չօգտագործելով ակտիվացման համար pull_request_target իրադարձությունը կգործարկվի միայն այն դեպքում, եթե PR-ին նշանակված է «այս PR-ը ստուգվել է» պիտակը (արտաքին օգտատերերը չեն կարող պիտակներ նշանակել PR-ին):

Երկրորդ օրինակը վերցնում է անվստահելի մուտքային տվյալներ (խնդրից, մեկնաբանությունից կամ pull request) որպես աղբյուր՝ a-ին փոխանցված արգումենտների համար pipeline հրամանը արտահայտությունների միջոցով։ Սա է pipeline OS հրամանի ներարկման խոցելիության տարբերակը։

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

Գործարկման գործողությունը ստեղծում է ժամանակավոր shell սկրիպտ՝ հիմնված ձևանմուշի վրա, որի դեպքում՝ $ փոխարինվել է, ինչը այն խոցելի է դարձնում shell հրամանների ներարկման նկատմամբ: Կեղծ GitHub հաշիվ ունեցող հարձակվողը կարող է խնդիր ստեղծել վերնագրի հետ a"; bad_code_goes_here;#, և բում! 

Ճահճի զայրույթԱխ, այդ տղաները պարզապես խնդիր բացելով՝ բացում էին հրամանի ներարկման դուռը…

GitHub գործողություններում կային կոդի կատարման խոցելիություններ, ինչպիսիք են՝ գաջիրա-մեկնաբանություն, այժմ շտկված է։ Խնդրում եմ կարդալ «Անվստահելի մուտք GitHub-ի աշխատանքային հոսքերում» լրիվ մանրամասներով:

Պատմության բարոյականությունը. Երբեք մի՛ ստուգեք և մի՛ կառուցեք PR-ներ անվստահելի աղբյուրներից՝ նախապես PR-ը չստուգելով։ «Անվստահելի» արտահայտությունը, բացառությամբ ծագման խիստ նույնականացման դեպքերի, կարող է նշանակել ցանկացած պոտենցիալ առևանգված մշակողի հաշիվ։

 

Անկանխատեսելի վնասակար ծրագրի տեղակայում այստեղ։

Շարունակական տեղակայում ավտոմատացման գագաթնակետն է, բայց այդ գագաթնակետը կարող է խափանվել համապատասխան հաստատման վերահսկողության բացակայության պատճառով pipeline հոսք

Աղբյուրից լիովին ավտոմատացված տեղակայման ռիսկերը commit Արտադրական համակարգերի համար ռիսկերը ներառում են վնասակար կոդի արտադրական միջավայրերում տեղակայման հնարավորությունը առանց այն հայտնաբերելու, ինչպես նաև տեղակայման գործընթացում սխալների հնարավորությունը, որոնք կարող են խափանումներ կամ անջատումներ առաջացնել։

Այս ռիսկերը մեղմելու համար կազմակերպություններին հաճախ խորհուրդ է տրվում իրենց տեղակայման գործընթացում իրականացնել «լուրջ ընդմիջում», որը պահանջում է մարդկային հավանություն նախքան թողարկումները տեղակայվեն վերջնական միջավայրերում։

Նրանք փակում են դռները

Ճահճի զայրույթԱյդ ուրախ լռելյայն գաղտնաբառերը CI/CD գործիքները մաքրվում են։ Մուտք գործելը /var/lib/jenkins/secrets/initialAdminPassword այժմ փակուղի է։ Շատ գործիքներ այժմ ապահովում են 2FA, որը Covid-ը դարձրեց հանրաճանաչ, և նույնիսկ ամենածույլ կոդավորողը օգտագործում է այն։

M3M3N70Մենք պայքարում ենք 2FA-ի դեմ, բայց դա այդքան էլ հեշտ չէ։ Դժվար է նրանց խաբել, քանի որ «Scatter Swine»-ն արեց Twilio-ի հետWebAuthn բանալիներով դա շատ ավելի դժվար է։ Ամեն դեպքում, մենք կարող ենք փորձել գողանալ թխուկներ՝ MFA-ն շրջանցելու համար, բայց պետք է ներխուժել մշակողի արկղը։

Բազմագործոն նույնականացումը լավ քայլ է ճիշտ ուղղությամբ՝ նույնականացման գաղտնիքների արտահոսքի ռիսկը սահմանափակելու համար: Ժամանակակից DevOps գործիքների մեծ մասը աջակցում է MFA-ին: Եվ նույնականացման բանալիները WebAuthn / U2F-ի ներքո (տե՛ս FIDO2 նախագիծ) թերևս DevOps-ում MFA-ի համար լավագույն տարբերակն են, եթե ճիշտ կառավարվեն։

Ճահճի զայրույթDevOps-ի տղաները արթնանում են։ Նրանց արյան մեջ է «նվազագույն արտոնությունների» բանը։ Եվ նրանք այլևս կոդի կապիկներ չեն։ Հիմա մեզ բռնում են քննադատները։

Ի դեպ, pipelines-ը այժմ մի փոքր ավելի հզոր են, քան մի քանի տարի առաջ, թույլ գործողություններն ու սկրիպտները հեռացված են, և անվտանգության լրացուցիչ ստուգման քայլերով նույնիսկ հայտնաբերվել են մեր գաղտագողի թաքնված dropper-ները։ commitներ և փաթեթներ, որոնք մենք առևանգել ենք։

Հարց ընթերցողի համար. արդյո՞ք ծրագրային ապահովումը սկզբնաղբյուրներից կառուցելու և արտադրության մեջ տեղակայելու գործընթացը ռիսկային գործ է: Կարո՞ղ եք տեսնել ձեր DevOps-ը այս փուլում: հին լավ ժամանակներ չարագործների համար՞

Վերջնական հանձնարարականներ

Որտեղից սկսել CI/CD pipelines?

Առաջին խորհուրդը պարզ է. զգուշորեն տեսություն pipelines (նրանք են քննադատական ռեսուրսներ) անվտանգության հարցերի համար: Վերանայումները թանկ են, բայց անհրաժեշտ և պետք է պատշաճ կերպով կատարվեն: Վերանայողները պետք է տեղյակ լինեն, թե ինչին ուշադրություն դարձնել: Յուրաքանչյուր քայլ պետք է ստուգվի թերությունների առկայության համար:

Հնարավոր է՝ ավտոմատացված վնասակար կոդի սկաներներով զինված փորձագիտական ​​​​գրախոսողների համադրությունը կարող է օգնել։

Երկրորդ առաջարկությունն այն է, որ վերապատրաստել գրող ծրագրավորողներին pipelineև պահպանել դրանք անվտանգության մեջՀաշվի առնելի բաներ՝

• Ինչպես ճիշտ կարգավորել ներքին և ամպային ծառայությունների նույնականացումը՝ խուսափելով երկարաժամկետ մուտքագրման տվյալների մշակման անհարմարությունից։
• Ինչպես սահմանափակել pipelineդեպի այն ռեսուրսների ճշգրիտ հավաքածուն, որոնց հասանելիություն է անհրաժեշտ։ Նվազագույն արտոնությունների սկզբունքը կրկին փայլում է։
• Ինչպես գրել պատրաստման քայլերը pipelineվերարտադրելի են, ինչպիսիք են տարբերակի ամրացումը և հրամանի ներարկման խոցելիություններից խուսափելը։
• Ինչպես հաստատել տեղակայումները անվտանգության տեսանկյունից (դրանք ուրիշներ են!): որ անվտանգության standards-ը պետք է համապատասխանեցվի և ինչպես ավելացնել համապատասխան չեկեր/դարպասներ pipelines.

Երրորդ առաջարկությունն այն է, որ կարգավորել CI/CD համակարգը պատշաճ խնամքովՈւժեղ նույնականացում, լռելյայն գաղտնաբառերի կամ անապահով կարգավորումների բացակայություն, նվազագույն արտոնություններ… Զգույշ եղեք տեղադրված պլագինների և ընդլայնումների խոցելիությունների հետ։ Սա կարող է լինել հաջորդ գրառումների ուշադրության կենտրոնում, խնդրում ենք հետևել նորություններին։

Չորրորդ առաջարկությունն այն է, որ լծակներ են CI/CD pipelineանվտանգության ավտոմատացման համար. Աղբյուրի կոդի վերլուծություն (SAST), աղբյուրի կազմի վերլուծություն (SCA), գաղտնի արտահոսքի սկանավորումը, վնասակար ծրագրերի դեմ պայքարի գործիքները, կոնտեյներների անվտանգության սկաներները կամ ավտոմատացված աշխատանքային ժամանակի դետեկտորները (DAST և վնասակար ծրագրեր) կարող են պարբերաբար գործարկվել pipelineԵվ ձեր կազմակերպությունը կարող է պարտադրել standardանվտանգության սկանավորման ծածկույթի մասին CI/CD.

Հիշեցրեք, որ այս գործիքները դեռևս չեն հեռացնում փորձագետների կարծիքը հավասարումից, հակառակ դեպքում դուք կարող եք կեղծ անվտանգության զգացում ունենալ։

Եթե ​​դուք հմուտ եք OWASP-ի լավագույն տասնյակների հարցում, ապա վերջերս կատարված լավ նախագիծ է... OWASP-ի լավագույն 10-յակը CI/CD Անվտանգության ռիսկ.

Հրաժարման նշում

(1) Այս գրառման օրինակները օգտագործում են GitHub-ը որպես SCM, AWS-ը որպես ամպային մատակարար և GitHub Actions-ը կամ Jenkins-ը որպես CI/CD գործիք։ Դրանք իրենց այլընտրանքներից ավելի թույլ / անվտանգ չեն։ Մամուլի վատ մտադրություն չկա։ Այս գործիքները հզոր են և պետք է համապատասխանաբար օգտագործվեն։

(2) M3M3N70 և Ճահճի զայրույթ հորինված կերպարներ են։ Ցանկացած նմանություն անձանց կամ խմբերի հետ՝ կենդանի թե մահացած, պարզապես պատահական է… թե՞ ոչ։

Ավելին կարդալու համար

• Հեյմոր, Ա. և այլք։ «10 իրական պատմություն այն մասին, թե ինչպես ենք մենք փոխզիջման գնացել» CI/CD pipelineս »NCC Group, հունվար 2022։
• configure-aws-credentials GitHub գործողություն և OpenID Connect-ի կարգավորումը Amazon Web Services-ում GitHub աշխատանքային հոսքերում տեղակայման համար AWS հրամաններ գործարկելու մանրամասների համար։
• Լոբաչևսկի Ջ. «Ձեր GitHub գործողությունների և աշխատանքային հոսքերի անվտանգ պահպանումը. Մաս 1. pwn հարցումների կանխարգելում»GitLab անվտանգության լաբորատորիա, դեկտեմբեր 2020։
• Լոբաչևսկի Ջ. «Ձեր GitHub գործողությունների և աշխատանքային հոսքերի անվտանգ պահպանումը. Մաս 2. Անվստահելի մուտքագրում»GitLab անվտանգության լաբորատորիա, հունվար 2021։
• OWASP-ը։ «OWASP-ի լավագույն 10-յակը» CI/CD Անվտանգության ռիսկեր»2022 թվականի հուլիս։
• Սալցեր Ջ. և Շրյոդեր Մ. «Տեղեկատվության պաշտպանությունը համակարգչային համակարգերում»1975թ. ապրիլ։ Անվտանգության սկզբունքները զարգացան տեխնոլոգիայի հետ մեկտեղ, բայց 47 տարի անց գիտության և տեխնիկայի գաղափարների մեծ մասը մնում է ուժի մեջ։
• Մեծ Բրիտանիայի NCSC: «Ապահովեք կառուցումը և տեղակայումը» pipeline"Մեծ Բրիտանիայի ազգային կիբերանվտանգության կենտրոն, փետրվար 2019։