Юу нь буруу болж болох вэ CI/CD pipelines?

Тасралтгүй интеграци ба тасралтгүй хүргэлт (CI/CD) pipelines нь програм хангамжийг "орчин үеийн" аргаар бүтээдэг аливаа програм хангамжийн байгууллагын үндэс суурь юм. Автоматжуулалт нь асар их хүч чадлыг өгдөг боловч ихэнх хөгжүүлэгчид үүний хариуцлагыг алддаг.

Developer: Тийм ээ, бид авна CI/CD аюулгүй байдал ноцтой бөгөөд код засварлагчдыг хүчтэй хянах, хянах commitнэгтгэхээс өмнөх с; ажлын байр болон pipelineахлах ажилтнуудын хяналтан дор ажилладаг тул тэд нууцыг задруулахгүй байхыг хариуцдаг pipelineс. Мөн багажийг энэ талаар мэддэг ажилтнууд суурилуулсан. Юу буруу болж болох вэ?

Эрхэм хөгжүүлэгч ээ, CI/CD Системүүд нь нарийн төвөгтэй. Өргөн хүрээтэй довтолгооны гадаргуу нь хорон санаатнуудыг татдаг. Болгоомжтой байж, хэзээ ч хэт өөртөө итгэлтэй байх ёсгүй.

Заримдаа анхдагч тохиргоог хадгалж, хакеруудын хамгийн сайн найз болдог. Ноцтой алдаанууд гарч болзошгүй CI/CD pipeline системийн тохиргоонд эсвэл үйл явц болон нөхцөл байдлын эргэн тойронд эх сурвалжууд pipeline мөн үүнийг хэрхэн идэвхжүүлдэг.

Энэ бичлэгт бид өөрсдийгөө муу жүжигчдийн оронд тавих болно. Бид эргэцүүллийг уншиж байна гэж төсөөлөөд үз дээ M3M3N70 (Моригийн дурсамж?) болон Намаг уур хилэн харанхуй вэбийн хаа нэгтээ, магадгүй барууны бус хэлээр байдаг ч хорон муу зүйл дэлхий даяар тархаж байгааг хэзээ ч бүү мартаарай.

 

Хуучин сайхан үед энэ нь маш амархан байсан ...

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 товчлуурууд ажиллаж байсан! Бид эхлээд аппликейшнд вакцинжуулалтын өөрчлөлтийг туршиж үзсэн, дараа нь тэдгээр залуус мэдээгүй юм шиг санагдсан тул Sting нэмсэн. Бинго! Ямар кампанит ажил вэ...

Муу этгээд нь AWS түлхүүрүүдийг ашиглан хортой програм хангамжтай өөрчлөгдсөн програмыг байршуулж, дараа нь ийм итгэмжлэлүүдтэй deploy командыг ажиллуулсан. Алдагдсан нууцууд болон түүнд агуулагдсан мэдээлэл pipeline"Ямар кампанит ажил вэ!" гэдэг нь Мементо хөөрхий хохирогчийг сүйрүүлсэн гэсэн үг байх.

Memento бидэнд энд юу гэж хэлдэг вэ гэвэл жишээн дээрх AWS хандалтын түлхүүрүүд шиг нууц мэдээлэл алдагдсаны дараа та нууцыг хүчингүй болгох ёстой (дээрх түлхүүрүүдийг эргүүлнэ үү) тэр даруйҮргэлж байдаг экспозицийн цонх гоожиж буй зүйлсийн хооронд commit мөн нууцаар хүчингүй болгох; Git түүхийг дахин бичих нь хэцүү (хамгийн хатуу ширүүн авторитар улс ч гэсэн түүхийг дахин бичих оролдлого хийсэн боловч ямар ч үр дүнгүй байсан) бөгөөд магадгүй үр дүнгүй байсан (манай найзууд нууц алдагдсан мэдээллийн сангаас өмнө хуулбарласан байж магадгүй юм.) commit). Товчлууруудыг нэн даруй эргүүлж, өртөлтийн цонхны үеэр зорилтот бүртгэлийн үйл ажиллагааны бүртгэлийг уншиж байхдаа залбир!

Магадгүй байгууллагууд тэгэх хэрэгтэй байх урт хугацааны нууцыг ашиглахыг хориглох CI/CD pipelines, мөн тэдгээрийг түр зуурын итгэмжлэлээр солино. Өмнөх жишээнд GitHub үйлдлүүд дэх AWS түлхүүрүүдтэй хамт ашиглах нь илүү аюулгүй юм. OpenID Connect (OIDC) үйлчилгээ үзүүлэгч үйл ажиллагаанд шаардлагатай богино хугацааны итгэмжлэл авах.

Намаг уур хилэнТа үнэхээр азтай байсан! Хуучин үед хатуу кодлогдсон түлхүүрүүдээр скриптүүд алдагддаг байсан нь олон нийтэд хүртээмжтэй S3 хувин дээр ч түгээмэл байсан. Та зүгээр л хувин доторх объектуудыг гүйлгэж, сонирхолтой зүйлсийг олохын тулд бага зэрэг хайлт хийхэд л хангалттай.

Заримдаа байршуулалтад ашигласан хэсэг (энэ жишээнд 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 дээрх “Аюулгүй байдлыг идэвхжүүлэх” гэсэн тэмдэглэгээний нүдийг санаж байна уу, хэдэн байгууллага үүнийг хялбар болгохын тулд идэвхжүүлээгүйг сонгосон бэ? Тэгээд тэдгээр “Хэн ч юу ч хийж чадна"Анхдагчаар зөвшөөрлийн хослолууд уу? Мөн тэдгээр зальтай Jenkins залгаасууд, гэх мэт GitHub OAuth залгаасҮүнийг тохируулсан залуу "Бүх баталгаажсан хэрэглэгчдэд READ зөвшөөрлийг олгох" болон "GitHub репозиторын зөвшөөрлийг ашиглах" гэсэн хоёр сонголтыг сонгосноор бидэнд тэдний бүх төслүүдэд хандах эрх олгосон.

(Женкинс, чамайг үлгэр дуурайл болгосонд уучлаарай 😉

Аюулгүй байдлын зарчмуудыг (бүр донтсон ч гэсэн) сайн баримтал. Нэг нь Анхдагчаар аюулгүй зарчим: хяналтууд нь хамгийн аюулгүй тохиргоонд анхдагчаар тохируулагдах ёстой. Аюулгүй байдлыг дараах байдлаар багтаасан байх ёстой CI/CD хэрэгсэл болон pipelineГэхдээ хэрэглэгчдэд ээлтэй, тохь тухтай байдал нь аюулгүй байдалтай зөрчилддөг.

Jenkins-ийн хувьд, суурилуулсан баталгаажуулалт хэтэрхий эмзэг байна: Jenkins-д суулгасан баталгаажуулалтын механизмыг хэзээ ч бүү ашиглаарай. Дүрд суурилсан эрх олголтын стратеги (“RBAC”) залгаастай гуравдагч талын механизм (SAML, LDAP, Google ...)-г сонгох нь дээр. Мөн маш болгоомжтой байх хэрэгтэй. admin данс.

Ажил хэрхэн хийгдэж байгааг анхаарч үзээрэй pipeline Jenkins дэх файлуудыг зохицуулдаг. Үүнтэй адил Тохиргооны код хэлбэрээр нэмэлт өргөтгөл болон түүний тохиргооны файлууд нь Jenkins тохиргоонд хамаарна.

Өөрөө зохион байгуулагчаас шилжих CI/CD Системийг үүлэн технологид суурилсан SaaS систем рүү шилжүүлэх нь байгууллагын сүлжээнд хажуу тийш шилжих боломжийг олгодог зарим болзошгүй эрсдлийг арилгадаг боловч одоо байгаа дотоод системүүд болон гадны системүүдийн хооронд гадаад холболтыг нээх гэх мэт бусад эрсдлийг нэмж оруулсан. CI/CD хэрэгсэл.

Байгууллагууд хичээх хэрэгтэйcisхатууруулахдаа зохих ёсоор анхаарал тавих хэрэгтэй CI/CD систем нь хамгийн хязгаарлагдмал тохиргооноос эхэлж, хамгийн бага шаардлагатай зөвшөөрлүүдээр аажмаар нээгддэг pipeline алхамууд.

Аюулгүй байдлыг тохируулах CI/CD хэрэгслүүд нь нарийн төвөгтэй байж болно. Олонх нь ихэнх эмзэг байдлыг агуулсан бөгөөд шинэчлэх шаардлагатай залгаасууд эсвэл өргөтгөлүүдтэй байдаг.

Ийм нарийн төвөгтэй хэрэгслүүдэд зориулсан аюулгүй байдлын буруу тохиргооны сканнер эсвэл бенчмаркууд тус болж магадгүй юм.

Код оруулж байна pipeline зугаа цэнгэл, ашгийн төлөөх тушаалууд

M3M3N70Та өмнө нь тушаал оруулахад өртөмтгий үйлдэл болон скриптүүд байдаг Найдваргүй Кодын Тооцооллыг ашиглаж байсан уу?

Энэ хэсэгт дараах зүйлс харагдаж байна 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 анхдагчаар зорилтот репозиторт бичих зөвшөөрөл болон зорилтот репозиторын нууцыг, тэр ч байтугай гадаад сэрээнээс ч авдаг бөгөөд PR-ийн зорилтот репозиторын хүрээнд ажилладаг үйл явдал,
• эх сурвалжаас PR кодыг шалгана уу, итгэмжлэгдээгүй репозитор,
• гэх мэт PR хяналттай контент дээр ажиллаж болох аливаа скриптийг идэвхжүүлэх npm installБолон
• өдөөгчийг идэвхжүүлэхийн тулд нөхцөл ашиглахгүй байх pull_request_target PR-д ямар нэгэн 'энэ PR шалгагдсан' гэсэн шошго оноогдсон тохиолдолд л үйл явдлыг ажиллуулах (гадаад хэрэглэгчид PR-д шошго оноож чадахгүй).

Хоёр дахь жишээ нь найдваргүй оролтыг (асуудал, сэтгэгдэл эсвэл pull request) дамжуулсан аргументуудын эх сурвалж болгон pipeline илэрхийллүүдээр дамжуулан тушаал өгөх. Энэ бол pipeline үйлдлийн системийн командын тарилгын эмзэг байдлын хувилбар.

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

Ажиллуулах үйлдэл нь загвар дээр үндэслэн түр зуурын бүрхүүлийн скриптийг үүсгэдэг бөгөөд $ орлуулсан нь бүрхүүлийн командын тарилгад өртөмтгий болгодог. Хуурамч GitHub бүртгэлтэй халдагч гарчигтай холбоотой асуудал үүсгэж болзошгүй a"; bad_code_goes_here;#, бас бум! 

Намаг уур хилэнӨө, тэр залуус зүгээр л асуудал нээж командын тарилгын үүдийг нээж байсан юм...

GitHub үйлдлүүдэд код гүйцэтгэх эмзэг байдал байсан, жишээ нь гажира-коммент, одоо зассан. Уншина уу "GitHub ажлын урсгал дахь найдваргүй оролт" дэлгэрэнгүй мэдээллийг авна уу.

Түүхийн ёс суртахуун: PR-г эхлээд хянаж үзээгүй бол хэзээ ч итгэмжлэгдээгүй эх сурвалжаас PR хийж болохгүй. Гарал үүслийн баталгаажуулалтыг хатуу чанд мөрдөхөөс бусад тохиолдолд энд "найдваргүй" гэдэг нь хөгжүүлэгчийн бүртгэл хулгайлагдсан байж болзошгүй гэсэн үг байж болно.

 

Санамсаргүй хортой програм хангамж байршуулсан байна!

Тасралтгүй байршуулалт автоматжуулалтын оргил үе боловч зохих зөвшөөрлийн хяналт байхгүйгээс болж энэхүү оргил үе нь бүтэлгүйтэж болзошгүй юм. pipeline урсгал.

Эх сурвалжаас бүрэн автоматжуулсан байршуулалтын эрсдэлүүд commit Үйлдвэрлэлийн системд хортой кодыг илрүүлэлгүйгээр үйлдвэрлэлийн орчинд байршуулах, мөн байршуулах үйл явцад гарсан алдаа нь тасалдал эсвэл тасалдал үүсгэх магадлалыг багтаана.

Эдгээр эрсдэлийг бууруулахын тулд байгууллагууд байршуулах үйл явцад "хатуу завсарлага" хэрэгжүүлэхийг зөвлөдөг бөгөөд энэ нь дараахь зүйлийг шаарддаг. хүний ​​зөвшөөрөл хувилбаруудыг төгсгөлийн орчинд байршуулахаас өмнө.

Тэд хаалгаа хааж байна

Намаг уур хилэнЭдгээр баяр хөөртэй анхдагч нууц үгс CI/CD хэрэгслүүдийг арчиж байна. Нэвтрэх /var/lib/jenkins/secrets/initialAdminPassword одоо үхмэл зам болсон. Олон хэрэгслүүд одоо Ковидын алдартай болгосон 2FA-г өгч байгаа бөгөөд хамгийн залхуу кодын сармагчин ч үүнийг ашиглаж байна!

M3M3N70Бид 2FA-тай тэмцэж байгаа ч тийм ч амар биш. Тэдгээр залуусыг ятгахад хэцүү, учир нь “Scatter Swine” кинонд Твилиотой хамт тоглосонWebAuthn түлхүүрүүдтэй бол энэ нь хамаагүй хэцүү. Ядаж л бид оролдож болно MFA-г тойрч гарахын тулд күүки хулгайлах, гэхдээ хөгжүүлэгчийн хайрцагт нэвтрэх хэрэгтэй.

Олон хүчин зүйлийн баталгаажуулалт нь баталгаажуулалтын нууц алдагдах эрсдлийг хязгаарлах зөв чиглэлд хийсэн сайн алхам юм. Орчин үеийн DevOps хэрэгслүүдийн ихэнх нь MFA-г дэмждэг. Мөн WebAuthn / U2F доорх баталгаажуулалтын түлхүүрүүд (харна уу) FIDO2 төсөл) нь зөв удирдсан тохиолдолд DevOps дахь MFA-ийн хамгийн сайн сонголт байж магадгүй юм.

Намаг уур хилэнDevOps-ын залуус сэрж байна. Тэдний цусанд "хамгийн бага эрх" гэсэн хараал идсэн зүйл бий. Тэд одоо кодлогч сармагчин биш болсон. Бид одоо шүүмжлэгчдэд баригдаж байна.

Үнэндээ, pipelines нь одоо хэдэн жилийн өмнөхөөс арай илүү хүчирхэг болсон бөгөөд сул үйлдэл болон скриптүүдийг арилгаж, нууцаар нуугдсан droppers-ийг илрүүлсэн нэмэлт аюулгүй байдлын туршилтын алхмуудтай болсон. commitбидний булаан авсан багцууд.

Уншигчдад зориулсан асуулт: програм хангамжийг эх сурвалжаас бүтээж, үйлдвэрлэлд нэвтрүүлэх үйл явц нь эрсдэлтэй бизнес мөн үү? Та DevOps-оо дараах шатанд байгааг харж байна уу? хуучны сайхан цаг үеүүд муу залуусын төлөө юу?

Эцсийн зөвлөмж

Хаанаас эхлэх вэ CI/CD pipelineс?

Эхний зөвлөмж энд энгийн байна: Болгоомжтой байгаарай тойм pipelines (тэд бол шүүмжлэлтэй нөөц) аюулгүй байдлын асуудлуудад зориулагдсан. Шалгалтууд нь үнэтэй боловч зайлшгүй шаардлагатай бөгөөд зохих ёсоор хийгдсэн байх ёстой. Шалгагчид юуг анхаарахаа мэдэж байх ёстой. Алхам бүрийг алдаа дутагдалтай эсэхийг шалгах ёстой.

Магадгүй автомат хортой код сканнераар зэвсэглэсэн мэргэжлийн шүүмжлэгчдийн хослол тус болж магадгүй юм.

Хоёр дахь зөвлөмж бол бичдэг хөгжүүлэгчдийг сургах pipelineмөн тэдгээрийг аюулгүй байдалд байлганаАнхаарах зүйлс:

• Урт хугацааны итгэмжлэлийг зохицуулахад учирч болзошгүй хүндрэлээс зайлсхийхийн тулд дотоод болон үүлэн үйлчилгээтэй баталгаажуулалтыг хэрхэн зөв зохицуулах вэ.
• Хэрхэн хязгаарлах вэ pipelineхамгийн бага давуу эрхийн зарчим дахин гэрэлтэж байна.
• Хийх алхмуудыг хэрхэн бичих вэ pipelineхувилбарын пиннинг шиг хуулбарлах боломжтой бөгөөд командын тарилгын эмзэг байдлаас зайлсхийдэг.
• Аюулгүй байдлын үүднээс байршуулалтыг хэрхэн батлах вэ (тэд бол бусад!): аль аюулгүй байдал standards-тэй таарч тохирох ёстой бөгөөд харгалзах чек/хаалтуудыг хэрхэн нэмэх талаар pipelines.

Гурав дахь зөвлөмж бол тохируулах CI/CD зохих ёсоор анхаарал халамж тавьдаг систем. Хүчтэй баталгаажуулалт, анхдагч нууц үг эсвэл аюултай тохиргоо байхгүй, хамгийн бага эрхтэй... Суулгасан залгаасууд болон өргөтгөлүүдийн эмзэг байдлыг анхаарч үзээрэй. Энэ нь дараагийн бичлэгүүдийн гол анхаарал байж магадгүй тул бидэнтэй хамт байгаарай.

Дөрөв дэх зөвлөмж бол хөшүүрэг болгох CI/CD pipelineаюулгүй байдлын автоматжуулалтад зориулсан sЭх кодын шинжилгээ (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 Групп, 2022 оны 1-р сар.
• configure-aws-credentials GitHub үйлдэл болон Amazon Web Services дээр OpenID Connect-ийг тохируулах GitHub ажлын урсгалд байршуулахын тулд AWS командуудыг хэрхэн ажиллуулах талаар дэлгэрэнгүй мэдээлэл авахыг хүсвэл.
• Лобачевски Ж. "GitHub үйлдлүүд болон ажлын урсгалаа аюулгүй байлгах нь 1-р хэсэг: Pwn хүсэлтээс урьдчилан сэргийлэх". GitLab Аюулгүй байдлын лаборатори, 2020 оны 12-р сар.
• Лобачевски Ж. "GitHub үйлдлүүд болон ажлын урсгалуудаа аюулгүй байлгах нь 2-р хэсэг: Найдваргүй оролт". GitLab Аюулгүй байдлын лаборатори, 2021 оны 1-р сар.
• OWASP. "OWASP-ийн шилдэг 10 CI/CD Аюулгүй байдлын эрсдэлүүд"2022 оны 7-р сар.
• Салцер Ж. ба Шредер М. "Компьютерийн систем дэх мэдээллийг хамгаалах нь"1975 оны 4-р сар. Аюулгүй байдлын зарчмууд технологийн хамт хөгжсөн боловч 47 жилийн дараа S&S-ийн ихэнх санаанууд хүчин төгөлдөр хэвээр байна.
• Их Британийн NCSC. "Барилга угсралт болон байршуулалтыг аюулгүй болгох pipeline". Их Британийн Үндэсний Кибер Аюулгүй Байдлын Төв, 2019 оны 2-р сар.