https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html * [googlelogo] Security Blog The latest news and insights from Google on security and safety on the Internet Introducing SLSA, an End-to-End Framework for Supply Chain Integrity June 16, 2021 Posted Kim Lewandowski, Google Open Source Security Team & Mark Lodato, Binary Authorization for Borg Team Supply chain integrity attacks--unauthorized modifications to software packages--have been on the rise in the past two years, and are proving to be common and reliable attack vectors that affect all consumers of software. The software development and deployment supply chain is quite complicated, with numerous threats along the source build publish workflow. While point solutions do exist for some specific vulnerabilities, there is no comprehensive end-to-end framework that both defines how to mitigate threats across the software supply chain, and provides reasonable security guarantees. There is an urgent need for a solution in the face of the eye-opening, multi-billion dollar attacks in recent months (e.g. SolarWinds, Codecov), some of which could have been prevented or made more difficult had such a framework been adopted by software developers and consumers. Our proposed solution is Supply chain Levels for Software Artifacts (SLSA, pronounced "salsa"), an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. It is inspired by Google's internal "Binary Authorization for Borg" which has been in use for the past 8+ years and is mandatory for all of Google's production workloads. The goal of SLSA is to improve the state of the industry, particularly open source, to defend against the most pressing integrity threats. With SLSA, consumers can make informed choices about the security posture of the software they consume. How SLSA helps SLSA helps to protect against common supply chain attacks. The following image illustrates a typical software supply chain and includes examples of attacks that can occur at every link in the chain. Each type of attack has occured over the past several years and, unfortunately, is increasing as time goes on. [LCcLLTQ_obo0rNMsXTA4WVsmLparOGHfCUWgJDSkfDpGRIxo63jes0cywMw5w0qq3mQUIztCpRBdajOS_nLKy-JmU3KuoonZp] Threat Known example How SLSA could have helped Linux hypocrite commits: Submit bad Researcher attempted to Two-person review caught A code to the intentionally introduce most, but not all, of the source vulnerabilities into the vulnerabilities. repository Linux kernel via patches on the mailing list. Compromise PHP: Attacker compromised A better-protected source B source PHP's self-hosted git code platform would have control server and injected two been a much harder target platform malicious commits. for the attackers. Build with A SLSA-compliant build official Webmin: Attacker modified server would have produced process but the build infrastructure provenance identifying the C from code to use source files not actual sources used, not matching matching source control. allowing consumers to detect source such tampering. control SolarWinds: Attacker Higher SLSA levels require Compromise compromised the build stronger security controls D build platform and installed an for the build platform, platform implant that injected making it more difficult to malicious behavior during compromise and gain each build. persistence. event-stream: Attacker Applying SLSA recursively to added an innocuous all dependencies would have Use bad dependency and then prevented this particular dependency updated the dependency to vector, because the E (i.e. A-H, add malicious behavior. provenance would have recursively) The update did not match indicated that it either the code submitted to wasn't built from a proper GitHub (i.e. attack F). builder or that the source did not come from GitHub. Upload an CodeCov: Attacker used Provenance of the artifact artifact leaked credentials to in the GCS bucket would have F that was not upload a malicious shown that the artifact was built by the artifact to a GCS bucket, not built in the expected CI/CD system from which users download manner from the expected directly. source repo. Attacks on Package Similar to above (F), Mirrors: Researcher ran provenance of the malicious Compromise mirrors for several artifacts would have shown G package popular package that they were not built as repository repositories, which could expected or from the have been used to serve expected source repo. malicious packages. Trick Browserify typosquatting: SLSA does not directly consumer Attacker uploaded a address this threat, but H into using malicious package with a provenance linking back to bad package similar name as the source control can enable original. and enhance other solutions. What is SLSA In its current state, SLSA is a set of incrementally adoptable security guidelines being established by industry consensus. In its final form, SLSA will differ from a list of best practices in its enforceability: it will support the automatic creation of auditable metadata that can be fed into policy engines to give "SLSA certification" to a particular package or build platform. SLSA is designed to be incremental and actionable, and to provide security benefits at every step. Once an artifact qualifies at the highest level, consumers can have confidence that it has not been tampered with and can be securely traced back to source--something that is difficult, if not impossible, to do with most software today. SLSA consists of four levels, with SLSA 4 representing the ideal end state. The lower levels represent incremental milestones with corresponding incremental integrity guarantees. The requirements are currently defined as follows. [xImMHmA4tgKvLidz2YQEglPLz_Oz1ynorznP3mcRpGZ7zqBv4KeV4SDFXf4fRO] SLSA 1 requires that the build process be fully scripted/automated and generate provenance. Provenance is metadata about how an artifact was built, including the build process, top-level source, and dependencies. Knowing the provenance allows software consumers to make risk-based security decisions. Though provenance at SLSA 1 does not protect against tampering, it offers a basic level of code source identification and may aid in vulnerability management. SLSA 2 requires using version control and a hosted build service that generates authenticated provenance. These additional requirements give the consumer greater confidence in the origin of the software. At this level, the provenance prevents tampering to the extent that the build service is trusted. SLSA 2 also provides an easy upgrade path to SLSA 3. SLSA 3 further requires that the source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance, respectively. We envision an accreditation process whereby auditors certify that platforms meet the requirements, which consumers can then rely on. SLSA 3 provides much stronger protections against tampering than earlier levels by preventing specific classes of threats, such as cross-build contamination. SLSA 4 is currently the highest level, requiring two-person review of all changes and a hermetic, reproducible build process. Two-person review is an industry best practice for catching mistakes and deterring bad behavior. Hermetic builds guarantee that the provenance's list of dependencies is complete. Reproducible builds, though not strictly required, provide many auditability and reliability benefits. Overall, SLSA 4 gives the consumer a high degree of confidence that the software has not been tampered with. More details on these proposed levels can be found in the GitHub repository, including the corresponding Source and Build/Provenance requirements. We are open to feedback and suggestions for changes on these requirements. Proof of Concept Today, we are releasing a proof of concept for SLSA 1 provenance generator (repo, marketplace). This will allow a user to create and upload provenance alongside their build artifacts, thereby achieving SLSA 1. To use it, add the following snippet to your workflow: - name: Generate provenance uses: slsa-framework/github-actions-demo@v0.1 with: artifact_path: Going forward, we plan to work with popular source, build, and packaging platforms to make it as easy as possible to reach higher levels of SLSA. These plans include generating provenance automatically in build systems, propagating provenance natively in package repositories, and adding security features across the major platforms. Our long-term goal is to raise the security bar across the industry so that the default expectation is higher-level SLSA security standards, with minimal effort on the part of software producers. Summary SLSA is a practical framework for end-to-end software supply chain integrity, based on a model proven to work at scale in one of the world's largest software engineering organizations. Achieving the highest level of SLSA for most projects may be difficult, but incremental improvements recognized by lower SLSA levels will already go a long way toward improving the security of the open source ecosystem. We look forward to working with the community on refining the levels as we begin adopting SLSA for our own open source projects. If you are a project maintainer and interested in trying to adopt and provide feedback on SLSA, please reach out or come join the discussions taking place in the OpenSSF Digital Identity Attestation Working Group. Check out the Know, Prevent, Fix post to read more about Google's overall approach to open source security. Share on Twitter Share on Facebook Google Labels: Open Source , Security No comments : Post a Comment [ ] # [ncccFICB87] Labels * #sharethemicincyber * android * android security * android tr * app security * big data * biometrics * blackhat * C++ * chrome * chrome security * CTF * diversity * encryption * federated learning * fuzzing * Gboard * google play * google play protect * interoperability * kubernetes * memory safety * Open Source * pha family highlights * privacy * Rowhammer * rust * Security * sigstore * spyware * targeted spyware * vulnerabilities # Archive * 2021 + Jun + May + Apr + Mar + Feb + Jan * 2020 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2019 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2018 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2017 + Dec + Nov + Oct + Sep + Jul + Jun + May + Apr + Mar + Feb + Jan * 2016 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2015 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb + Jan * 2014 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + Apr + Mar + Feb + Jan * 2013 + Dec + Nov + Oct + Aug + Jun + May + Apr + Mar + Feb + Jan * 2012 + Dec + Sep + Aug + Jun + May + Apr + Mar + Feb + Jan * 2011 + Dec + Nov + Oct + Sep + Aug + Jul + Jun + May + Apr + Mar + Feb * 2010 + Nov + Oct + Sep + Aug + Jul + May + Apr + Mar * 2009 + Nov + Oct + Aug + Jul + Jun + Mar * 2008 + Dec + Nov + Oct + Aug + Jul + May + Feb * 2007 + Nov + Oct + Sep + Jul + Jun + May # [8LnOxYWFhZ] Feed # Follow @google [facebook-l]Follow # Give us feedback in our Product Forums. # [P2DAYDAaDwWA] * Google * Privacy * Terms