Trusty provides a free-to-use service with scoring and metrics about a package’s repo and author activity.
Minder is an open source platform that helps project owners build more secure software and prove that what they’ve built is secure.
Provenance in the software supply chain is a critical concept, particularly in an era where malicious attacks on open source projects are increasing—and are ever more sophisticated. Here's an overview of what provenance is, what supply chain attacks it can help guard against, and how to establish it.
Provenance in the software supply chain is a critical concept, particularly in an era where malicious attacks on open source projects are increasing—and are ever more sophisticated. Here’s what you need to know about what software provenance is, and how it can help.
At its core, “provenance” refers to the origin or source of something. In the context of software, it means understanding where code comes from, who wrote it, who built it, and how it has been altered over time. This understanding is essential for maintaining the integrity and security of software systems.
In the realm of software supply chains, provenance plays a pivotal role in safeguarding against various types of attacks. One primary threat is the insertion of malicious code or dependencies into open-source libraries or packages. Attackers often target these resources due to their wide usage and inherent trust within the developer community. By ensuring provenance, organizations can trace the lineage of each component in their software, allowing them to verify its authenticity and integrity. This is the sole reason why I originally started the sigstore project back in 2020.
Sigstore is a project within the Linux Foundation that has emerged as a powerful tool in the pursuit of decent and credible software provenance. Sigstore provides a transparent, easy-to-use solution for signing, verifying, and protecting software. It utilizes cryptographic signatures to establish a verifiable chain of custody for software artifacts. This approach ensures that the software has not been tampered with, from its point of creation to its final deployment.
The level of cryptographic provenance brought to the table via sigstore allows protections and mitigations against multiple supply chain attacks.
Additionally, SLSA—Supply-chain Levels for Software Artifacts—is an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. It’s used as a model by open source ecosystems and organizations for how to establish provenance for software projects, and prevent software supply chain attacks.
Integrating sigstore with frameworks like SLSA enhances the robustness of security measures. SLSA's framework includes practices like hermetic builds and source integrity, so it complements sigstore's signing capabilities, creating a comprehensive solution for software provenance. Both sigstore and SLSA have seen decent in-roads lately into CI/CD pipelines, ensuring each step of the software's journey from development to deployment is secured and verified.
Using Sigstore and SLSA to establish provenance for open source software projects can help guard against the following types of attacks:
Supply Chain Poisoning: This occurs when attackers inject malicious code into a software component that is widely used across different applications. For instance, if a widely used open-source library in the npm ecosystem is compromised, it could affect thousands of downstream applications. Provenance ensures that every change to the code is tracked and verified, helping to detect such malicious insertions.
Man-in-the-Middle (MitM) Attacks: In this scenario, an attacker intercepts and potentially alters the communication between two parties. In the context of software development, this could mean altering the code or dependencies as they are being downloaded or updated. Sigstore’s cryptographic signatures over the integrity structure of a package or file ensure that the software or an update is authentic, and has not been tampered with during transmission.
Unauthorized Code Modification: This attack involves unauthorized alterations to the codebase, potentially by an insider or through compromised developer credentials. Provenance tracking via SLSA and Sigstore's signing mechanism ensure that any changes to the code are authorized and can be traced back to a known, trusted source.
Dependency Confusion or Substitution Attacks: Attackers could exploit a software's dependencies by creating malicious packages with the same names as legitimate ones but hosted in different repositories. Developers might unknowingly download these malicious packages. Provenance and cryptographic signing can prevent this by verifying the origin and integrity of each package.
Replay Attacks: In these attacks, a valid data transmission is maliciously repeated or delayed. This can be a threat in software updates or code transmissions. Signed and timestamped code, as facilitated by tools like Sigstore, helps in ensuring that the code being used is the latest and legitimately intended version.
Software Tampering During CI/CD Pipelines: Continuous Integration and Continuous Deployment (CI/CD) pipelines are critical in modern software development. However, they can be vulnerable to attacks where the code is tampered with before deployment.
Backdoor Insertion: This involves the inclusion of harmful code within a legitimate software update or package. Such backdoors are often hard to detect. Provenance ensures that each update or new package is properly reviewed and signed by trusted developers, minimizing the risk of backdoor attacks.
Compromised Build Processes: If an attacker gains control of the build process, they can introduce vulnerabilities or malicious code. Provenance tracking, especially when combined with the principles of SLSA, ensures that the build environment and process are secure and have not been altered.
Moreover, the use of GitHub Actions with sigstore further streamlines the process of signing and verifying code. GitHub Actions, an automation platform, can be configured to automatically sign code using sigstore during the development pipeline—for example, developers can use the “Docker Publish” GitHub Actions workflow to sign their container images by default. Integrations like this not only ensure the security of your code, but also add efficiency and reliability to the development process.
For developers, these resources can help you learn more about sigstore, SLSA, and publishing your packages with provenance:
How sigstore works: A breakdown of sigstore and its components
SLSA Build levels: Standards for establishing provenance for software projects
GitHub Actions’ “Docker Publish” workflow: Provides an automated container image signing workflow
GitHub Actions starter workflow for automating container image signing with sigstore
npm documentation for how to publish packages with provenance, using GitHub Actions or GitLab CI/CD
Finally, if you want to know whether an open source package has been signed and built with sigstore—so that you can trust that truly it is what it says it is—you can use Trusty, a free service from Stacklok.
Trusty displays sigstore provenance information for npm packages (currently, the only ecosystem that supports publishing packages with provenance).
Provenance in the software supply chain is not just a best practice, but an absolute necessity in today’s digital landscape. Tools like sigstore, coupled with frameworks like SLSA, provide robust solutions for ensuring the integrity and security of software. By adopting these practices, organizations can protect themselves against a range of cyber threats, ensuring the safety and reliability of their software products.
Here at Stacklok, we’re continuing to work with developer communities to support adoption of sigstore, and to provide better signal into proof of origin for packages that haven’t yet been signed. Join our Discord for the latest updates about provenance information in Trusty!