One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 4593786 |
| Date de publication | 2022-04-13 12:30:56 (vue: 2022-05-13 21:47:30) |
| Titre | How to SLSA Part 1 - The Basics |
| Texte | Posted by Tom Hennen, Software Engineer, BCID & GOSST One of the great benefits of SLSA (Supply-chain Levels for Software Artifacts) is its flexibility. As an open source framework designed to improve the integrity of software packages and infrastructure, it is as applicable to small open source projects as to enterprise organizations. But with this flexibility can come a bewildering array of options for beginners-much like salsa dancing, someone just starting out might be left on the dance floor wondering how and where to jump in.Though it's tempting to try to establish a single standard for how to use SLSA, it's not possible: SLSA is not a line dance where everyone does the same moves, at the same time, to the same song. It's a varied system with different styles, moves, and flourishes. The open source community, organizations, and consumers may all implement SLSA differently, but they can still work with each other.In this three-part series, we'll explore how three fictional organizations would apply SLSA to meet their different needs. In doing so, we will answer some of the main questions that newcomers to SLSA have:Part 1: The basicsHow and when do you verify a package with SLSA?How to handle artifacts without provenance?Part 2: The detailsWhere is the provenance stored?Where is the appropriate policy stored and who should verify it?What should the policies check?How do you establish trust & distribute keys?Part 3: Putting it all togetherWhat does a secure, heterogeneous supply chain look like?The SituationOur fictional example involves three organizations that want to use SLSA:Squirrel: a package manager with a large number of developers and usersOppy: an open source operating system with an enterprise distributionAcme: a mid sized enterprise. Squirrel wants to make SLSA as easy for their users as possible, even if that means abstracting some details away. Meanwhile, Oppy doesn't want to abstract anything away from their users under the philosophy that they should explicitly understand exactly what they're consuming.Acme is trying to produce a container image that contains three artifacts:The Squirrel package 'foo'The Oppy package 'baz'A custom executable, 'bar', written by Acme employeesThis series demonstrates one approach to using SLSA that lets Acme verify the Squirrel and Oppy packages 'foo' and 'baz' and its customers verify the container image. Though not every suggested solution is perfect, the solutions described can be a starting point for discussion and a foundation for new solutions.BasicsIn order to SLSA, Squirrel, Oppy, and Acme will all need SLSA capable build services. Squirrel wants to give their maintainers wide latitude to pick a builder service of their own. To support this, Squirrel will qualify some build services at specific SLSA levels (meaning they can produce artifacts up to that level). To start, Squirrel plans to qualify GitHub Actions using an approach like this, and hopes it can achieve SLSA 4 (pending the result of an independent audit). They're also willing to qualify other build services as needed. Oppy on the other hand, doesn't need to support arbitrary build services. They plan to have everyone use their Autobuilder network which they hope to qualify at SLSA 4 (they'll conduct the audit/certification themselves). Finally, Acme plans to use Google Cloud Build which they'll self-certify at SLSA 4 (pending the result of a Google-conducted a |
| Envoyé | Oui |
| Condensat | :such able abstract abstracting acceptable accepted accomplished achieve acme actions actually affect after all allowed allowing allows already also analysis answer anything applicable apply approach approaches appropriate arbitrary are array artifact artifacts artifacts:the asking attestation attestations audit audit/certification auto autobuilder away bar base basics basicshow basicsin baz bcid because been beginners being believes benefits bewildering build builder built but caching can capable case cases certify chain changes check checking cloud code com/foo come community complex computing conduct conducted connectivity consumers consuming container contains context control coordinate corresponding could cover creating critical custom customers dance dancing data decisions delegated demonstrates dependencies described designed desirable details detailswhere determine developers different differently difficult directly discussion distribute distributed distributionacme: does doesn doing don downstream each easier easy employeesthis engineer ensure enterprise establish established even every everyone exactly example executable explicitly explore external fictional finally flexibility floor flourishes follow foo foundation framework free from full future gather gathered gathering generate generated github give given good google gosst one got great hand handful handle happen have have:part having helpful hennen heterogeneous higher hope hopes how http://example idea image implement import important imported importer improve increase independent inevitably information infrastructure install installacme installed instead integrity interested intermediaries internal involves isn issue its job jobs jump just keys kyverno large larger latency latitude launching left lets level levels like likely likes limited line look lot made main maintainers make manager many may meaning means meanwhile meet meets met mid might model moment more most moves much must native necessitate need needed needs network new newcomers next not now number once one only open operating operation oppy options optionsfull order organizations original other out own package packages part parties party pending perfect perform performed performs perhaps philosophy pick place plan plans point policies policy possible possible: post posted prefers prepared prevent prioritize problem process produce produced projects provenance provide published put putting qualification qualify questions quickly quite really receive reliability remove repo repository reposquirrel require required requires result results right run salsa same scaling scan secure security seems self series service services sha256:abc should shows signature similar simpler simplified simplifies since single site sitting situationour sized slsa slsa:squirrel: small software solution solutions some someone something song sort source sources specialized specific squirrel standard start starting storage stored story styles such sudden suggested summary supply support sure system systems take taking tampered tampering tcb tempting tgz themselves then these they things though three time timein times to: togetherwhat tom too tool tradeoffs traffic trust trusted try trying typically unable under understand upstream use used users usersoppy: useverification using value varied verification verificationat verificationwhen verified verify verifyverification very vsa vsas vulnerability vulns want wants what when where which who wide will willing without wondering work would written yet “how “is “where |
| Tags | |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.