What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2022-04-07 11:33:30 | Improving software supply chain security with tamper-proof builds (lien direct) | Posted by Asra Ali and Laurent Simon, Google Open Source Security Team (GOSST)Many of the recent high-profile software attacks that have alarmed open-source users globally were consequences of supply chain integrity vulnerabilities: attackers gained control of a build server to use malicious source files, inject malicious artifacts into a compromised build platform, and bypass trusted builders to upload malicious artifacts. Each of these attacks could have been prevented if there were a way to detect that the delivered artifacts diverged from the expected origin of the software. But until now, generating verifiable information that described where, when, and how software artifacts were produced (information known as provenance) was difficult. This information allows users to trace artifacts verifiably back to the source and develop risk-based policies around what they consume. Currently, provenance generation is not widely supported, and solutions that do exist may require migrating build processes to services like Tekton Chains.This blog post describes a new method of generating non-forgeable provenance using GitHub Actions workflows for isolation and Sigstore's signing tools for authenticity. Using this approach, projects building on GitHub runners can achieve SLSA 3 (the third of four progressive SLSA “levels”), which affirms to consumers that your artifacts are authentic and trustworthy. ProvenanceSLSA ("Supply-chain Levels for Software Artifacts”) is a framework to help improve the integrity of your project throughout its development cycle, allowing consumers to trace the final piece of software you release all the way back to the source. Achieving a high SLSA level helps to improve the trust that your artifacts are what you say they are.This blog post focuses on build provenance, which gives users important information about the build: who performed the release process? Was the build artifact protected against malicious tampering? Source provenance describes how the source code was protected, which we'll cover in future blog posts, so stay tuned.Go prototype to generate non-forgeable build provenanceTo create tamperless evidence of the build and allow consumer verification, you need to:Isolate the provenance generation from the build process;Isolate against maintainers interfering in the workflow;Provide a mechanism to identify the builder during provenance verification.The full isolation described in the first two points allows consumers to trust that the provenance was faithfully recorded; entities that provide this guarantee are called trusted builders.Our Go prototype solves all three challenges. It also includes running the build inside the trusted builder, which provides a strong guarantee that the build achieves SLSA 3's ephemeral and isolated requirement.How does it work?The following steps create the trusted builder that is necessar | Solardwinds |
1
We have: 1 articles.
We have: 1 articles.
To see everything:
Our RSS (filtrered)
