ossf / wg-securing-software-repos

OpenSSF Working Group on Securing Software Repositories
Other
84 stars 15 forks source link

Start v0.2 of Principles for Package Repository Security #38

Open steiza opened 5 months ago

steiza commented 5 months ago

This is where we can collect feedback from the v0.1 release, as well as pick up feedback we didn't get to in https://github.com/ossf/wg-securing-software-repos/pull/37.

gmollett commented 5 months ago

Something I see missing is around the closely linked subjects of package integrity and non-repudiation. I think these are important things to consider in any package management ecosystem maturity rating. I'll take a quick stab at an idea of the levels here, but it's probably a worthwhile topic for discussion rather than taking these verbatim:

Level 1: Basic integrity verification is done at the package level via simple manually verifiable checksums. Authenticity of the repository is established via standard transport layer mechanisms (SSL/TLS etc..)

Level 2: Integrity verification is done automatically at the package level. Both authenticity of the repo meta-data and packages is verified via cryptographic signatures at install or query time.

Level 3: Integrity verification is possible at the individual file/component level both at install and query time, as well as offline at a given point in future post-installation to detect changes. Both authenticity of repo meta-data and packages can be verified via cryptographic signatures, at install or query time or offline. Identity of signing entity is establish by a 3rd party such as a CA with a verifiable chain of trust.

carols10cents commented 5 months ago

The "Authorization" section says:

Authorization

Applies to: package repositories that have user accounts and accept built packages.

but I'm not sure that this section only applies to repositories that accept built packages, unless I'm misunderstanding something.

Crates.io accepts source code, not built packages, but we definitely have API tokens for publishing that code, the tokens can have different permissions associated with them, and we integrate with GitHub's secret scanning. Perhaps this should say "Applies to: package repositories that have user accounts with associated API tokens, especially if the repository accepts built packages" or similar?

carols10cents commented 5 months ago

General Capabilities Level 1 has this guideline:

  • The package repository has published a vulnerability disclosure policy allowing security researchers to identify and report vulnerabilities affecting the package repository, and receive legal safe harbor when doing so within the requirements of the policy. The package repository should strive to remediate reported vulnerabilities within 90 days.

which is for the security policy of the package registry itself. The registry could also be surfacing information in its UI about the security/vulnerability policy of each package. For example, this issue is where we're discussing possible improvements to crates.io's UI to display security information about each package. I think this would be a useful guideline to add, perhaps in Level 2 as it feels similar to "The package repository warns of known security vulnerabilities in dependencies in the package repository UI" to me?

gtewallace commented 4 months ago

Thank you to the authors for putting this set of Principles out!

An aspect of package security that I did not see, but may have missed, relates to containing, and protecting users from, malware or malicious/rogue code that makes it through. Here's how the FreeBSD package management system does it. (All of this is BSD licensed so, with porting, should be replicable by others.)

phatgeek commented 4 months ago

Something I see missing is around the closely linked subjects of package integrity and non-repudiation. I think these are important things to consider in any package management ecosystem maturity rating. I'll take a quick stab at an idea of the levels here, but it's probably a worthwhile topic for discussion rather than taking these verbatim:

Level 1: Basic integrity verification is done at the package level via simple manually verifiable checksums. Authenticity of the repository is established via standard transport layer mechanisms (SSL/TLS etc..)

Level 2: Integrity verification is done automatically at the package level. Both authenticity of the repo meta-data and packages is verified via cryptographic signatures at install or query time.

Level 3: Integrity verification is possible at the individual file/component level both at install and query time, as well as offline at a given point in future post-installation to detect changes. Both authenticity of repo meta-data and packages can be verified via cryptographic signatures, at install or query time or offline. Identity of signing entity is establish by a 3rd party such as a CA with a verifiable chain of trust.

Wouldn't it be preferable to, at peak maturity, have authenticity and integrity and non-repudiation at the level of individual code check-ins, builds, etc?

di commented 4 months ago

(Note that there is some discussion about this on https://github.com/ossf/wg-securing-software-repos/issues/40 as well)

phatgeek commented 4 months ago

I'm curious about specifying TOTP for authentication, which if I understand correctly is based on shared symmetric secrets. A very sophisticated adversary might make use of this to circumvent authentication (by obtaining and using the database of secrets to impersonate authorized users). Perhaps SMS is in this regard superior, even though it isn't cryptographic. Maybe FIDO2 is a better recommendation? OAUTH2 with TOTP is intended to support delegation, not authentication, per se. Please kindly correct me if I'm mistaken.

di commented 4 months ago

@phatgeek The current version of the doc does recommend WebAuthn (part of FIDO2) as a Level 2 principle:

The package repository supports MFA via phishing-resistant means such as WebAuthn.

The primary motivator here is that TOTP is phishable and WebAuthn is not, but I think the fact that TOTP requires storing secrets, while WebAuthn only requires storing public keys, would be a valid thing to include here as well.

gmollett commented 4 months ago

Something I see missing is around the closely linked subjects of package integrity and non-repudiation. I think these are important things to consider in any package management ecosystem maturity rating. I'll take a quick stab at an idea of the levels here, but it's probably a worthwhile topic for discussion rather than taking these verbatim: Level 1: Basic integrity verification is done at the package level via simple manually verifiable checksums. Authenticity of the repository is established via standard transport layer mechanisms (SSL/TLS etc..) Level 2: Integrity verification is done automatically at the package level. Both authenticity of the repo meta-data and packages is verified via cryptographic signatures at install or query time. Level 3: Integrity verification is possible at the individual file/component level both at install and query time, as well as offline at a given point in future post-installation to detect changes. Both authenticity of repo meta-data and packages can be verified via cryptographic signatures, at install or query time or offline. Identity of signing entity is establish by a 3rd party such as a CA with a verifiable chain of trust.

Wouldn't it be preferable to, at peak maturity, have authenticity and integrity and non-repudiation at the level of individual code check-ins, builds, etc?

You want both imo. They are related but different things.

phatgeek commented 4 months ago

Something I see missing is around the closely linked subjects of package integrity and non-repudiation. I think these are important things to consider in any package management ecosystem maturity rating. I'll take a quick stab at an idea of the levels here, but it's probably a worthwhile topic for discussion rather than taking these verbatim: Level 1: Basic integrity verification is done at the package level via simple manually verifiable checksums. Authenticity of the repository is established via standard transport layer mechanisms (SSL/TLS etc..) Level 2: Integrity verification is done automatically at the package level. Both authenticity of the repo meta-data and packages is verified via cryptographic signatures at install or query time. Level 3: Integrity verification is possible at the individual file/component level both at install and query time, as well as offline at a given point in future post-installation to detect changes. Both authenticity of repo meta-data and packages can be verified via cryptographic signatures, at install or query time or offline. Identity of signing entity is establish by a 3rd party such as a CA with a verifiable chain of trust.

Wouldn't it be preferable to, at peak maturity, have authenticity and integrity and non-repudiation at the level of individual code check-ins, builds, etc?

You want both imo. They are related but different things.

Yes. I see how what I said was ambiguous. I completely agree with you. But transparency in package management often whitewashes the opacity of identities and veracity of code contributions.

So we need to create accountability and transparency in both the code contributions (think gitops) and package management. Getting a Red Hat package that is signed by Red Hat seems great until you think about whether they pulled in their Rust crates with cargo (or their Python with PIP, or their JS with NPM, base container from Docker Hub,...) I want to know exactly where my code came from, and who submitted it, who they are, where they live, who they work for, and what they think about Travis Kelsey.