Missing Threat: Revoked Dependency

[ThomasOwens]

I've been reviewing the SLSA documentation and it seems like there is a missing dependency threat: an instance where the authorized maintainer of a dependency destroys the dependency. This could be pulling the dependency from public repositories or updating the version to remove the functionality (especially when versioned as a patch).

This isn't quite like some of the other identified threats. For example, it's not "submit bad code to the source repository" since that threat describes outside contributors submitting changes into the review process with the intention of evading detection or "use bad dependency" since the dependency was (theoretically) well-vetted and accepted.

An example of this would be left-pad.

[msuozzo]

I believe the documented threats are more oriented towards cases where the attacker can gain code execution and not, as in this case, where they can DoS a build. It is certainly a threat in the general sense but perhaps less concerning from an information security perspective.

[ThomasOwens]

I believe the documented threats are more oriented towards cases where the attacker can gain code execution and not, as in this case, where they can DoS a build. It is certainly a threat in the general sense but perhaps less concerning from an information security perspective.

This is a valid point. It's not clear to me - even with reading the homepage and Introduction and some of the other pages - what the scope of SLSA is. There's talk of "artifact integrity" and "secure packages and infrastructure" but not the scope.

I will say, though, that the inability to build a system can indirectly lead to security issues. When you rely on public repositories, you rely on them for all your builds. Consider a security issue, like log4j, coupled with a dependency author who yanked a key dependency. You may struggle to build your patched system. But even so, if the focus is on direct attacks to systems rather than impeding or slowing down the development or deployment of systems, this would be out-of-scope.

If this threat is out-of-scope, then I'd like to see a better definition of the scope of SLSA so people know what the limitations are and that there may be classes of supply chain vulnerabilities that would not be addressed even at the highest levels.

[MarkLodato]

Thanks, @ThomasOwens!

I agree that we should add this to the threats page, presumably under the "dependencies" category. I would like that page to model all supply chain threats, whether in-scope or out-of-scope. Care to send a PR?

For the current version (v0.1), I'd call this "out of scope" since none of the requirements address this this threat. Do you agree?

For future versions, it is a good question whether SLSA should address this by adding a new requirement. Note that there is also #276 of how SLSA fits into the broader supply chain security picture. But even if we just consider the current scope, this seems to fall within "availability" which we already somewhat address with the "sources retained" piece. Any thoughts on what kind of requirement would address this, and where it should go in the ladder?

[ThomasOwens]

@MarkLodato

I'm not sure that it is out of scope. The requirements for "Hermetic" may address this, although the bit about "prevent network access while running the build steps" is a bit unusual. It does say that is a "best effort" requirement, though.

The common way I've addressed this threat model is for the organization to use a controlled repository. Sometimes, the organization may choose to self-host their repository within their internal network (either in their own data center or within their own VPC on a public cloud) and apply the appropriate security controls. This would satisfy the requirement to "fetch all artifacts in a trusted control plane", though. I'm not sure I'd consider public artifact repositories to be trusted, especially when the author can revoke packages or publish destructive content as a patch version. This solution also gets an organization a step closer to satisfying the "Reproducible" requirement.

I will point out, though, that there are some services that allow for an organization to stand up an artifact repository in the cloud. This approach may be more suitable, especially to let teams focus on their core business functions rather than supplemental or supporting work. Going to cloud services for things like code hosting, build servers, and artifact repositories could be a good idea.

Do you agree with this assessment?

I'll also get set up and open a pull request in the very near future to address this.

[MarkLodato]

I agree that what you suggest is as good idea and that perhaps it should be a new requirement for the next version, but I don't think anyone is interpreting the "Hermetic" requirement in that way. It was not the intention to require mirroring of all inputs. That is why I suggested that we call it "out of scope" for v0.1. Again, not that it's a bad idea, just that it was not considered for v0.1.

[ThomasOwens]

@MarkLodato Makes sense. I did think it was a little bit of a stretch. Out-of-scope but perhaps not far out-of-scope. I'll still go forward with that pull request in the next couple of days, for sure. Thanks.

[ThomasOwens]

@MarkLodato I've opened a pull-request that includes the partial changes. It felt more appropriate to add it how I did, rather than to the "things that don't fit well in current picture", but I would be open to changing if it was appropriate. If the current approach is good, I can look at editing the SVG to add I to the diagram.

[david-a-wheeler]

I think we definitely need to note this threat, in particular because there are different countermeasures for it (caching the information and/or having a repo's policy prevent removal after some period of time).

[ThomasOwens]

This was resolved in #347