Skip to main content

Securing a CI/CD process

System accounts and environments used as part of the CI/CD process will often have access to a wide range of resources such as source code, secrets, and infrastructure. This, combined with a lack of understanding how the process works makes CI/CD an attractive target for attackers.

Secrets​

Secrets (passwords, tokens, ssh-keys etc.) are often required for the process to work as intended. As these are used to access resources it is important that these do not become available to unauthorized persons, and that they are treated with care:

  • Use the CI/CD system best practices for adding and using secrets.
    • Don't create your own custom solutions for handling secrets, such as reading files, environment variables and so on. Doing so may have unforeseen consequences.
  • All secrets should have a limited lifespan, and a process needs to be in place to replace it before expiry or if it is compromised.
  • Avoid machine accounts and shared accounts.
  • Check that secrets aren't logged, also in the case of failures in the process.
  • Only consume secrets in the CI/CD steps where it is explicitly required.

Configuration​

The CI/CD solution is a critical part of the system as a whole, so it is important to be able to recreate pipelines and tasks quickly. Any configuration of the CI/CD system and process should be treated as source code and kept under version control.

Runtime environment​

If the CI/CD environment should be compromised, the consequences can be severe. The source code build as part of this process can be modified, secrets collected and exfiltrated, and it can be used as a tool allowing an attacker access to additional resources. Securing virtual machines and containers are covered by separate articles.

Some general suggestions to help increase the security of the CI/CD process:

  • Avoid self-hosted build environments.
  • Avoid Jenkins if possible, if used pay close attention to updates and which plugins you use.
  • Use Github Actions, but be aware of
    • External actions. Should be avoided, or treat it as any other library. Can also be locked to a specific commit hash.
    • Don't allow pull requests from forks to run in self hosted runners
    • Consider using environment secrets for each branch and remember that anyone running code has access to all exposed secrets.
    • Consider using federated identity credential (Azure + Github)
OWASP CI/CD Top 10

If you need more information on securing the CI/CD process, the OWASP CI/CD Top 10 can be a good starting point. ⭐