Produce whitepaper of recommendations for securing package repositories

[znewman01]

This working group has produced a ton of useful information about how best to build a secure package repository, along with data on what repositories are currently doing. Can we crystallize this into an easy-to-digest guide to package repository security for package repository admins/maintainers? Topics would include (by no means complete):

• list of incidents: torchtriton
• guidance on dependency selection: keeping dependency trees trim
  • trust metrics
• revocation policies
• encouragin best practices
  • OSSF Scorecards; do scorecards help?; Sonatype safety rating
• static/dynamic analysis
  • malware scanning: DataDog/guarddog; benchmark; does it help?; IBM Software Fingerprinting for Supply Chain Security Presentation & Feedback #8
  • secret scanning (GitHub, GitLab)
  • reporting APIs
• security auditing
  • for packages (attestations?)
  • for the repository itself
• package namespacing
• dependency confusion
  • Python discussion
• package signing/attestations
  • Produce cryptographic signing guide for package managers #10
  • TUF, in-toto
  • npm/pypi as case studies
  • SLSA: provenance
  • publish attestations, [Docker attestations](
• https://docs.docker.com/build/attestations/)
  • with Sigstore?
  • privacy concerns
• publishing workflows ([PyPI trusted publishers](
• https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/))
  • API token scoping
• account management
  • MFA: SMS vs. TOTP vs. webauthn/passkeys
  • domain squatting attacks
  • password breach detection
  • account recovery
• package manager features
  • lockfiles
  • reproducible builds
• vulnerability scanning
• SBOMs and package manager ecosystems
• surfacing vulnerabilities to users

(There could also be a good research paper "Systematization of Knowledge" here—CC @joshuagl).

CC @woodruffw

Misc references

• meeting minutes
• npm's list of threats and mitigations

[scovetta]

Also to add, Threats, Risks, and Mitigations in the Open Source Ecosystem has a bunch of information on threats, many of which apply to ecosystems.

[david-a-wheeler]

I suggest starting with a list of attacks (or threats) that you (might) want to counter, then show controls against them. Ideally with examples.

A starting point: "Taxonomy of Attacks on Open-Source Software Supply Chains"
https://arxiv.org/abs/2204.04008

S2C2F has a nice list of attacks & then mappings to countermeasures. https://github.com/ossf/s2c2f

For example:

• Package could be deleted from repo by maintainer, leading to build failures worldwide. Example: left-pad.
  • Control: Forbid deletion from repo after XYZ days unless legally required; keep multiple copies.
• Might serve malicious code (intentionally created)
  • Control: Use scanners to detect potentially malicious code, block deployment
• Package maintainer's account subverted, enabling attack to upload subverted package
  • Control: Require MFA for maintainers.

Hopefully that gets the idea across :-).

[trishankatdatadog]

The simplest threat model: just assume an entire software repo can be (temporarily) taken over. The rest are details.

[david-a-wheeler]

The simplest threat model: just assume an entire software repo can be (temporarily) taken over.

Absolutely, I agree that should be in the set.

The rest are details.

I don't agree. There are many attacks that do not involve taking over a whole repo, and they need to be addressed as well. Let's collect all the ones that matter.

[trishankatdatadog]

I don't agree. There are many attacks that do not involve taking over a whole repo, and they need to be addressed as well. Let's collect all the ones that matter.

My point is that they follow from the general assumption of a compromised repo.

[david-a-wheeler]

My point is that they follow from the general assumption of a compromised repo.

Sure! I just wanted to make sure that we also covered other cases where the whole repo wasn't compromised, but there was instead some other kind of problem.

[steiza]

We've started organizing this content on Package Manager Security Roadmap

[steiza]

We released v0.1!

https://repos.openssf.org/principles-for-package-repository-security
https://openssf.org/blog/2024/02/08/openssf-securing-software-repositories-working-group-releases-principles-for-package-repository-security/
https://www.cisa.gov/news-events/alerts/2024/02/08/cisa-partners-openssf-securing-software-repositories-working-group-release-principles-package

For feedback / work on v0.2, see #38.