Attestations play a big function in SLSA and it’s important that buyers of artifacts know the place to search out the attestations for these artifacts.
Attestations might be colocated within the repository that hosts the artifact. That is how Squirrel plans to retailer attestations for packages. They even wish to add assist to the Squirrel CLI (e.g. acorn get-attestations foo@1.2.3).
Acme actually likes this strategy as a result of the attestations are at all times accessible and it doesn’t introduce any new dependencies.
Rekor
In the meantime, Oppy plans to retailer attestations in Rekor. They like having the ability to direct customers to an current public occasion without having to keep up any new infrastructure themselves, and the in-depth protection the transparency log supplies towards tampering with the attestations.
Although the latency of querying attestations from Rekor is probably going too excessive for doing verification at time of use, Oppy isn’t too involved since they count on customers to question Rekor at set up time.
Hybrid
A hybrid mannequin can also be accessible the place the writer shops the attestations in Rekor in addition to co-located with the artifact within the repo—together with Rekor’s inclusion proof. This supplies confidence the information was added to Rekor whereas offering the advantages of co-locating attestations within the repository.
‘Coverage’ refers back to the guidelines used to find out if an artifact must be allowed for a use case.Insurance policies typically use the package deal title as a proxy for figuring out the use case. An instance being, if you wish to discover the coverage to use you might search for the coverage utilizing the package deal title of the artifact you’re evaluating.
Coverage specifics might fluctuate based mostly on ease of use, availability of knowledge, danger tolerance and extra. Full verification wants extra from insurance policies than delegated verification does.
Default insurance policies permit admission choices with out the necessity to create particular insurance policies for every package deal. A default coverage is a manner of claiming “something that doesn’t have a extra particular coverage should adjust to this coverage”.
Squirrel plans to finally implement a default coverage of “any package deal and not using a extra particular coverage will likely be accepted so long as it meets SLSA 3”, however they acknowledge that almost all packages don’t assist this but. Till they obtain vital mass they’ll have a default SLSA 0 coverage (all artifacts are accepted).
Whereas Oppy is leaving verification to their customers, they’ll counsel a default coverage of “any package deal constructed by ‘https://oppy.instance/slsa/builder/v1’”.
Squirrel additionally plans to permit customers to create insurance policies for particular packages. For instance, this coverage requires that package deal ‘foo’ will need to have been constructed by GitHub Actions, from github.com/foo/acorn-foo, and be SLSA 4.
Squirrel will even permit packages to create SLSA 0 insurance policies in the event that they’re not utilizing SLSA compliant infrastructure.
Coverage add-ons
Coverage analysis might do extra than simply consider the SLSA necessities. The identical insurance policies that test SLSA necessities are effectively positioned to test different properties which might be essential to organizations like “was static evaluation carried out”, “are there any identified CVEs on this artifact”, “was integration testing profitable”, and so on…
Acme is absolutely interested by a few of these coverage add-ons. They’d wish to keep away from the embarrassing scenario of publishing a brand new container picture with identified CVEs. They’re undecided how one can implement it but however they’ll be looking out for instruments that may assist them accomplish that.
Delegated insurance policies
When utilizing delegated verification there’s a lot much less that truly must be checked and they are often hard-coded immediately in tooling. A minimal delegated verification coverage may be “permit if trusted-party verified this artifact (recognized by digest) as <package deal title>”. This may be tightened additional by including necessities on the artifact & its dependencies SLSA ranges (knowledge which is offered within the VSA). For instance, “permit if trusted-party verified this artifact as <package deal title> at SLSA 3 and it doesn’t have any dependencies lower than SLSA 2”.
When utilizing particular, non-default, insurance policies verifiers must know the place to search out the coverage they should consider.
Squirrel plans to retailer particular insurance policies as a property of the package deal within the repository. This makes them very simple for customers and their tooling to search out. It additionally permits the maintainer of the package deal to simply set the coverage (they have already got write permissions!).
A possible draw back is that the write permissions are the identical as for the package deal itself. An attacker that compromises the developer’s credentials might additionally change the coverage. This will not be as unhealthy because it appears. Insurance policies are human-readable so anybody paying consideration would discover that package deal foo’s coverage now says that it may be constructed from github.com/not-foo/acorn-foo. Squirrel plans to inform events (together with the maintainer!) when the coverage adjustments, doubtlessly letting them “sound the alarm” if something nefarious occurs.
An analogous strategy is taken in a variety of contact-change workflows. For instance, while you change your tackle along with your financial institution, the financial institution will ship you an electronic mail (and a letter to the outdated tackle) letting you already know the tackle has been modified. This sort of notification would alert the maintainer to a possible compromise.
Squirrel would additionally contemplate requiring a second individual to overview any coverage adjustments for packages with over 10,000 customers.
Public canonical Git repo
An alternative choice may be to simply create a canonical git repo (e.g. github.com/slsa-framework/slsa-acorn-policies) and let individuals publish proposed insurance policies there. This has the benefit of utilizing a separate ACL management mechanism from the package deal repository itself, however the disadvantages of being troublesome to make sure the creator of the coverage is definitely allowed to set the coverage for that package deal and never scaling effectively because the repo grows.
The strategy outlined in coverage auto technology might assist right here. Automation within the repo might simply take a look at the final N releases of the package deal and decide if the proposed coverage matches what’s truly been revealed. Proactive adjustments to the coverage (like deciding to change from GitHub Actions to CircleCI) can be tougher to coordinate nevertheless.
Org particular repo
Acme plans to determine their very own org particular repo for coverage storage. This provides them a single place to retailer all their insurance policies, no matter ecosystem kind, and lets them present extra particular insurance policies for packages supplied by upstream repos. Since Oppy doesn’t have any plans to offer package-specific insurance policies this provides Acme a spot to retailer their very own insurance policies for Oppy packages (in the event that they ever get round to it).
Organizations also can use their coverage repo to vet any upstream adjustments to coverage and doubtlessly add further checks (e.g. “doesn’t have any identified vulnerabilities”).
Acme desires to make use of delegated verification and that depends on having trusted verifiers to make choices for downstream customers. Who’re these trusted verifiers?
A public repo is in an awesome place to behave as a trusted verifier for his or her customers. Customers already belief these repos they usually might already be doing verification on import.
Squirrel plans to utilize this by making VSAs accessible for every artifact revealed, publicizing their verifier ID (i.e. ‘https://squirrel.instance/slsa-verifier’) and the general public key used to signal the VSAs. They even plan to construct VSA verification immediately into the Squirrel tooling, in order that customers can get SLSA safety by default.
Org-wide verifier
Whereas Acme is comfortable to make use of Squirrel’s verifier (and the verification constructed into the tooling) they nonetheless want their very own verifier to allow them to publish VSAs to Acme clients. So Acme plans to face up their very own verification service and publish their verifier ID (i.e. ‘https://acme.instance/private-verifier’) and signing key. Acme clients can then confirm the software program they get from Acme.
Sooner or later Acme might require all software program used all through the corporate to be verified with this verifier (as a substitute of counting on public verifiers). They’d do the verification and generate VSAs at any time when artifacts are imported into their personal Artifactory occasion. They may then configure this ID/key pair to be used all through Acme and be assured that any software program used has been verified based on Acme coverage. That’s not Acme’s highest precedence for the time being, however they like having this feature open to them.
When utilizing delegated verification this might be the best case. Squirrel can simply construct the important thing they used for delegated verification immediately into the Squirrel tooling. Acme also can pretty simply configure the usage of their keys by way of the corporate utilizing current configuration management mechanisms.
When utilizing full verification this may be tougher. If there are a number of builders that might be accepted the keys that signal the attestations must be distributed to everybody which may use that builder. For Squirrel this may be actually troublesome since they plan to permit package deal maintainers to make use of no matter builder they need. How these keys get configured can be tough only for Squirrel, and way more troublesome if downstream Squirrel customers wished to do full verification of the Squirrel packages.
The scenario is less complicated, nevertheless, for Oppy. That’s as a result of Oppy plans to solely settle for artifacts constructed by their autobuilder community. Oppy can configure this community to make use of a single (or small set) of keys after which publish these keys (and the SLSA stage Oppy believes it meets) for downstream customers.
Squirrel plans to unravel the issue of which keys they settle for by leveraging Fulcio. Squirrel will construct assist for Fulcio root keys into their verifier after which categorical which Fulcio topic is allowed to signal attestations within the particular coverage of every package deal. E.g. “Squirrel package deal ‘foo’ will need to have been constructed & signed by ‘spiffe://foobar.com/foo-builder, from github.com/foo/acorn-foo, and be SLSA 4”.
The Replace Framework (TUF)
The above strategies might be additional enhanced with TUF to permit the safe upkeep of keys. TUF metadata might embrace all of the SLSA keys, the construct providers and different entities they’re legitimate for, and the SLSA ranges they’re certified at. Oppy is contemplating utilizing TUF to let verifiers securely fetch and replace keys utilized by the Autobuilder community. Oppy would use a TUF delegation to point that these keys ought to solely be used for the builder id ‘https://oppy.instance/slsa/builder/v1’. Squirrel would possibly do one thing just like permit for updating the Fulcio key in its tooling.
Acme desires to file and confirm the dependencies that go into its container into the SLSA provenance. Acme would like that this performance had been simply built-in their construct service, however that function isn’t accessible but. As an alternative they’ll must do one thing themselves. They’ve a couple of choices at their disposal:
Since Oppy doesn’t construct SLSA into it’s tooling Acme will create wrapper scripts for dependency import/set up that file and confirm (utilizing cosign) dependencies as they’re put in. Acme will replace their construct scripts to exchange all cases of Oppy package deal set up with the wrapper script after which use the recorded outcomes to assist populate the supplies part of the provenance.
A draw back is that this strategy, if run within the construct itself, is just not assured to be full and can’t meet the “non-falsifiable” requirement (because the outcomes reported by the wrapper might be falsified by the construct course of), relegating this strategy to SLSA 2. Nonetheless, it permits Acme to make progress SLSA-fying their builds and supplies a place to begin for attaining greater SLSA ranges.
Constructed into ecosystem tooling
Since Squirrel does construct verification into their tooling, Acme can simply use acorn set up to confirm the dependencies and file what was put in. Acme can use this data to populate the Squirrel packages put in within the supplies part of the provenance and it may possibly embrace the attestations of these dependencies within the in-toto bundle for his or her container picture.
As with device wrappers, if this technique is used within the construct itself it can’t meet “non-falsifiable” requirement.
Proxied verification
Acme thought of making a proxy for his or her current builder to proxy outbound connections. This proxy might confirm all the things fetched and use its logs to populate the provenance. Since this proxy is trusted it could be simpler to satisfy “non-falsifiable” requirement. Sadly it’s additionally plenty of work for Acme in order that they’re going to defer this concept for now.
Within the first two elements of this collection, we’ve coated the fundamentals of getting began with SLSA and the small print of coverage and provenance storage, coverage verification, and key dealing with. In our subsequent publish we’ll cowl how Squirrel, Oppy, and Acme put this all collectively to guard a heterogeneous provide chain.
