GitHub Actions vastzetten: een tag kan ongemerkt naar andere code wijzen

Zet een action in een GitHub Actions-workflow vast als uses: EIGENAAR/REPOSITORY@VOLLEDIGE_COMMIT_SHA. Controleer eerst of de commit uit de bedoelde bronrepository komt en beoordeel de code die je ermee gaat uitvoeren. De beveiligingsrichtlijn van GitHub beschrijft waarom een tag onvoldoende zekerheid geeft: iemand met toegang tot de actionrepository kan die tag verplaatsen of verwijderen.

Schakel na de omzetting in Settings → Actions → General de optie ‘Require actions to be pinned to a full-length commit SHA’ in. Daarmee wordt een action die nog via een gewone tag wordt aangeroepen tegengehouden. Neem herbruikbare workflows afzonderlijk mee: voor hun verwijzingen geldt deze eis niet op dezelfde manier.

Breng de verwijzingen in kaart

Zoek eerst alle ‘uses:’-regels, zodat je weet welke workflowbestanden moeten veranderen. Het commando rg -n 'uses:' .github --glob '*.yml' --glob '*.yaml' toont treffers in YAML-bestanden onder .github, waaronder workflows en eventuele lokale actiondefinities. Bekijk de context van iedere treffer; een zoekresultaat vertelt je nog niet of het om een externe action, een herbruikbare workflow of een lokale action gaat.

Noteer voor elke externe verwijzing de eigenaar, repository, huidige tag of branch en de functie van de aanroep. Een stap met uses: EIGENAAR/REPOSITORY@TAG verwijst naar een action. Een aanroep met een pad naar .github/workflows/ verwijst naar een herbruikbare workflow, terwijl een pad dat met ./ begint naar bestanden in de eigen repository verwijst. Bekijk ook gegenereerde workflowbestanden als die in je project worden gebruikt: een handmatige wijziging verdwijnt anders mogelijk bij de volgende generatie.

Kies een commit die je kunt verantwoorden

Open de oorspronkelijke repository van de action en bepaal welke release je wilt gebruiken. Vergelijk de release-informatie met de versie die nu in de workflow staat en controleer de gewijzigde bestanden. Neem geen hash over uit een willekeurige andere workflow of fork: het gaat erom dat de gekozen commit daadwerkelijk bij de bedoelde actionrepository hoort.

Wie de repository lokaal ophaalt, kan de tag met git clone https://github.com/EIGENAAR/REPOSITORY.git en daarna git -C REPOSITORY rev-parse 'TAG^{commit}' naar de onderliggende commit herleiden. Vervang de hoofdletters door de werkelijke namen en tag. De toevoeging ^{commit} levert ook bij een geannoteerde tag de commit op in plaats van het tagobject. Vergelijk de volledige uitvoer met de commit in de oorspronkelijke repository; met git -C REPOSITORY show --stat VOLLEDIGE_COMMIT_SHA zie je welke bestanden bij die commit zijn gewijzigd.

Lees vervolgens de code die de action uitvoert. Let op scripts die extra code ophalen, op de verwerking van repository-inhoud en op toegang tot geheimen of het GITHUB_TOKEN. Een volledige SHA houdt de verwijzing bij een specifieke commit, maar zegt op zichzelf niets over de betrouwbaarheid van die commit of de code die zij tijdens een run elders ophaalt.

Vervang na de beoordeling alleen de verwijzing achter het apenstaartje door de volledige hash van de gecontroleerde commit. Bewaar de bijbehorende releasetag eventueel als commentaar voor de volgende beoordelaar; de uitvoerbare ‘uses:’-verwijzing blijft de SHA. Pas dezelfde werkwijze toe op elke externe action uit de inventarisatie, ook wanneer de eigenaar bekend is of de action door GitHub wordt aangeboden.

Dwing de repositoryregel af

Open de repositoryinstellingen, kies Actions → General, schakel onder ‘Actions permissions’ de pinoptie in en sla de wijziging op. De GitHub-instellingen voor repositories specificeren dat de regel ook geldt voor actions uit de eigen organisatie en voor actions van GitHub, terwijl herbruikbare workflows nog via een tag kunnen worden aangeroepen. Zet bestaande actionverwijzingen daarom om voordat je de instelling activeert en controleer daarna een workflowrun.

Voor een externe herbruikbare workflow kun je zelf een vaste verwijzing gebruiken in de vorm EIGENAAR/REPOSITORY/.github/workflows/BESTAND.yml@VOLLEDIGE_COMMIT_SHA. Beoordeel ook daar de gekozen commit en latere wijzigingen. Als een organisatie- of ondernemingsbeleid de repositoryinstelling beheert, moet de beheerder dat beleid aanpassen; een ontbrekende wijzigmogelijkheid in de repository is dan geen reden om de workflowverwijzingen ongemoeid te laten.

Er is een relevante uitzondering bij workflows met een dependency-lockfile: het beleid controleert voor afgedekte afhankelijkheden de daarin vastgelegde commit. Een tag kan dan in het workflowbestand blijven staan, terwijl de lockfile bepaalt welke code wordt uitgevoerd. Actions die niet door zo’n lockfile zijn afgedekt, hebben voor deze repositoryregel nog steeds een volledige SHA in de verwijzing nodig.

Laat updates als wijziging beoordelen

Een vastgezette commit beweegt niet automatisch mee met een nieuwe release. Configureer daarom Dependabot-versie-updates voor GitHub Actions. De Dependabot-instructie van GitHub gebruikt hiervoor .github/dependabot.yml met version: 2 en onder updates de waarden package-ecosystem: "github-actions", directory: "/" en een schedule.interval, bijvoorbeeld "weekly". Dependabot kan dan pull requests voor verouderde actionverwijzingen openen.

Behandel zo’n pull request als een voorstel om andere code uit te voeren. Vergelijk de oude en nieuwe commit, lees de relevante wijzigingen en release-informatie, en laat de betrokken workflows draaien voordat je de wijziging goedkeurt. De releasetag in een commentaar helpt bij de oriëntatie, maar blijft buiten de uitvoerbare verwijzing. Zo is een nieuwe actionversie een zichtbare, beoordeelbare wijziging in de repositorygeschiedenis.

Lees ook:

• GitHub Actions naar Azure: OIDC vervangt het langdurige deploygeheim
• Een SBOM maken in GitHub Actions: scan na de installatiestap
• Een AI-agent beveiligen: promptfilters alleen houden aanvallers niet tegen