Dina postingan kami sateuacanna ngeunaan CI/CD Pipelines, urang nempo kumaha carana nge-hack a CI/CD skenario anu sigana dijaga.
Hayu urang émut deui poin urang dina postingan sateuacanna: urang mimitian ku sababaraha pipeline anu rentan ka Karacunan Teu Langsung Pipeline eksekusi (I-PPE) sareng, pikeun ngalereskeunana, kami mutuskeun pikeun ngabagi pipeline jadi dua:
- Anu 1st pipeline (Build CI), aman pikeun D-PPE sareng I-PPE, bakal mariksa kode PR, ngadamel build, sareng ngahasilkeun artefak
- Anu ka-2 pipeline (Test CI), ogé aman pikeun D-PPE sareng I-PPE bakal mariksa kodeu Dasar (pikeun nyingkahan modifikasi skrip shell) sareng ngaéksekusi skrip asli ngalawan artefak.
- Pikeun nyingkronkeun Test CI pipeline pikeun ngajalankeun SAANGGEUS CI Build pipeline, kami dipaké alur_jalan pemicu.
Urang ngaranan ieu salaku Skenario #3.
Sanaos, sapertos anu parantos disebatkeun dina tulisan éta, aya solusi sanés, kami mutuskeun pikeun nerapkeun "solusi" ieu pikeun alesan pedagogis, supados kami tiasa nalungtik langkung jero kana karentanan CI/CD pipelines.
Saatos éta, urang ningali kumaha carana ngaretas skénario ieu ku cara ngaracun artefakIeu anu urang sebut Karacunan Artefak, nyaéta kamampuan pikeun ngarobih (hack) pipeline logika ku cara ngarobah hiji pipeline artefak.
Naon masalahna sareng pendekatan ieu? Kami ningali yén masalahna timbul nalika aya pangguna "nyieun" anu énggal pipeline.
Upami pangguna muka PR anu ngandung anu énggal pipeline, GitHub bakal ngalaksanakeun éta pipeline (dibéré sababaraha sarat, sakumaha anu urang tingali dina postingan).
Pangguna teras tiasa ngadamel anu énggal pipeline kalawan nami anu sami sareng Build CI!! Leres, éta héran, tapi GitHub ngamungkinkeun anjeun pikeun nyiptakeun dua pipelines anu ngaranna sarua!!
Nalika pangguna muka PR kalayan parobihan ieu, anu "anyar" pipeline bakal dieksekusi (ngunggah artefak anu diracun) sareng Deploy CI pipeline bakal dijalankeun saatos éta, hasilna skrip cangkang "dirobih" nimpa skrip cangkang "asli" anu aya di pipeline rohangan gawé. Janten, "solusi" ieu henteu nyingkahan kerentanan I-PPE (sakumaha anu urang tiasa tingali di handap)
Naon masalahna? Sahenteuna, aya sababaraha masalah:
- heula, Kumaha carana mastikeun yén prosés pangwangunan henteu diganggu? Dina skénario ieu, pangguna jahat parantos tiasa ngarobih prosés ngawangun anu dimaksud ku cara nganggo pipeline pikeun nyieun artefak racun.
- Bréh, Kumaha urang bisa meunteun asal-usul hiji artefak?
Patarosan-patarosan ieu ngalungkeun urang kana panangan Atestasi Parangkat Lunak domainna!!
Atestasi Parangkat Lunak
An kandang mangrupa sapotong tina data ngagambarkeun bukti hiji kajadian. Di dunya nyata, urang umumna nyebut ieu certifications.
Contona, nalika laboratorium nguji getih anjeun, data ngeunaan tés éta dirékam sareng disertifikasi. Hasil tés getih nyaéta tiasa diverifikasi jeung ngabasmi.
Langkung caket kana domain IT urang, anjeun tiasa nebak naon tarjamahan tina prosés ieu kana, contona, prosés kompilasi.
Inpormasi ngeunaan lingkungan sareng alat server kompilasi, bahan (kode sumber), sareng produk/artéfak (kode binér) bakal janten bagian tina atéstasi sapertos kitu.
Tangtosna, atestasi kedah dihasilkeun ku attestor anu diidinan (dioténtikasi sareng henteu tiasa dibantah) pikeun masihan kredibilitas.
Sigana mah, sababaraha di antara anjeun panginten mikir .. sareng naon ari bédana antara tanda tangan sareng atestasi?
Kode tanda tangan jeung attestations
Dina tingkat anu luhur, hiji tekenan dijieun ngagunakeun pasangan konci sareng artefak. Pasangan konci diwangun ku konci publik sareng konci pribadi.
Pangguna nandatangan artefak nganggo konci pribadi, sareng anu sanésna tiasa mastikeun tanda tangan nganggo konci umum. Konci pribadi kedah dirahasiakeun, tapi konci umum disebarkeun sacara lega.
Tanda tangan tiasa dianggo pikeun ngabuktikeun yén anu gaduh konci pribadi nganggo konci pribadi pikeun nandatangan artefak éta.
Tandatangan ulah ngabuktikeun
- Pangguna maksud pikeun nandatangan artefak (aranjeunna panginten parantos ditipu), atanapi
- Niat pangguna pikeun ngalakukeun naon waé klaim khusus ngeunaan artefak
jeung Sertipikat, tinimbang nandatangan artefak sacara langsung, pangguna nyiptakeun sababaraha jinis surat penting yen ngarebut niat maranéhna tukangeun nandatangan artefak sareng naon waé klaim khusus dijieun salaku bagian tina tanda tangan ieu.
Kerangka Atestasi In-toto
Kerangka anu paling umum nyaéta Kerangka Atestasi in-toto
- ngahartikeun a standard format pikeun atestasi anu ngabeungkeut subjek, artefak anu dijelaskeun, kana metadata anu diauténtikasi ngeunaan artefak éta
- nyayogikeun sakumpulan predikat anu tos ditetepkeun sateuacanna pikeun ngirimkeun metadata anu diauténtikasi di sakumna ranté suplai perangkat lunak
Hayu urang bahas langkung rinci ngeunaan format atestasi.
An Nyaksian nyaeta dokumén anu ditandatanganan sacara digital anu ngandung Pernyataan.
nu parnyataan nyaéta lapisan tengah tina atestasi, anu ngabeungkeut kana hal-hal anu khusus taluk sareng sacara jelas ngaidentipikasi jinis-jinisna prédikat:
- taluk: a rujukan anu aman sacara kriptografis kana artefak (biasana ngalangkungan hash), sareng
- Predikat: sakumpulan hal anu khusus klaim Ngeunaan artefak éta disebut Pernyataan. Klaim ieu tiasa dianggo pikeun ngébréhkeun (sareng engké ngabuktikeun) naon waé anu anjeun tiasa pikirkeun! Éta tiasa ngagambarkeun persetujuan manual, asal-usul artefak, hasil tés otomatis, jalur audit, atanapi langkung seueur deui!
Nalika Pernyataan ieu ditandatanganan sacara kriptografis, éta teras disebut salaku Nyaksian
Ku cara kieu, salaku conto, Alice nyieun Pernyataan ngeunaan hiji artefak teras nandatanganan éta nganggo konci pribadina, pikeun nyieun hiji Atestasi.
- Bob teras tiasa pariksa tanda tangan dina Atestasi éta, ngamungkinkeun anjeunna percaya kana klaim-klaim éta jero.
Bob teras tiasa nganggo klaim éta mutuskeun naha artefak ieu diidinan dianggo atanapi henteu.
Naha Atestasi tiasa ngabantosan ngungkulan Keracunan Artefak?
Saatos bubuka kana Atestasi ieu, hayu urang balik deui kana masalah urang. Kumaha atestasi tiasa ngabantosan urang pikeun ngarengsekeun masalah urang, nyaéta pikeun nyingkahan karacunan artefak?
Pangguna jahat éta tiasa nyiptakeun artefak kalayan ngalangkungan mékanisme "resmi", nyaéta ku cara nganggo na pipeline pikeun ngahasilkeun artefak.
Bakal endah pisan upami urang tiasa ngabuktikeun yén artefak anu diunduh parantos diwangun nganggo sistem resmi pipelines. Ieu ngan ukur salah sahiji conto tina naon anu urang sebut "Titik gangguan", tapi tiasa waé aya seueur deui anu sanés.
Sakumaha anjeun tiasa tingali dina gambar di luhur, titik-titik gangguan éta aya sababaraha. Ku cara kieu, konsumen pipeline (Tes CI dina conto urang) kedah meunteun integritas prosés pangwangunan ogé integritas artefak éta sorangan.
Dina conto urang, artefak anu diracun parantos didamel ku cara ngenalkeun artefak énggal (anu diracun) pipeline anu ngaganggu prosés ngawangun. Tapi pangguna jahat éta tiasa waé:
- ngarobih kode saatos dipariksa ti SCM pikeun ngahasilkeun binér jahat
- ngaganti binér katuhu anu dihasilkeun ku kompilasi ku binér jahat anu sanés
- ngaruksak Artefak Registry sareng unggah artefak anu diracun anu didamel ku cara sanés
- jsb
Sakumaha anjeun tiasa tingali, tiasa aya sababaraha titik "gangguan".
Naon anu penting di dieu? Tangtosna pikeun ngajaga sadaya titik "gangguan" éta. Tapi, dina ahirna, anu paling penting nyaéta yén "konsumén" artefak tiasa meunteun integritas artefak, sareng mutuskeun naha badé neraskeun atanapi henteu.
Urang tiasa ngira-ngira integritas hiji artefak ku dua cara.
Salah sahijina nyaéta ku cara ngaevaluasi kabuktosan tina artefak éta.
Ku cara ngahasilkeun hiji Atestasi Asal-usul, kami nyayogikeun metadata anu mangpaat (anu diauténtikasi kalayan leres sareng henteu dibantah) ngeunaan artefak. Dina conto-conto di handap ieu, urang bakal nganggo UYAH Xygeni (Lapisan Pangesahan Parangkat Lunak pikeun Kapercayaan), komponén pikeun ngahasilkeun, ngadaptar, sareng verifikasi pangesahan parangkat lunak.
- name: Building ... run: | # mvn will compile and create target/MyApp.war mvn clean package - name: Generating provenance run: | #!/usr/bin/env bash shopt -s expand_aliases alias salt=$PWD/salt_pro/xygeni_salt/salt echo " " echo "-----------" echo "Generating Provenance with CLI ..." salt at slsa \ --basedir ${GITHUB_WORKSPACE}/target \ --key="${PRIVATE_KEY}" \ --public-key=${GITHUB_WORKSPACE}/Test1_public.pem \ --key-password=${KEY_PASSWD} \ --output-unsigned=${GITHUB_WORKSPACE}/cli_provenance_${PIPELINE}_unsigned.json \ --pipeline ${PIPELINE} --pretty-print \ --file ./MyApp.war Dina kode di luhur, anjeun tiasa ningali aya léngkah anu ngawangun file perang sareng léngkah kadua anu ngahasilkeun Atestasi Asal-usulPikeun ngalakukeun éta, pipeline ngagunakeun konci pribadi sareng ogé ngalebetkeun konci publik dina atestasi.
Di tukangeun layar, Xygeni's uyah paréntah nyimpen atestasi dina ledger (alias pendaptaran atestasi, Rékam dina kasus urang tapi anjeun tiasa nganggo anu sanés). Saatos éta, konsumen pipeline tiasa kalebet Xygeni's Mesin Verifikasi pikeun mastikeun asal-usul artefak sareng meunteun integritas artefak éta.
- name: 'Verifying the attestation' run: | #!/usr/bin/bash echo " " echo "-------" # Calculate sha256sum for the artifact SHA_SUM=$(sha256sum ./MyApp.war | cut -f1 -d ' ') # Recover the attestation Id from the sha256sum ATT_ID=$(echo $(salt -q registry search --digest sha256:$SHA_SUM --format json) | jq -r .[-1].gitoidSha256) echo " " echo "-------" # Download the provenance attestation echo "Downloading the provenance attestation ..." salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json echo " " echo "-------" echo "Verifying provenance ..." salt verify \ --basedir ${GITHUB_WORKSPACE} \ --attestation=${GITHUB_WORKSPACE}/provenance_kk.signed.json \ --public-key=${GITHUB_WORKSPACE}/Test1_public.pem \ --file ./MyApp.war Prosés verifikasi ngaevaluasi:
- nu artefak sha256sum valid (contona aya katerangan ngeunaan "subjék" éta), sareng
- nu konfirmasi parantos diverifikasi kalayan leres (éta parantos dihasilkeun ku ngagunakeun konci pribadi anu nyukupan)
Prosés verifikasi ieu tiasa nangtoskeun yén artefak sareng atestasi éta valid.
Tapi, sakumaha anu anjeun émut, dina kasus urang, artefak éta dihasilkeun ku "jahat" pipeline (nyaéta sanés aslina ku modifikasi pipeline). Teras urang kedah teraskeun sareng mariksa aspék anu sanés: éta artefak éta dihasilkeun ku "asli" pipeline, lain nu séjénna.
Pikeun ngalakukeun éta, cukup lebetkeun garis saderhana pikeun mariksa kaayaan éta, contona:
echo " " echo "-------" # Download the provenance attestation echo "Downloading the provenance attestation ..." salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json WFR=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json |base64 -d | jq -r .predicate.buildDefinition.internalParameters.environment.GITHUB_WORKFLOW_REF) echo $WFR | grep cicd_top10_3_salt\/.github\/workflows\/build.yml Pamariksaan tambahan ieu bakal gagal upami artefak éta henteu dihasilkeun ku "brankas" urang. pipeline.
Upami artefak éta dihasilkeun ku aslina urang pipeline (cicd_top10_3_salt/.github/workflows/build.yml), paréntah grep bakal suksés, upami henteu, éta bakal gagal, ngalanggar pipeline sareng ngabatalkeun léngkah-léngkah salajengna.
"Pambangun" pipeline ngan ukur hiji titik gangguan anu kedah dipariksa, tapi, sapertos anu parantos disebatkeun sateuacanna, aya sababaraha titik gangguan sanés anu kedah dipariksa.
Salaku conto, Kumaha upami kode sumberna parantos dirobah saatos checkout repo sareng sateuacan paréntah build? Dina hal ieu, kode anu bade diwangun teu sami sareng anu disimpen dina SCM.
Pikeun mariksa titik gangguan ieu gampang pisan sapertos mariksa hash bahan dina unggal léngkah.
SHA_ATT_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[0].predicate.materials[].digest[]) SHA_STEP_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[3].predicate.materials[0].digest[]) conclusions
Singkatna, hiji Atestasi Parangkat Lunak nyaéta hiji pernyataan anu dijieun ngeunaan hiji perangkat lunak, nyaéta pernyataan anu diauténtikasi (metadata) ngeunaan artefak perangkat lunak atanapi kumpulan artefak perangkat lunak.
Atestasi perangkat lunak mangrupikeun generalisasi tina artefak atah/penandatanganan kode. Atestasi mangrupikeun dokumén anu ditandatanganan (dina format anu ditangtukeun, biasana dumasar kana JSON) anu ngahubungkeun metadata sareng artefak. Éta ngagambarkeun bukti anu ngahubungkeun input (bahan) sareng output (artefak anu dihasilkeun) dina unggal léngkah pangwangunan.
Atestasi nyadiakeun catetan anu tiasa diverifikasi ngeunaan léngkah-léngkah anu dilakukeun pikeun ngawangun artefak perangkat lunak ahir, kalebet bahan input pikeun unggal léngkah sareng paréntah ngawangun anu dijalankeun.
Kasimpulanana, Atestasi Parangkat Lunak mangrupikeun mékanisme anu saé pikeun mariksa seueur aspék integritas anu béda tina prosés pangwangunan urang.
Tos réngsé maca séri ieu? Tong hariwang! Mangga luncat deui ka 'Diracun Pipeline Palaksanaan (APD)' atanapi postingan sanés anu narik minat anjeun deui!
Teraskeun diantos, urang bakal ngabahas langkung jero ngeunaan atestasi sareng build security dina tulisan blog salajengna.
