-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Brainstorm ideas on how to improve "Principles for Package Repository Security" from CISA OSS Summit #40
Comments
Here's my notes from the summit:
|
Here are some notes I took that overlap with some topics already mentioned:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thank you SO MUCH for your work on the "Principles for Package Repository Security".
Today several of us brainstormed about ways to possible improve it, as part of the CISA OSS Summit. Below are notes on our ideas. These are not gospel, they are notes from a brief discussion. Still, I hope that they'll be useful.
--- David A. Wheeler
=======
We answer this as consumers of package repos, as the individuals in this group aren’t maintainers of one.
Many repos, e.g., CRAN, would probably like to comply with many of these, but they have no resources to do so. Need to find a way to resource them to implement these changes, as well as funding to improve sustainment.
A related issue: All of the repo groups are struggling to prioritize of this work vs. other work they need to do.
Is there a staff to support? Most repos don’t have 10 people staffed, which is often the number for supporting major infrastructure services. Especially to maintain MFA, keeping things operational.
What about namespacing? That seems to be missing here. Attacks on namespace are a big issue. Biggest problems are typosquatting & dependency confusion, need to counter.
A big problem is visibility. Repos don’t know how many people are affected by certain attacks.
These requirements are too specific. It would be better if it first identified the general goal (what are you trying to accomplish). Talk about outcomes first, then use these as examples of how to achieve the outcome. The SSDF is an example of this more general approach. Maybe even investigate making this a “projection” of the SSDF.
Need to find a way to triage across the space.
EFF did a great job on the TLS “Wall of Shame” to measure things - it’s important to make how well package repos implement various requirements. Create a “Scorecard” for common understanding of how repos are doing. We really don’t want to shame people, the goal is to help people understand situation.
Organizations trust CLI tools to do things, e.g., bring in software without being vulnerable to dependency confusion or typosquatting. Needs to be easy to say “don’t download THIS”.
In many package repos, you can’t confirm that the pre-built packages are related to the claimed source code, making it easy to insert malicious code. Mechanisms like “building separately” (Go, Homebrew) or verifying reproducible builds could eliminate one vulnerability.
Maven & npm are commercial. PHP is muddly. Everyone else is non-commercial & has little in the way the way of resources.
Need Resources:
Money
Skilled people
Community.
Connecting with other people who are working on similar problems is very helpful.
Publishers of individual projects and consumers of projects will push back. There’s a community of users who don’t want changes. Having a third party that publishes “what you should do” is really helpful, we need to get to a point where these principles are refined further & widely agreed on.
It needs to be EASY for publishers & consumers. This means the repos will need to do work.
Needs to be added: operational resiliency.
CDN risks aren’t identified here! Many depend on Fastly & one-year contracts, that contract goes away & service disappears. (Fastly is moving to 5-year contracts thankfully!)
What do you do with private keys & how are they shared?
There’s the repo itself. But there’s also the security of the build process to generate the CLI & repo components.
There should be a secure-by-default manner for packages. Make it easy to do the safe thing. E.g., you’d have to work to NOT pin, you’d have to work to have dependency confusion, etc.
Need to secure build & operational infrastructure of package repo. None of these points matter if the build or operational infrastructure are not resilient / insecure. The repo needs to be at least as secure as its most secure component. The current principles list focuses on security functionality.
Perhaps report “average libyears” in CLI, track at repo.
We’d encourage every ecosystem to learn about how their community feels about these changes before rolling them out. Platonic ideal isn’t enough, and priorities might vary.
The text was updated successfully, but these errors were encountered: