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 보안 사용 참조.