In the ever-evolving realm of software development, dependency libraries stand out as pivotal elements. These dependencies are designed with a focus on efficiency, reusability, and seamless ecosystem integration. However, they don’t come without their challenges. Concerns about maintainability and the potential risks associated with inadequate governance, particularly regarding security vulnerabilities, underscore their importance.
For software developers seeking to deliver their creations as binaries to end consumers, a vulnerable aspect emerges: binary distribution. The looming question arises — what if an unauthorized entity injects malicious code, jeopardizing the integrity of the application? Addressing these apprehensions, Sigstore, a project housed under the Open Source Security Foundation (OpenSSF), steps in. This blog article delves into the intricacies of how various components within the Sigstore project collaboratively address and overcome these challenges, ensuring a robust and secure software development environment.
Secure your development environment and the ground before asking the user of your software to secure their environment.
Fulcio: The first component that we discuss from Sigstore is Fulcio. The simple definition of Fulcio is that it is a service that verifies the identity, generates a short lived certificate associated with the signing key, the signing key would then be valid for a shorter duration. The developer’s identity is verified using one of the known IAM solutions. There is also OpenID Connect interface to verify the identity.
Goal is to avoid the need to store and secure the signing key.
Cosign: The tool that facilitates the signing process. Be it a build artifact, a binary or just a blob, the cosign tool has support for all. Use this to generate a signature, also comes integrated so that it can connect to Fulcio instance of your choice. The signature and the publicly verifiable information is uploaded to an immutable record keeper, called rekor. More information on that will be discussed in the next section.
Generate the necessary signature on the generated artifact, distribute the signature and the verification information, along with the binary.
Rekor: The place where signatures along with their verification information is stored. It is an immutable record, so that once written the records can be used to verify any number of times. The public information such as the certificate associated with the signing key, identity which generated the signature are some of the critical parameters one can fetch from this store.
Leaves no chance for an attacker to fake a binary, developer or the release engineer has full access to what is produced as a build.
Policy Controller: The signing process is only as strong as the verification process. The generated signature shall be verified for its authenticity. The users of the build artifacts are expected to verify if they are pulling in the right build. Policy Controller is one of the components available for an end user to verify if their binary is valid, the validity check is embed within the Kubernetes’ container image pull mechanism. It just makes the whole process of verification much easier to adopt.
Don’t just believe the documentation, implement verification mechanism to be very sure.
Overall, these tools should suffice for the complete lifecycle of build artifact management. I will add more details and the commands in next blog post, with a sample project using the Sigstore model.