Een weekplan voor het verharden van GitHub Actions

Elke gebruiker met schrijftoegang tot een repository kan alle secrets lezen die daarin zijn geconfigureerd. De credentials die uw workflows gebruiken, moeten dus de minste rechten hebben die de taak toelaat. De secure use reference van GitHub zegt hetzelfde over de GITHUB_TOKEN: geef deze alleen de minimaal vereiste permissies. De vijf onderstaande taken kosten elk één dag.

De OWASP Top 10 CI/CD Security Risks benoemt de probleemgebieden die dit plan raakt: inadequaat identity- en accessmanagement (CICD-SEC-2), misbruik van de dependency chain (CICD-SEC-3), poisoned pipeline execution (CICD-SEC-4), onvoldoende credential hygiene (CICD-SEC-6) en onjuiste validatie van artifact-integriteit (CICD-SEC-9).

Maandag: beperk wat de token kan doen

Ga ervan uit dat iedereen die naar de repository kan pushen, de secrets kan lezen. Beperk vervolgens waar die credentials bij kunnen.

GitHub adviseert de standaardpermissie van de GITHUB_TOKEN voor repository-inhoud op alleen-lezen te zetten en die per job te verhogen waar dat nodig is. In een workflowbestand:

permissions:
  contents: read

jobs:
  release:
    permissions:
      contents: write

Loop elke workflow langs en vraag u af welke jobs daadwerkelijk iets schrijven. Geef alleen die jobs schrijftoegang en laat de rest op lezen staan.

Dinsdag: audit de actions die u gebruikt

Maak een lijst van alle actions die in uw workflows worden gebruikt, ook die welke worden aangeroepen vanuit reusable workflows die u zelf beheert. Lees van elke action de broncode, en die van de repository die haar uitvoert.

De richtlijnen van GitHub over het auditen van secrets zijn specifiek over waar u op moet letten. Controleer dat secrets niet naar onbedoelde hosts worden verstuurd en dat ze niet expliciet naar de logoutput worden geschreven.

Pas daarna least privilege toe op de credentials zelf. Omdat schrijftoegang tot de repository leestoegang tot de secrets betekent, mag elke credential die een workflow gebruikt alleen doen wat die workflow nodig heeft. Een deploytoken waarmee u het hele cloudaccount kunt beheren, voldoet daar niet aan.

Woensdag: script injection

Onbetrouwbare contextwaarden, zoals de titel van een pull request, vormen een probleem wanneer ze rechtstreeks in een inline script worden geplaatst. De reference van GitHub noemt twee manieren om dat te voorkomen.

De aanbevolen aanpak is een action die de contextwaarde als argument ontvangt, omdat de waarde dan nooit wordt gebruikt om een shellscript te genereren. Moet u een inline script behouden, zet de expressie dan in een tussenliggende omgevingsvariabele:

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

In het voorbeeld van GitHub faalt de controle bij een titel van a"; ls $GITHUB_WORKSPACE" en wordt het commando niet uitgevoerd. De waarde wordt in het geheugen opgeslagen en als variabele gebruikt, waardoor ze niet in wisselwerking staat met het genereren van het script. GitHub adviseert ook om shellvariabelen tussen dubbele aanhalingstekens te zetten om word splitting te voorkomen, wat algemene shellpraktijk is.

Zoek contextexpressies in uw workflows om kandidaten te vinden en lees elke treffer in het bijbehorende run:-blok:

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

Donderdag: secrets en beschermde environments

Plaats deployment-secrets in environments en eis reviewers. Een workflowjob heeft pas toegang tot environment-secrets nadat een reviewer heeft goedgekeurd.

GitHub is duidelijk dat automatische redactie niet gegarandeerd is, omdat een secretwaarde op verschillende manieren kan worden getransformeerd. Redactie berust grotendeels op het vinden van een exacte match en wordt door de runner uitgevoerd. Een secret wordt dus alleen geredacteerd als een job het heeft gebruikt en de runner er toegang toe had. Gebruik deze tabel als review:

Fouten kunnen op onvoorziene manieren in STDOUT en STDERR terechtkomen, dus lees de logs na het testen handmatig door. Als een niet-geredacteerd secret in een runlog terechtkomt, verwijder dan het log en roteer het secret. Verwijder secrets die niet meer nodig zijn en roteer de overige periodiek. Dat verkort de tijd dat een gecompromitteerde waarde geldig blijft.

Vrijdag: eigenaarschap van workflows en output

Dit onderdeel is ons eigen advies. De bovenstaande bronnen schrijven het niet voor en het wordt niet aan GitHub, OWASP of NIST toegeschreven.

Bepaal wie de workflows mag wijzigen waarmee uw software wordt gebouwd en uitgebracht, en leg dat vast. Gebruikt u CODEOWNERS op uw platform, dan is de map .github/workflows een verstandig pad om te dekken. Stel daarna vast welke workflow uw release-artifacts produceert, want daarop vertrouwen klanten of productiesystemen.

De bronnen komen bij artifacts maar een stuk van de weg. OWASP noemt onjuiste validatie van artifact-integriteit als CICD-SEC-9 en onvoldoende logging en zichtbaarheid als CICD-SEC-10. Het Secure Software Development Framework (SP 800-218) van NIST biedt een gemeenschappelijk vocabulaire waarmee kopers en leveranciers over veilige softwareontwikkeling kunnen spreken. Geen van deze bronnen geeft een receptuur voor ondertekening, dus laten wij die ook achterwege.

Bepaal tot slot wie het opmerkt wanneer workflowbestanden, secrets of environment-goedkeuringen wijzigen, en hoe diegene dat te weten komt.

Waar u kunt beginnen

1. Zet de standaardpermissie van de GITHUB_TOKEN voor repository-inhoud op alleen-lezen en voeg permissions-blokken toe aan de jobs die meer nodig hebben.
2. Maak een lijst van alle gebruikte actions, lees hun broncode en controleer dat ze geen secrets naar onverwachte hosts sturen of naar logs schrijven.
3. Zoek contextexpressies in run:-blokken en verplaats ze naar een tussenliggende omgevingsvariabele of naar een action.
4. Verplaats productiesecrets naar een environment met verplichte reviewers, splits gestructureerde secrets op in losse waarden, registreer afgeleide waarden en roteer alles wat in een log is verschenen.
5. Leg vast wie de workflows mag wijzigen die release-artifacts bouwen, en wie een melding krijgt wanneer ze wijzigen.

Wilt u een second opinion op uw pipelines, dan omvat ons werk op het gebied van veilige softwareontwikkeling ook de CI/CD-configuratie. Een penetratietest kan laten zien of een pull request bij uw secrets kan komen.