GitHub Actionsi tugevdamise plaan arendustiimidele ühe nädalaga

Igaüks, kellel on repositooriumile kirjutusõigus, saab lugeda kõiki selles seadistatud saladusi (secrets). Seepärast peaksid teie töövoogude kasutatavad volitused omama vähimaid õigusi, mida ülesanne võimaldab. GitHubi turvalise kasutamise juhend ütleb sama GITHUB_TOKEN-i kohta: andke sellele vaid minimaalsed vajalikud õigused. Allolevad viis ülesannet võtavad igaüks ühe päeva.

OWASPi CI/CD turvariskide Top 10 nimetab probleemivaldkonnad, mida see plaan puudutab: ebapiisav identiteedi- ja ligipääsuhaldus (CICD-SEC-2), sõltuvusahela kuritarvitamine (CICD-SEC-3), mürgitatud pipeline'i täitmine (CICD-SEC-4), ebapiisav volituste hügieen (CICD-SEC-6) ja artefaktide terviklikkuse puudulik kontroll (CICD-SEC-9).

Esmaspäev: vähendage tokeni võimalusi

Lähtuge eeldusest, et igaüks, kes saab repositooriumisse push'ida, näeb selle saladusi. Seejärel kitsendage, milleni need volitused ulatuvad.

GitHub soovitab määrata GITHUB_TOKEN-i vaikeõiguseks repositooriumi sisu puhul ainult lugemise ning tõsta seda vajaduse korral üksikute jobide jaoks. Töövoo failis:

permissions:
  contents: read

jobs:
  release:
    permissions:
      contents: write

Käige läbi iga töövoog ja küsige, millised jobid tegelikult midagi kirjutavad. Andke kirjutusõigus ainult neile ja jätke ülejäänud lugemisõiguse peale.

Teisipäev: auditeerige kasutatavaid actioneid

Tehke nimekiri kõigist teie töövoogudes kasutatavatest actionitest, sealhulgas nendest, mida kutsuvad teie hallatavad taaskasutatavad töövood (reusable workflows). Lugege iga action'i lähtekoodi ning ka selle repositooriumi koodi, mis seda käivitab.

GitHubi juhend saladuste auditeerimise kohta on täpne selles, mida otsida. Kontrollige, et saladusi ei saadeta soovimatutele hostidele ja et neid ei prindita selgesõnaliselt logiväljundisse.

Seejärel rakendage vähima õiguse põhimõtet volitustele endile. Kuna repositooriumi kirjutusõigus tähendab ka selle saladuste lugemisõigust, peaks iga töövoo kasutatav volitus suutma teha ainult seda, mida see töövoog vajab. Deploy-token, millega saab hallata kogu pilvekontot, seda testi ei läbi.

Kolmapäev: skriptisüstid

Mitteusaldusväärsed kontekstiväärtused, näiteks pull request'i pealkiri, muutuvad probleemiks, kui need paigutada otse inline-skripti. GitHubi juhend pakub selle vältimiseks kaks viisi.

Soovitatav lähenemine on action, mis võtab kontekstiväärtuse argumendina, sest siis ei kasutata väärtust kunagi shelliskripti genereerimiseks. Kui peate inline-skripti alles hoidma, määrake avaldis vahepealseks keskkonnamuutujaks:

- name: Check PR title
  env:
    TITLE: ${{ github.event.pull_request.title }}
  run: |
    if [[ "$TITLE" =~ ^octocat ]]; then exit 0; else exit 1; fi

GitHubi näites ei läbi pealkiri a"; ls $GITHUB_WORKSPACE" kontrolli ja käsku ei täideta. Väärtus salvestatakse mällu ning seda kasutatakse muutujana, mistõttu see ei puutu skripti genereerimisega kokku. GitHub soovitab ka shelli muutujaid topeltlgiltides ümbritseda, et vältida sõnadeks jagamist, mis on üldine shelli tava.

Kandidaatide leidmiseks otsige oma töövoogudest kontekstiavaldisi ja lugege iga leid läbi selle run: plokis:

grep -rn 'github.event' .github/workflows

Neljapäev: saladused ja kaitstud keskkonnad

Paigutage deploy-saladused keskkondadesse (environments) ja nõudke ülevaatajaid. Töövoo job ei pääse keskkonna saladustele ligi enne, kui ülevaataja selle heaks kiidab.

GitHub ütleb selgelt, et automaatset maskeerimist ei saa garanteerida, sest saladuse väärtust saab mitmel viisil teisendada. Maskeerimine tugineb suuresti täpse vaste leidmisele ja selle teeb runner, mistõttu maskeeritakse saladus ainult siis, kui job seda kasutas ja runner sai sellele ligi. Kasutage ülevaatuseks järgmist tabelit:

Vead võivad jõuda STDOUT-i ja STDERR-i viisidel, mida te ette ei planeerinud, seega lugege logisid pärast testimist käsitsi. Kui maskeerimata saladus jõuab käivituse logisse, kustutage logi ja roteerige saladus. Eemaldage saladused, mida enam ei vajata, ning roteerige ülejäänuid perioodiliselt, mis lühendab aega, mille jooksul kompromiteeritud väärtus kehtib.

Reede: töövoogude ja väljundi omanikud

See jaotis on meie enda nõuanne. Ülaltoodud allikad seda ei ette kirjuta ning seda ei omistata GitHubile, OWASPile ega NISTile.

Otsustage, kes tohib muuta töövooge, mis teie tarkvara ehitavad ja välja laskavad, ning kirjutage see üles. Kui kasutate oma platvormil CODEOWNERS-it, on kataloog .github/workflows mõistlik kaetav tee. Seejärel tehke kindlaks, milline töövoog toodab teie release-artefakte, sest just neid usaldavad kliendid või toodangusüsteemid.

Artefaktide osas jõuavad allikad vaid osaliselt kaugele. OWASP loetleb artefaktide terviklikkuse puuduliku kontrolli kui CICD-SEC-9 ning ebapiisava logimise ja nähtavuse kui CICD-SEC-10. NISTi Secure Software Development Framework (SP 800-218) pakub ühist sõnavara, mida ostjad ja tarnijad saavad turvalise arenduse arutamiseks kasutada. Ükski neist ei anna allkirjastamise retsepti, seega jätame selle välja.

Lõpuks otsustage, kes märkab, kui töövoo failid, saladused või keskkonna kinnitused muutuvad, ja kuidas see temani jõuab.

Kust alustada

1. Määrake GITHUB_TOKEN-i vaikeõiguseks repositooriumi sisu puhul ainult lugemine ning lisage permissions plokid jobidele, mis vajavad rohkem.
2. Tehke nimekiri kõigist kasutatavatest actionitest, lugege nende lähtekood läbi ja kontrollige, et need ei saada saladusi ootamatutele hostidele ega prindi neid logidesse.
3. Otsige run: plokkidest kontekstiavaldisi ja viige need vahepealsesse keskkonnamuutujasse või action'isse.
4. Viige toodangu saladused keskkonda, kus on kohustuslikud ülevaatajad, jagage struktureeritud saladused üksikuteks väärtusteks, registreerige tuletatud väärtused ja roteerige kõik, mis on logis ilmunud.
5. Kirjutage üles, kes tohib muuta release-artefakte ehitavaid töövooge ja keda nende muutumisest teavitatakse.

Kui soovite oma pipeline'ide kohta teist arvamust, hõlmab meie turvalise tarkvaraarenduse teenus ka CI/CD seadistust. Penetratsioonitest näitab, kas pull request pääseb teie saladustele ligi.