När jag arbetar med CI/CD-säkerhet försöker jag börja i den faktiska tillgången, datan och förändringen som ska skyddas. CI/CD-pipelinen har ofta rätt att läsa källkod, hämta secrets och deploya produktion och bör därför behandlas som en privilegierad produktionskomponent.
CI/CD-säkerhet i praktiken
Första byggstenen: Branch protection minskar risken att en ensam commit når release. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: OIDC workload identity kan ersätta långlivade cloud keys. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Tredjepartsactions eller plugins är supply-chain-kod. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Separata environments kan kräva olika approval och credentials. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Från nuläge till verifierad kontroll
- Kartlägg vilka pipelines som kan deploya var.
- Minska token permissions per jobb.
- Pinna externa actions till känd version eller digest där plattformen stödjer det.
- Använd kortlivad federation mot cloud.
- Kräv review för produktionsenvironment.
För CI/CD-säkerhet håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Exempel från ett driftperspektiv
Ett särskilt viktigt test är en forkad pull request. Den ska kunna bygga och testas utan att få samma hemligheter som en betrodd releasebranch.
Fallgropar jag försöker undvika
- Att ge pipeline-token write-all eftersom det är enklare.
- Att köra okänd pull-request-kod med tillgång till produktionssecrets.
- Att återanvända samma cloud credential i dev och prod.
Kontrollpunkter
För CI/CD-säkerhet vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Pull request från extern källa kan inte läsa produktionshemlighet.
- Jobbet får endast de API-rättigheter det behöver.
- Deployment kan kopplas till granskad commit och körning.
Ett negativt test hör också till CI/CD-säkerhet: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
CI/CD-säkerhet – behandla pipeline som produktionsinfrastruktur handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.