content: Update mitigation section for the Dependency Confusion threat. #1226
Conversation
Signed-off-by: Meder Kydyraliev <1212257+meder@users.noreply.github.com>
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
meder
changed the title
Signed-off-by: Meder Kydyraliev <1212257+meder@users.noreply.github.com>
| packages on a SLSA Level 2+ compliant build system and define expectations for | ||
| build provenance. Expectations must be verified on installation of the internal | ||
| packages. If a misconfigured victim attempts to install attacker's package with |
There was a problem hiding this comment.
Do we need to be more precise about what we mean by "define expectations for build provenance" here? It is not clear to me what expectations we are verifying.
Also, if we are doing verifications on the provenance, that is after the build, right? If so, it doesn't really follow for me to verify on installation. Are you trying to say that we must verify that internal packages are installed/used and not some untrusted external one?
There was a problem hiding this comment.
Checking 'expectations' is commonly used terminology on this page. The other threats mention it without further explanation. The explanation about how to do so is in https://slsa.dev/spec/v1.1/verifying-artifacts#step-2-check-expectations.
There was a problem hiding this comment.
re: the last question: yes.
| @@ -775,9 +775,18 @@ The consumer requests a package that it did not intend. | |||
| on the victim's internal registry, and wait for a misconfigured victim to fetch | |||
| from the public registry instead of the internal one. | |||
|
|
|||
| **TODO:** fill out the rest of this section | |||
| *Mitigation:* The mitigation is for the software producer to build internal | |||
There was a problem hiding this comment.
optional: Would we prefer to say that SLSA doesn't currently address this threat but that a future tracks plans to (insert relevant links)?
One reason we might prefer not to address this threat as written is that not all methods of forming expectations will address it. E.g. in 'verifying-artifacts' it talks about forming expectations and the first thing listed is TOFU. In the TOFU model this threat isn't addressed, we'd just wind up anchoring on the malicious package's provenance values. 'Defined in source' has a similar problems in that the package name is bound to a source repo, if the wrong name is requested then the malicious expectations will be pulled instead.
The only way of forming expectations that works here is "Defined by producer", but it's not clear how those expectations are communicated. You could imagine a similar one called 'defined by organization' where the org sets a policy that says "unless you get an exception for a package it must come from builds A, B, C and source repos X, Y, Z".
There was a problem hiding this comment.
Given that this threat is very specifically about a public package shadowing a name from the internal registry, it would still be possible to enforce expectations on the internal-only packages at least since the producer and consumer is the same entity, I think? In other words, set expectations for package foo (known internal) in resolvedDependencies but not package bar which is fine to pull in from the external registry.
Separately, this might need a higher level of completeness in build provenance than is currently typical. For example, looking at NPM's use of provenance, resolvedDependencies doesn't record all the packages that are actually resolved but rather just the git revision. Should this be called out?
There was a problem hiding this comment.
Given that this threat is very specifically about a public package shadowing a name from the internal registry, it would still be possible to enforce expectations on the internal-only packages at least since the producer and consumer is the same entity, I think? In other words, set expectations for package foo (known internal) in resolvedDependencies but not package bar which is fine to pull in from the external registry.
Right, that's a better way of describing what I was trying to get at with expectations that are set by the organization.
Separately, this might need a higher level of completeness in build provenance than is currently typical. For example, looking at NPM's use of provenance, resolvedDependencies doesn't record all the packages that are actually resolved but rather just the git revision. Should this be called out?
Not quite sure what you mean? That's all we need to address this threat as the source repo listed there is the 'main' one that drives the build itself (IIUC).
Or perhaps you're suggesting we call this out to the folks that build that NPM provenance because it's not complete? (it doesn't need to be at lower SLSA levels).
There was a problem hiding this comment.
Right, that's a better way of describing what I was trying to get at with expectations that are set by the organization.
My bad, I misread the last bit of that comment. It's the same idea. 😄
Not quite sure what you mean? That's all we need to address this threat as the source repo listed there is the 'main' one that drives the build itself (IIUC).
If the provenance only records a git revision, we don't have sufficient information to enforce the "defined by organization" list for internal dependencies as the packages fetched by the dependency resolver for the manifest at that git revision is unknown.
In other words, in addition to saying SLSA level 2+ builder, maybe this text needs to call out that resolvedDependencies needs to be more complete to enforce the expectations about the organization's internal packages.
There was a problem hiding this comment.
If the provenance only records a git revision, we don't have sufficient information to enforce the "defined by organization" list for internal dependencies as the packages fetched by the dependency resolver for the manifest at that git revision is unknown.
Oooh, I think where we're getting wires crossed is when this is getting checked and at what scope.
My assumption is that here @meder is referring to the provenance of the dependency itself being checked. It sounds like you're thinking about it from the perspective of checking if something build with that dependency uses the bad thing.
Case 1 <--- This is what @meder is saying??
- External package 'foo' shadows internal package 'foo'.
- external-foo's provenance lists a single
resolvedDependencyshowing that it was built fromgit+https://github.com/not-my-org/foo-js@refs/heads/main. - The system that fetches 'foo' (somehow) knows that foo is internal and so it must have provenance that shows it was built from
git+https://github.com/my-orgorgit+https://git.my-org.com.
Case 2 <--- This is what you're saying??
- External package 'foo' shadows internal package 'foo'.
- Internal package 'bar' is built using external-foo.
- bar has a good build that provides complete resolvedDependencies in it's provenance
- When bar is having its provenance checked the verifier can check to see that all packages we expect to be internal (somehow) come from the internal registry.
I think the biggest problem with this approach is actually figuring out which packages are internal and which aren't. Which is why it might be easier to just say "SLSA doesn't handle this now, but the dependency track will".
There was a problem hiding this comment.
Great discussion, thanks all.
Case 1 is indeed what I am describing with the caveat that the producer should be able to easily communicate/distribute the expectations to the consumers as the producer and the organization consuming dependencies are the same entity. The verification can then happen at different points in SDLC: it could happen at the time dependencies are ingested into the internal registry, it could happen on build/installation.
Documenting a SLSA-native and build trackccentric mitigation for Dependency Confusion attacks (#1181)
Would love to hear thoughts/opinions on the best way to reflect differing levels of adoption / maturity in native provenance verification across different ecosystems.