wg-securing-software-repos
wg-securing-software-repos copied to clipboard
Produce whitepaper of recommendations for securing package repositories
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
- revocation policies
- encouragin best practices
- static/dynamic analysis
- malware scanning: DataDog/guarddog; benchmark; does it help?; https://github.com/ossf/wg-securing-software-repos/issues/8
- secret scanning (GitHub, GitLab)
- reporting APIs
- security auditing
- for packages (attestations?)
- for the repository itself
- package namespacing
- dependency confusion
- package signing/attestations
- https://github.com/ossf/wg-securing-software-repos/issues/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
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.
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 :-).
The simplest threat model: just assume an entire software repo can be (temporarily) taken over. The rest are details.
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.
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.
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.
We've started organizing this content on Package Manager Security Roadmap
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.