En av de mest kritiska attackytorna i modern mjukvaruutveckling är inte produktionsmiljön. Det är vägen dit. CI/CD-pipelinen som bygger, testar och levererar koden har blivit ett av angriparnas mest attraktiva mål.

Varför pipelinen är ett så attraktivt mål

Om en angripare får kontroll över build-processen blir konsekvenserna svåra att överblicka: en manipulerad build, officiella uppdateringar med bakdörrar och skadlig kod signerad med organisationens egna certifikat. Tusentals eller miljontals användare komprometteras automatiskt, via en helt legitim uppdateringskanal som de litar på.

Angriparen behöver inte längre attackera varje användare. Den attackerar utvecklingskedjan en gång och låter er egen distribution göra resten.

Vanliga attackvägar

  • Stulna CI-secrets. Tokens för GitHub Actions eller GitLab CI som läcker via loggar, forkade repon eller komprometterade utvecklarkonton.
  • Överprivilegierade pipelines. Ett byggjobb som har åtkomst till långt mer än det behöver blir en genväg till hela miljön.
  • Manipulerade build-steg. En liten ändring i en pipelinedefinition eller ett byggskript passerar lätt obemärkt i en stor kodbas.
  • Kodinjektion vid build eller paketering. Skadlig kod läggs till efter kodgranskningen men före leverans, där få tittar.
  • Komprometterade runners och build-servrar. Maskinen som bygger koden är ofta sämre skyddad än produktionsservrarna, trots att den har nycklarna till dem.
  • Manipulerad signeringsprocess. Kan angriparen signera med era nycklar är skadlig kod inte längre skiljbar från äkta.

Det har redan hänt, flera gånger

SolarWinds (2020): en bakdörr injicerades i build-processen för Orion-plattformen och distribuerades som officiell uppdatering till tusentals organisationer, däribland amerikanska myndigheter.

Codecov (2021): angripare modifierade verktygets Bash Uploader-skript och kunde under flera månader samla in secrets ur kunders CI-miljöer.

3CX (2023): företagets desktop-applikation komprometterades via byggkedjan och levererades signerad till kunderna, i sin tur sprunget ur en annan komprometterad leverantör.

CircleCI (2023): stulna sessioner ledde till att kunder världen över tvingades rotera alla secrets som någonsin lagrats i plattformen.

En pipeline med åtkomst till produktion är produktionsmiljö. Skydda den därefter.

Så minskar ni risken

  • Isolera CI-miljöerna. Byggmiljön ska vara separerad från både utvecklarnas vardagsmiljö och produktion.
  • Minimera privilegier. Varje pipeline får bara den åtkomst den behöver, inget mer.
  • Rotera secrets. Korta livslängder och engångs-tokens i stället för statiska nycklar som lever i åratal.
  • Övervaka pipeline-ändringar. Ändringar i byggskript och pipelinedefinitioner ska granskas och larmas på, precis som kodändringar.
  • Separera signering från build. Signeringsnycklarna ska inte finnas på samma system som bygger koden.
  • Verifiera artefakter. Checksummor och attestering genom hela kedjan, så att det som levereras bevisligen är det som byggdes.

Inte längre teoretiskt

Supply chain-attacker är inte längre teoretiska. De är en av de största riskerna i modern mjukvarusäkerhet, och NIS2 gör dessutom leverantörskedjan till ett uttryckligt ansvar. Vi testar gärna er utvecklingskedja på samma sätt som en angripare skulle, från utvecklarkonto till färdig artefakt. Läs också vår artikel om utvecklarsäkerhet 2026, som handlar om människorna bakom kedjan.

One of the most critical attack surfaces in modern software development is not the production environment. It is the road there. The CI/CD pipeline that builds, tests and ships your code has become one of the most attractive targets for attackers.

Why the pipeline is such an attractive target

If an attacker gains control of the build process, the consequences are hard to contain: a manipulated build, official updates carrying backdoors, and malicious code signed with the organisation's own certificates. Thousands or millions of users are compromised automatically, through a fully legitimate update channel they trust.

The attacker no longer needs to attack every user. They attack the development chain once and let your own distribution do the rest.

Common attack paths

  • Stolen CI secrets. GitHub Actions or GitLab CI tokens leaking through logs, forked repositories or compromised developer accounts.
  • Over-privileged pipelines. A build job with access to far more than it needs becomes a shortcut into the entire environment.
  • Manipulated build steps. A small change in a pipeline definition or build script easily goes unnoticed in a large codebase.
  • Code injection at build or packaging. Malicious code is added after code review but before delivery, where few people look.
  • Compromised runners and build servers. The machine that builds the code is often less protected than the production servers, despite holding the keys to them.
  • A manipulated signing process. If the attacker can sign with your keys, malicious code is no longer distinguishable from genuine.

It has already happened, several times

SolarWinds (2020): a backdoor was injected into the build process of the Orion platform and distributed as an official update to thousands of organisations, including US government agencies.

Codecov (2021): attackers modified the tool's Bash Uploader script and were able to harvest secrets from customers' CI environments for months.

3CX (2023): the company's desktop application was compromised through the build chain and delivered signed to customers, itself originating from another compromised supplier.

CircleCI (2023): stolen sessions forced customers worldwide to rotate every secret ever stored in the platform.

A pipeline with access to production is a production environment. Protect it accordingly.

How to reduce the risk

  • Isolate CI environments. The build environment should be separated from both developers' everyday environment and production.
  • Minimise privileges. Each pipeline gets only the access it needs, nothing more.
  • Rotate secrets. Short lifetimes and one-time tokens instead of static keys that live for years.
  • Monitor pipeline changes. Changes to build scripts and pipeline definitions should be reviewed and alerted on, just like code changes.
  • Separate signing from build. Signing keys should not live on the same system that builds the code.
  • Verify artifacts. Checksums and attestation through the whole chain, so that what ships is provably what was built.

No longer theoretical

Supply chain attacks are no longer theoretical. They are one of the biggest risks in modern software security, and NIS2 also makes the supply chain an explicit responsibility. We are happy to test your development chain the way an attacker would, from developer account to finished artifact. Also read our article on developer security in 2026, about the people behind the chain.