About this guide
This guide describes the highest impact changes you can make to improve the security of your build systems. Each section outlines a change you can make to your processes to improve security. The highest impact changes are listed first.
What's the risk?
Some attacks on software supply chains target the build system directly. If an attacker can modify the build process, they can exploit your system without the effort of compromising personal accounts or code. It's important to make sure that you don't forget to protect the build system as well as personal accounts and code.
Secure your build system
There are several security capabilities a build system should have:
-
The build steps should be clear and repeatable.
-
You should know exactly what was running during the build process.
-
Each build should start in a fresh environment, so a compromised build doesn't persist to affect future builds.
GitHub Actions can help you meet these capabilities. Build instructions are stored in your repository, alongside your code. You choose what environment your build runs on, including Windows, Mac, Linux, or runners you host yourself. Each build starts with a fresh runner image, making it difficult for an attack to persist in your build environment.
In addition to the security benefits, GitHub Actions lets you trigger builds manually, periodically, or on git events in your repository for frequent and fast builds.
GitHub Actions is a big topic, but a good place to get started is 了解 GitHub Actions, as well as GitHub Actions 的工作流语法, and 触发工作流程.
Generate artifact attestations for your builds
项目证明使你能够为自己构建的软件创建不可伪造的来源和完整性保证。 反过来，使用软件的人员可以验证软件是在哪里以及如何构建的。
使用软件生成项目证明时，将创建加密签名的声明用于确立生成的来源，并包含以下信息：
- 指向与项目关联的工作流的链接
- 项目的仓库、组织、环境、提交 SHA 以及触发事件
- OIDC 令牌中用于确立来源的其他信息。 有关详细信息，请参阅“OpenID Connect”。
还可以生成包含关联的软件物料清单 (SBOM) 的项目证明。 将你的版本与它们中使用的开放源代码依赖项列表相关联可提供透明度，并使使用者能够遵守数据保护标准。
Artifact attestations include a signature over a built artifact, along with links to the source code and build instructions. If you sign your build with artifact attestations, you do not have to manage your own signing key material. GitHub handles this for you with the signing authority we operate.
For more information, see 使用项目证明确立生成的来源.
Sign your builds
After your build process is secure, you want to prevent someone from tampering with the end result of your build process. A great way to do this is to sign your builds. When distributing software publicly, this is often done with a public/private cryptographic key pair. You use the private key to sign the build, and you publish your public key so users of your software can verify the signature on the build before they use it. If the bytes of the build are modified, the signature will not verify.
How exactly you sign your build will depend on what sort of code you're writing, and who your users are. Often it's difficult to know how to securely store the private key. One basic option here is to use GitHub Actions encrypted secrets, although you'll need to be careful to limit who has access to those GitHub Actions workflows. If your private key is stored in another system accessible over the public internet (like Microsoft Azure, or HashiCorp Vault), a more advanced option is to authenticate with OpenID Connect, so you don't have to share secrets across systems. If your private key is only accessible from a private network, another option is to use self-hosted runners for GitHub Actions.
For more information, see 在 GitHub Actions 中使用机密, OpenID Connect, and 自托管运行程序.
Use immutable releases
If you are using release assets from other projects in your build system, or creating releases for your own work, you should reduce security risk by ensuring those releases are immutable, meaning they cannot be changed after publication. Immutable releases help prevent supply chain attacks and accidental breaking changes. For more information, see 不可变版本.
Harden security for GitHub Actions
There are many further steps you can take to additionally secure GitHub Actions. In particular, be careful when evaluating third-party workflows, and consider using CODEOWNERS to limit who can make changes to your workflows.
For more information, see 安全使用参考 and 安全使用参考.