Acerca de esta guía
This guide describes the highest impact changes you can make to improve the security of your build systems. Cada sección detalla un cambio que puedes hacer a tus procesos para mejorar la seguridad. Los cambios de más alto impacto se listan primero.
¿Cuál es el riesgo?
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 virtual environment, 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.
Las GitHub Actions son un tema amplio, pero un buen lugar para iniciar es la sección de "Entender las GitHub Actions", así como "Elegir los ejecutores hospedados por GitHub" y "Activar un flujo de trabajo".
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. si solo se puede acceder a tu clave privada desde una red privada, otra opción es usar los corredores auto-hospedados para GitHub Actions.
Para obtener más información, consulta las secciones "Secretos cifrados" y "Acerca de los ejecutores auto-hospedados".
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.
Para obtener más información, consulta las secciones "Fortalecimiento de seguridad para las GitHub Actions"; particularmente "Utilizar acciones de terceros" y "Utilizar CODEOWNERS para monitorear cambios".