Sécurisation des builds logiciels

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. 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. 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. Artifact attestations enable you to create unfalsifiable provenance and integrity guarantees for the software you build. In turn, people who consume your software can verify where and how your software was built. When you generate artifact attestations with your software, you create cryptographically signed claims that establish your build's provenance and include the following information: A link to the workflow associated with the artifact The repository, organization, environment, commit SHA, and triggering event for the artifact Other information from the OIDC token used to establish provenance.

You can also generate artifact attestations that include an associated software bill of materials (SBOM). Associating your builds with a list of the open source dependencies used in them provides transparency and enables consumers to comply with data protection standards. 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. 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.

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. Harden security for GitHub Actions There are many further steps you can take to additionally secure GitHub Actions. Les travaux de recherche présentés dans l’article dont le titre peut être traduit par « La gestion fonctionnelle des paquets permet-elle des constructions reproductibles à grande échelle ? Oui. » permettent de mieux comprendre et d’améliorer la sécurité des logiciels. lorsqu’un logiciel est installé, il est important de savoir qu’il n’a pas été modifié ou corrompu. Pour ça, il existe une méthode appelée « Reproducible Builds » (constructions reproductibles), qui permet de reconstruire exactement le même logiciel à partir du code, peu importe qui le fait ou quand.

Nos chercheurs ont voulu savoir si cette méthode pouvait passer à l’échelle, même quand on l’applique à des centaines de milliers de logiciels. Ils ont donc testé plus de 700 000 programmes dans un système appelé Nix (gestionnaire de paquets fonctionnel) entre 2017 et 2023. Leur expérience a montré que, dans la plupart des cas, les logiciels étaient bien identiques à chaque reconstruction.