In the fascinating and complex world of software development, each component is a piece of an invisible machine, seemingly made of magic words. This process begins with the source code, which is nothing more than text files hosted in a repository. Subsequently, this code is transformed through a unique process into what is known as a “software artifact”. These artifacts can be a minimized JavaScript file, a container image packed with business logic, or a binary compiled for a specific processor architecture.
Once created, these artifacts can spend a long period of time inactive in package registries or containers, such as npm, RubyGems, PyPI, MavenCentral, GitHub Packages, Azure Container Registry, AWS ECR, among others. They can be stored as binaries attached to GitHub Releases or simply as a ZIP file in blob storage, waiting to be used.
The real challenge arises when it is time to use these artifacts. Someone must unpack the package, run the code, launch the container, install the driver, or update the firmware. This process, which can involve many hours of human work and considerable costs, also carries substantial risk, given that our modern world deeply depends on software.
One of the main security concerns today is ensuring that the artifact being executed is exactly the one that was originally built. Details of the artifact’s journey are often lost or become blurred, making it difficult to connect the final artifact with the source code and original build instructions. This lack of visibility is one of the main causes of many security challenges.
Throughout the software development life cycle (SDLC), there are opportunities to ensure the security of the code flow that turns into artifacts, reducing the risk of malicious actors compromising the final software. However, some cybersecurity challenges may seem almost impossible to solve, although that is not the current case.
Take a simple example: if you want to ensure that a file in your personal directory is exactly the same today and tomorrow, you can generate a digest of the file using a secure hash algorithm. Using OpenSSL and the SHA-256 algorithm, you can create a unique fingerprint for that file. If anything changes in the file, the fingerprint will also change.
But what happens when we want to secure an artifact? At this point, we need a software artifact signature. The process involves taking the digest string, passing it through a cryptographic algorithm, and producing a string that represents the “signature” of that fingerprint with a unique key. For others to confirm your signature, asymmetric encryption must be used: sign the digest with your private key and provide the corresponding public key.
Asymmetric encryption is the foundation of almost all trust on the Internet. From secure interactions with banks to the secure delivery of content on GitHub, asymmetric encryption powers technologies like TLS and SSH, creating a foundation of trust through signatures.
Major operating systems such as Windows, macOS, iOS, and Android require the presence of a signature to ensure a trusted origin for software artifacts. Building these systems is incredibly difficult and important for the modern software world.
While a signature is a good start in providing reliable information about a software artifact, to significantly improve SDLC security, we need to go beyond signatures and think in terms of attestations. An attestation is a verifiable statement about an artifact, created by an authenticated entity.
The main type of attestation is about the origin and creation of the artifact, affirming the facts and build instructions that led to that artifact. This is called a provenance attestation, and its specification comes from the SLSA project, which provides a common framework for reasoning about software supply chain security.
GitHub, as the largest global software development platform, has been involved in thinking and developing solutions to ensure SDLC security, including issuing certificates, securing those certificates, enabling secure artifact signing, and reliably verifying those signatures.
This is where Sigstore comes in, an open-source project that provides an X.509 certificate authority and a timestamp authority. Sigstore simplifies and makes software signatures accessible, similar to how Let’s Encrypt simplifies TLS certificates. GitHub helps oversee the governance of the Sigstore project and actively participates in its operations and development.
With Sigstore, it is possible to create an audit trail that links artifacts to CI, ensuring that software consumers can trust the origin of the code they run. GitHub is excited to share more about these solutions in the near future.
Harness the power of GitHub Advanced Security and stay tuned for future updates to better protect your software projects.
Source: MiMub in Spanish
