slsa-framework / slsa Goto Github PK

We should include recommendations on how to convey the maximum SLSA level the keys are valid for.

For example:

• Publish on a website
• Some sort of PKI with an accreditation body signing certs with a different root cert for each SLSA level
• Sigstore integration
• ...

I suggest changing "Deploy" to "Release" (where it produces a resource). You might also want add another step that involves the user "acquiring" the resource.

I think typically the word "deploy" means "install & operate in the production environment". It makes sense why Google would use the word "deploy" and "release" synonymously, since they're often the same for Google.

But for many situations, a release is NOT the same as deployment. E.g., if someone releases a package on PyPI or npm, that does NOT mean it's deployed, that just means it is now available for users to download & possibly deploy.

"Artifact that was directly authored or directly by persons..."

Is it intend to say directly or indirectly authored?

Currently (as of), the requirements doc says of reviewing that:

Every change in the revision's history was agreed to by two trusted persons prior to submission, and both of these trusted persons were strongly authenticated.

The term "review" or "reviewer" implies that second, third etc participants do so asynchronously, following from a change being added to the history in some form.

It's unclear to me if this either includes, or excludes, pair programming and mob programming as acceptable instances of two trusted persons. I am strongly of the opinion that such ought to be acceptable for SLSA, so long as "strongly authenticated" can be satisfied.

I think there are two main "audiences" for these requirements (maybe more):

• Developers that publish open source artifacts
• Organizations that operate build systems (company internal, public services, community-run, whatever)

Some of the requirements span both, but I think most can be separated into one of these categories pretty cleanly. Then the flow could read like:

Are you just trying to publish a package that meets SLSA N? First pick a build system that has been accredited to meet at least the SLSA N levels, then make sure you follow these practices...

Are you trying to operate a build system that meets SLSA N? Make sure you configure it and operate it according to these practices...

The "readable" criterion has a loophole: Would a JPEG of the source code be acceptable as source code? Presumably not, but that's not clear.

I suggest adding a related criterion 'editable': The source artifact for a work means the preferred form of the work for making modifications to it.

This could also be added as part of readable.

We already require retention of sources. Do we require retention of the inputs to the build as well?

It's tempting to think the attacks like the event-stream incident could be avoided by requiring all one's dependencies to be SLSA3-compliant, but I wonder if it is the intent of the SLSA document to make that claim.

The event-stream incident happened because the previous maintainers handed over control to a new team. As it happens, there was only one maintainer in the first group and only one in the second group, but it seems like it would be reasonable to imagine a situation where event-stream had two maintainers (as would be required to be SLSA3-compliant), both of which would be happy to hand over the reigns to a new team, which could easily consist of two collaborators. In this situation, wouldn't the same attack as affected event-stream users still work?

The downstream users of the package, when rolling their dependency, would do their due diligence, see that there was a new team in place, verify that they are still operating as a SLSA3-compliant team, and miss that the team's values have changed.

Edit 2022-10-17: This issue is being slightly repurposed to decide requirements and/or guidelines on how artifacts are automatically verified to meet the SLSA requirements.

Tasks:

• Describe how the overall system works: builds generate provenance and downstream systems compare this to an expectation at various points (not sure where this should go)
• levels.md: explain that users set expectations and downstream systems verify them
• requirements.md: add detailed requirements and recommendations for how this system must/should work
• #168

Context: #130

Original post

There was a lot of discussion in #37 that seems to indicate there's still an apparent disconnect on policy (who produces/owns it) and evaluation (when/where to evaluate that policy).

I think, for the most part, we actually agree with one another. There are just some slight misunderstandings that are confusing us.

I think the following are the open questions:

1. Who creates and owns the policy?
2. Should we have a separate set or recommendations on what a good policy looks like?
3. Should those requirements and recommendations be part of the SLSA levels (e.g. SLSA 3P) or separate from it?
4. What use cases are we targeting?
   A. complete end-to-end: producer creates and artifact & provenance and those make their way all the way to the consumer who then checks the artifact & provenance against their own policy
   B. early evaluation: producer creates and artifact & provenance and at some point of trust (e.g. code signing, ACL'd folder, repo upload) that artifact & provenance against some other policy
5. What do people mean when they talk about 'resource'?

Does that sound right?

My opinion on what the answers to these questions are:

1. Who creates and owns the policy?

Some of the discussion in #37 has changed my mind.

So, now my opinion is "anyone that cares can create a policy".

The question itself is a bit of a misnomer. There isn't necessarily one single policy that should be evaluated. There could be many policies created and owned by different people. Anyone that cares about the artifact can create their own policy. The artifact producer themselves can create a policy if they want, but it's not required. Downstream users can use the producer's policy if they wish (and there's a way for them to get it securely), but they can also create their own policy (perhaps using create on first use as has been discussed in #37).

One thing we do have to watch out for when there are lots of policies is what happens if/when the software creators refactor how their code is built. E.g. changing the name of the Makefile target, switching repos, etc...

2. Should we have a separate set of recommendations on what a good policy looks like?

Yes, I think so. I think having a separate clear set of requirements for policy would help. We have this internally and I think it's helpful.

3. Should those requirements and recommendations be part of the SLSA levels (e.g. SLSA 3P) or separate from it?

I think it can be helpful to include them as a part of the SLSA levels, but I don't feel that strongly about it. A reason to do this is that it would be very easy for someone to create a bad policy that doesn't actually provide as much security benefit as they might like. E.g. "Any artifact built by GitHub Actions SLSA 3 builder". Since GitHub Actions is public a malicious actor could create whatever malicious artifact they want with GitHub Actions, and get the policy evaluator to accept that. There'd still be some protection since after the fact an audit could be done to see who built that thing and what source it came from (which might deter some, but not all actors).

4. What use cases are we targeting?

I think we should target both A and B. A is the grand vision of where we want the entire industry to go. It might be easier to achieve in some cases than B, but in others it might be harder. B is a bit more limited but allows for adoption in cases that might otherwise be harder to implement. E.g. It would be much easier to protect the signing operation of an iOS app with SLSA than to add support for evaluating SLSA provenance into iOS.

5. What do people mean when they talk about 'resource'?

This is just the name of the 'thing' or operation that is being protected by a policy.

Example: PyYAML

Let's assume that policy is evaluated in two places:

1. GitHub Artifact Publishing Service (GAPS) which checks policy before uploading a package to a repo. This service manages the credentials needed to upload to the repo for the user.
2. An upgraded PyPI client that checks policy before installing a package it got from PyPI.

For both 1 and 2 the systems need to know what policy to evaluate at any given time.

GAPS publishes lots of stuff, so it needs to lookup the policy for the thing being published. It might do this by looking up the policy in map based on the name of the thing it's publishing "pypi:pyyaml". How this policy is created and managed is up to GAPS.

The upgraded PyPI client, meanwhile, installs lots of packages. If it creates policy on first use it still needs to store that policy somewhere and it needs to be able to distinguish the policy for PyYAML from the policy for urllib3. So it might have a database where it can lookup policies based on the name of the thing it's installing. E.g. "pyyaml" or "urllib3".

The policy being evaluated by GAPS and the PyPI service could very well be different and that's totally fine.

It may be that some policies don't have an explicit resource, perhaps it's just some configuration flag that you add to a tool that only does one task. Perhaps when you configure GAPS for your project it doesn't used named policies it just has you provide the policy file. That's fine. But it's still probably the case that some thing (even if not explicit) is being protected by a policy, and that thing is what we call the resource.

SLSA 4 calls for two-person informed review of all submissions. The current framing indicates that levels 1 through 3 are OK with authors submitting code without any review.

Should one of the lower SLSA levels call for some informed review by a single independent reviewer?

Currently (as of), the requirements doc says of identifying artifacts that:

The provenance identifies the output artifact via a cryptographic hash. The RECOMMENDED algorithm is SHA-256 for cross-system compatibility. If another algorithm is used, it SHOULD be resistant to collisions and second preimages.

It would be useful if provenance tooling could calculate multiple digests, so that if one digest algorithm is rendered untrustworthy, there is still a redundant way to assure integrity.

1. Recommending an algo+digest format, eg JWT's alg field or W3C Subresource Integrity.
2. Allow provenance systems to attach multiple digests to a single resource.

We have already defined SLSA to be non-transitive, such that the SLSA rating of built artifact does not depend on the ratings of its dependencies. But currently it does depend on its sources' ratings, which is odd because we don't have a strong definition of source vs dependency.

I propose that we fully split, such that each resource always has its own rating. Then we could split the requirements, one set for sources and one set for built artifacts. This would make things like two-person control more clear. For example, a GitHub repo that is owned by a single person may only be SLSA 2 (no two-party control), yet its built packages are all SLSA 3 because it uses an approved builder with provenance and reproducibility.

By the way, perhaps we should call the output of a build a "Package." That term fits the most common usage, and it is arguably correct for all examples. (Thanks @david-a-wheeler for the suggestion.)

Right now it is not clear what attacks SLSA prevents. Example issues: #34, #35.

Tasks:

• Add a threat model diagram and list of attacks.
• Explain what attacks are mitigated (and to what extent) at each level.
• Explain what other threats remain that SLSA does not address.
• Add real-world examples like SolarWinds, event-stream, Great Suspender, and CodeCov, along with how those attacks could have been mitigated with SLSA.

Status update, 2021-11-15: https://slsa.dev/threats exists but still has several TODOs. I'll leave this issue open as a reminder to finish it.

It would be good to have a very low-barrier-to-entry first level that is basically "Is it signed at all" and perhaps "must be signed in an interoperable format." That is roughly what we have right now.

It would be useful to have an intermediate level that says:

• Must be generated by the platform.
• Must specify top-level sources.
• Must have some cryptographic integrity guarantees.

SLSA 2 is too high because it requires build isolation, which is much harder to do.

My experience of several real supply-chain vulnerabilities is that integrity of the finished product depends on the whole supply chain. In particular, incidents like left-pad,
shared-mime-info, and a host of others have seen
substantial disruptions as a result of problems deep in the dependency tree.

With that in mind, I have a hard time seeing how SLSA levels can reasonably be independent of the quality assessment of the dependencies they rely on. If I read things right, you could have an SLSA 4 rating on a final product, but that rating could include components that were unrated or SLSA 0 or even I guess known to have problems.

Did I miss something crucial here? I just don't see the point of having hypercorrect build patterns for the finished product if the components it's being built from are not adequately testable.

Right now SLSA does not require the provenance to be in a particular format. The intention is that some companies (like Google) may may have a purely internal SLSA implementation that is not interoperable. We want that to still be called "SLSA 3" even if it can't be checked outside.

That said, we want the format to be interoperable. Maybe we say that it needs to be a particular format within a closed ecosystem, and within the "internet" ecosystem we require in-toto attestations?

Might as well lump PKI into this.

We need to decide on a strategy for how to version the SLSA standards. We are not likely to get everything right on the first try. Plus, we need to break up the problem and make incremental progress before everything is figured out.

Questions:

1. Will we use make versioning explicit? Something like "SLSA N, revision X"? I can't think of another option, but I'd love to hear ideas.
2. Assuming we have an explicit version, how do we call it? "SLSA N, revision X"? Date? "Draft"? "Alpha"? Something else?
3. We likely will have initial revisions that are under specified. Should the name be different for those to indicate that they are partial? "Interim"? "Provisional"?
4. What criteria should we use for giving something a version? Periodic cadence? "When it's ready"? "ASAP"?

In the "Terminology" table, in the build row, add the example "Building an installable package (including a system-level package or language-level package)."

I've having a hard time understanding the choice of the term "hermetic" to describe one of the criteria.

I'm familiar with the phrase "hermetically sealed", e.g. thoroughly shrink-wrapped, which has some meaning somehow related to the use of the term here.

The other definition is "Having to do with the occult sciences, especially alchemy; magical." That seems equally likely.

Can someone unpack this for me?

Is it worth differentiating between "data owner" and "system admin" in the context of SLSA 4? Does such a distinction add any value?

• Data owner: user with elevated privileges. The platform must prevent these users from bypassing or disable controls.

  • Example: A GitHub user with "admin" privileges, such as a project owner, can bypass the two-party review branch protection unless the include administrators option is set. Thus, the "include administrators" option is required to meet SLSA 4. (Disabling that option must also require two-party review, though that feature is not currently implemented on GitHub.)

• System admin: person that runs the platform or otherwise has "superuser" privileges. The organization that operates the platform must have processes to guarantee that these users do not abuse their privileges. Consumers have no choice but to trust that these processes are in place (though third-party audits can help increase that trust).

  • Example: A GitHub employee could theoretically write to any repository or push a malicious version of the server that writes to any repository.

The reason we might want to differentiate is that the "data owner" property is project-specific whereas the "system admin" property applies to the entire platform.

Issues like #100 show us that we need to clarify what specific things we expect users to get out of each level. Without this, we don't have a clear reason to add or remove a requirement at any particular level.

Example use cases for SLSA 1:

• Inventory all of the source and build systems used across a large organization.
• Prevent project maintainers from making mistakes in the release process, such as building from unsubmitted code.
• Adopt all the expected workflow changes now, as required by higher SLSA levels, while waiting for implementation (and security) to follow. For example, "enforcing" code review on all code changes, even though it can be bypassed by faking the provenance.

We should add a CONTRIBUTING.md file listing https://developercertificate.org/ and require a Signed-Off-By line (example), as required by OpenSSF.

See also #75 which would also go in CONTRIBUTING.md.

The README.md file goes through an extended discussion of the build
process for a curl Docker image, without any obvious evidence that
the author has been in communications with the Alpine team to better
understand how they do things and where those processes are documented.

For example, "The APKBUILD includes a sha256 hash of this file. It is not clear where that hash came from."

is documented here, at https://wiki.alpinelinux.org/wiki/APKBUILD_Reference

"The checksums are normally generated and updated by executing abuild checksum and should be the last item in the APKBUILD."

The SLSA document says:

• Attack any of the systems involved in the supply chain, as in the SolarWinds attack.

SLSA intends to cover all of these threats.

It's not clear to me how the proposed model would help in cases like the SolarWinds attack. For example, suppose an open source project uses Travis CI to build their binaries, and Travis CI's infrastructure is infiltrated in a manner similar to the SUNBURST hack: how would the open source project detect it? Short of having actual verified reproducible builds using a different CI, we could never trust that the binaries built by this open source project are correct, could we? (The SLSA document says "SLSA does not require verified reproducible builds directly".)

But even if we did have two CI systems building the code of this open source project, say both Travis CI and Cirrus CI, what would stop an attacker from compromising both? Surely then even verified reproducible builds wouldn't help?

It helps to explain not just what a system must do to meet SLSA N, but also why along with examples showing common scenarios.

Thanks @david-a-wheeler for the suggestion.

Given this is centered on artifacts, I think the term "publish" is more commonly used. In my mental model:

Deployment == fetching an artifact and running it.
Publish == building an artifact and making it available.

This is to try to get to a consensus on fully defining SLSA1, or basically filling in that column:

Readability: Required
Retention: Not Required
Change History: Not Required
Two-Person Review: Not Required

Automation: Required
Isolation: Not Required
Hermeticity: Not Required
Reproducibility: Not Required
Source Integrity: Not Required
Provenance: I'd recommend we require this, but drop the "signing" component.

Provenance Chain: Same as above
Policy: I'd recommend dropping this one for SLSA1.
Enforcement: I'd recommend dropping this one for SLSA1.
Logging: Required

Security: We should do something here. Maybe "ephemeral environments" as a good first step?
Access: Something small here.
Superusers: Something small here.

I think this proposal consists of two "big" changes. The first is that we drop the worked "signing" from provenance and provenance chain at SLSA 1. In multi-party systems like these, signing (and PKI) is too hard to get right today. Further, signing is an implementation detail. The real goal is tamper-resistant, verifiable provenance. There are other ways to achieve this goal.

The second change is to drop policy and enforcement. I'm not aware of any package managers or artifact registries that would actually support this mechanism. I also think encouraging this idea too much might cause end users to rely on it. Users of these artifacts should be the ones responsible for defining, verifying, and checking policy. Distribution systems can do this as well to help "shift left" and catch issues earlier, but this doesn't exist anywhere today and users will want to verify on their own anyway.

We still need to fill in some basic security hygiene for security, access and superusers, but this gets us closer!

Many open source projects only have one maintainer. How will they meet the 2 person review requirement? Are tools like automated code reviews in scope for meeting this requirement?

The document isn't very clear about constructs like curl | sh . I'm guessing that won't be hermetic, and thus not okay, though maybe it's considered "prebuild" and thus just fine?

The curl | sh and similar constructs enable essentially undetected attacks & make it impossible to later determine what happened. However, they're also convenient, and many people don't care much about security so they're in use. For example, the recommendations for installing Rust recommend them: https://www.rust-lang.org/tools/install

At the least the document should be clear. I think curl | sh is dangerous myself, but clearly that's not a universal position.

Many (possibly most) OSS projects are single-person. Yes, it'd be awesome if they had multiple people, but for a variety of reasons they don't. If those with multiple people would be hard-pressed to always have changes reviewed by a second person.

It is obviously much better if a project has 2-person control (non-unilateral), but since that will often not be possible, we should have a level that expresses what we can get in that case.

I think it'd be good to have at least one level between SLSA 2 and 3, call it 2.5, that adds hermiticity without non-unilateral (2-person control). That way, you get what you can get out of a smaller project.

The definition of Build describes the inputs "may be sources, dependencies, or ephemeral build outputs."

To my understanding, "dependencies" are persistent build output artifacts. Is that correct?
If so, I wonder what is the significance of differentiating the persistent vs. ephemeral artifacts?
Could we unify them and just define build input as "may be sources and output artifacts of prior builds."?

Right now SLSA provides all the requirements an artifact needs to meet at various levels.

SLSA also provides guidance on how to communicate how an artifact was built (use in-toto Provenance) and has an outstanding issue to communicate what source requirements were met.

It does not, however, provide any guidance on how to communicate the SLSA level that some entity evaluated an artifact to have.

Should we create some other in-toto predicate type to convey this information?

This would be useful for developers that do not want, or cannot, release the in-toto Provenance or source code attestations (potentially because they contain proprietary information) but still want to communicate to their downstream users the SLSA level of a given artifact.

We would probably also need to document the algorithm people should follow to determine an artifact's level (so that things are consistent at least). That is probably part of #46.

In "starting at the very end of the supply chain and working forward", the word "end" should be "beginning".

Currently https://github.com/slsa-framework/slsa-controls is a separate repo. Does that actually make sense? Should we just merge it here and add it as a subdirectory? That might make it easier for people to keep track of everything SLSA.

Any opinions one way or the other?

One way to reduce vulnerabilities in a product is to ensure that dependencies are kept up to date. This is a tedious process (especially when you have a lot of dependencies), so it is one that we usually want to automate.

How do such automated rollers fit in the SLSA framework?

curl/curl-docker doesn't use Travis CI anymore (or at least they removed travis.yml).

curl/curl-docker@df19807

I guess they switched to Zuul curl/curl-docker@4fc976c

The SLSA proposal omits reproducible builds, and I think that's a mistake.

Currently the proposal assumes that there are magical build systems that cannot be subverted. No such systems exist. You could use build systems that are protected/hardened, and that obviously reduces risk, but subverting a build environment is a known attack that just happened to SolarWinds' Orion & is one of the main reasons people are calling for improvements in supply chain integrity. Ignoring a well-known attack vector, especially one that is specifically the kind of attack people are trying to prevent, is a mistake.

Implementing reproducible builds is usually not that hard. Typical challenges are enforcing order where things were in arbitrary order (e.g., by sorting) & by forcing timestamps to fixed values. It typically requires changes because historically no one tried to make builds reproducible, but it's doable.

I recommend that verified reproducible builds. It's fine if they're added as a new SLSA level (say, "level 4").

SLSA implicitly prefers provenance attestations instead of carefully configured ACLs. We should explain why. Something like:

Theoretically one could configure ACLs properly such that a CI/CD system only pulls from the proper source, signing keys to only allow access to the CI/CD system, etc. In practice, that is almost impossible to get right and keep right. There are often over-provisioning, or confused deputy problems, or mistakes.

For these reasons, we prefer attestations of the properties we want to verify.

Isolation and Hermeticity are very similar. They should be next to each other so they're easier to contrast.

The words "resource" and "artifact" are only briefly explained at the beginning of the "Terminology" section & they aren't clear at all.

These need rigorous definitions AND specific examples (explaining why they meet those definitions).

Attempting to follow either of the links to the PDF of "Building Secure and Reliable Systems" result in 404.

We use the term "SLSA 0" in the doc but never define it.

NOTE: This is a brain dump of ideas. I'm writing it down now so we can track it.

Once we talk about provenance verification (a.k.a. policy), we should introduce a concept of "coverage" that describes what artifacts are covered by SLSA. This applies when there are multiple classes of artifacts present in an environment, such as a runtime environment like Kubernetes. This is orthogonal to level because each class could have a different level.

Starting proposal for runtime environments, based on what we have found useful within Google:

We would suggest prioritizing in the order above. Static binary is the most important and also the easiest to do. Static config is something that is both under the radar (most people don't realize how large of an impact it has) and also not easily "built by a service" as required by SLSA 2. Dynamic artifacts are also important, but they are much harder to verify because it requires cooperation from the workload (or some sort of sandboxing, which is likely infeasible.)

Notes:

• Could also use "startup / runtime" instead of "static / dynamic".
• May want to give some sort of concentric ratings to these as well. Don't want to confuse with levels, so it shouldn't be numeric. A, B, C is probably confusing. Bronze/silver/gold would work but doesn't convey the concept too well.

The "Source integrity" criterion doesn't require source integrity at all, it only requires transport integrity from its distribution point to receipt. It doesn't, in particular, require any kind of digital signature verification. I agree that the criterion belongs here, I just think its name is misleading.

Rename it to "Source transport integrity" or something like that.

Currently the Build Requirements say

All transitive build steps, sources, and dependencies were fully declared up front with immutable references

and

The user-defined build script:

MUST declare all dependencies, including sources and other build steps, using immutable references in a format that the build service understands.

Is it actually necessary that the build script specify the immutable references? That would require users to manually update each build script for each dependency in order to get the latest version. Would it instead be reasonable to simply require that the builder resolve the dependency into an immutable reference and include that in the provenance?

If we actually want users to specify the exact reference they want pulled, could that be a separate ('Version Pinning'?) requirement? That might add some clarity.

This is definitely a preference thing, but I find markdown easier to work with and diff when we wrap at sentences instead of characters. See the OCI style guide for an example: https://github.com/opencontainers/image-spec#markdown-style

Any opposition to switching to this from the current 80 char convention?

(Upfront disclosure: I'm an engineer at Microsoft who is starting to look into supply chain security and I'm reaching out with some of my personal thoughts and opinions; I am not representing Microsoft as a whole).

Resources as friendly, non-content-based identifiers are assumed mutable. This tells me that what artifact a resource links to could change over time. Furthermore, I assume there may be multiple resources that point to the same artifact. For instance, the alpine image on Docker Hub currently has tags 3.13.5, 3.13, 3 and latest that all point to the same underlying image sha.

In the curlimages/curl example provided it looks like the build information (and thus attestation) is tied to the artifact via the resource, but if the resource changes which artifact it points to, the attestation would no longer be valid.

Would it make sense for builds to link directly to artifacts and pull resources out to the side as independent, friendly identifiers of artifacts (that can be updated over time)? Or was this the intent and I'm reading too much into what the implied model is from the diagram?

I appreciate the great work done here so far!

I don't see digital signature verification.

Was that what was intended by "Provenance chain"? It's not clear. I think "Provenance chain" needs clarification so that people will know what is an acceptable way to achieve this. For example, it should be clear whether or not "provenance chain" requires verification of digital signatures. More generally, it should be clear if digital signatures are expected somewhere or not.

As you well know there are many problems today in verifying digital signatures, so I understand if you don't want to require them today. That said, I think at least referring to sigstore in the "related work" section would be a good idea.

When a set of levels (e.g. SLSA) are freshly defined / developed, we could enjoy some nice properties, such as the requirements of each level on different components are carefully aligned so that the security (i.e. difficulty to attack) of each component on the same level are balanced.

But after the levels are published and adopted, we could discover new attacks on certain previously uncovered aspects of some components with varying difficulties. And a low-bar attack would wreck havoc on the existing levels:

• To defend the attack, we need to add new requirements on affected components;
• The problem is where do we add them:
  • If we add to existing level definitions, we have a problem of "run-away target" - customers working towards qualifying a level finding their goal post is moving further;
  • If we create a higher level and add to there, the problem is that this effectively squashes previous levels from the security value point of view. Because the attackers always will aim at the easiest target, if we only start to defend a low-bar attack at level X, then many if not all the previous X-1 levels wouldn't make much difference.
    • "We have 5 levels of escort services for your money, with increasing protection coverage, but for level 1~4 someone wearing a blue hat with pink slippers can take anything, which level would you choose?"

Within section "Hermeticity and two-person review" https://github.com/slsa-framework/slsa/blob/main/walkthrough.md?plain=1#L145

"Once these controls are enabled, the Docker image will be SLSA 3."

Should this read "Once these controls are enabled, the Docker image will be SLSA 4."?

Thank you.