Need mitigation for Compromise package repo threat

[sergiomarotco]

For example:

React to:

1. suspicious artifacts in the artifact repository;
2. suspicious actions with artifacts;
3. information from the Internet about the compromise of the package used in the company;
4. detection of signatures of static code analyzers for the presence of backdoors and SCA;
5. deviation of the behavior of the application from the expected; take action to...

[ThomasOwens]

What type of package repository is this? It's pretty broad.

If the package repository is a public (or otherwise externally controlled) repository, then a mitigation would be for the developing organization to stand up their own package repository, control what packages are put into it, and control access to the repository. This also shifts the threat to the second kind - a private, internally controlled repository.

If it's a private internally controlled repository, it seems like the risk is someone introducing a malicious package by adding or changing the artifacts that are available to the developers pulling from it. Limiting who has that access, ensuring that all actions are audit trailed, and that notifications of modifications (to both settings - to mitigate someone changing access control rules or notification rules - as well as stored packages) to other people for review and confirm.

I'd also point to vendor management for the package repository vendor (especially for SaaS private repositories), keeping the package repository software up-to-date to mitigate security vulnerabilities in the repository management tools themselves (for self-hosted private repositories), and limiting the access to the repository and infrastructure. Anti-malware on the repositories along with static analysis of any source files for packages would help, too.

[david-a-wheeler]

If the package repository is a public (or otherwise externally controlled) repository, then a mitigation would be for the developing organization to stand up their own package repository, control what packages are put into it, and control access to the repository. This also shifts the threat to the second kind - a private, internally controlled repository.

Many private repos mirror selected packages from a public repo (e.g., "these are the packages I trust, and I'm mirroring them to ensure they're available). So in many cases that isn't enough.

Subverted repos are indeed a thing, it's happened many times.

Other countermeasures include:

• Require signing by developers before sending to repo - now the repo doesn't have the private keys necessary to forge the package.
• External signing of the packages. The package repo has the packages, but not the keys necessary for signing the packages.
• In general, separating writing of the packages from their distribution. Harder to subvert a read-only repo.
• Reproducible builds. If they're verified, then you have to subvert the source code (not just the compiled objects).

I'm sure there are others. Perhaps listing countermeasures will help create a more refined understanding of the threat.

[MarkLodato]

I suggest that we make a decision for v1.0 whether SLSA covers this threat or not.

• If so, we need to define it for v1.0.
• If not, I think it's OK to defer to after v1.0.

[kpk47]

This issue was addressed as part of SLSA v1.0. The threat is consider out of scope.