Add software supply chain security criteria

[JustinCappos]

@SantiagoTorres

I would like to suggest the addition of software supply chain tracking criteria to the CII Badge process. The addition of cryptographically signed and validated steps in the software creation process seems very sensible given the myriad of supply chain attacks.

I propose: 1) requiring written documentation of the software supply chain at the basic badging level.
2) making cryptographic supply chain verification of the build and packaging processes a requirement for the silver badging level 3) requiring all steps of the software supply chain be cryptographically verified as part of the gold badging level, using a system that can securely rotate keys and/or recover from a key compromise.

[david-a-wheeler]

Hi, thanks so much for your feedback!

Let's look at that those thoughts part-by-part:

Part 1: Document Supply chain

If by "written documentation of the supply chain" you mean "sit down and write a Word document", no one will do it and it would be useless anyway. It would probably be obsolete before you finished typing it and no one will read it. The badging criteria at the "passing" level needs to be something that OSS developers generally agree is something that should be done and is widely done. Developers writing 10-line JavaScript programs must be able to reasonably do it, for example. HOWEVER....

If you mean "use a standard package management format for your programming language(s) (if they exist) to record dependencies and allow them to be automatically updated", that is sensible. Once set up, those can be automatically maintained, would actually be used in development, and could be useful downstream. Unfortunately C/C++ don't really have one (people use system package managers), but that would still include JavaScript, Python, Ruby, Rust, and many other ecosystems. We can allow N/A if there is no such system, which is imperfect but still a step forward.

That text would need some refining, but I think that if we approach it that way, it is very doable.

Part 2: Cryptographic verification

I'd love to require that, but there's a fundamental problem: where are the public keys? Some package management systems do support cryptographic verification, but there's no practical way to find the public keys of the developers, so those functions (where they exist) are often unused. If you're getting the software from a repo, you could check its signature, but that's not very different from just using TLS. Either way you're trusting the repo, and if the repo is subverted then so is its private key. There's a small advantage if the repo signing key is offline, but few major ecosystem repos (like PyPI) can have offline keys because they have to be able to automatically sign & deploy updates.

The "best practices" badge levels are all about identifying what you can do now. If you can work with the various package management systems & repos to implement this, then we can add it as a requirement. But it has to be practical before requiring it. If you can show me how it's reasonably practical in all major ecosystems, that would be great!

Part 3: Cryptographic verification of all steps

That looks like in-toto. There's ongoing work to begin deployment of that in special cases. If you can help us get that more widely used, that'd be great, and then we can add it!

[JustinCappos]

On Fri, Feb 26, 2021 at 7:30 AM David A. Wheeler notifications@github.com wrote:

Hi, thanks so much for your feedback!

Sure, happy to iterate and try to be more helpful.

Oops, I think I wasn't very clear here. It's fairly standard procedure to have instructions about how to compile / install the software (usually contained in the project's README). I'm really just proposing that this include a description of the tools used to build and make it in the case where this somehow isn't obvious. I think this is already very common in many ecosystems. E.g., install gcc version X, libA version Y, etc. and then type "make" to build and "make install" to install.

If you mean "use a standard package management format for your programming

language(s) (if they exist) to record dependencies and allow them to be automatically updated", that is sensible. Once set up, those can be automatically maintained, would actually be used in development, and could be useful downstream. Unfortunately C/C++ don't really have one (people use system package managers), but that would still include JavaScript, Python, Ruby, Rust, and many other ecosystems. We can allow N/A if there is no such system, which is imperfect but still a step forward.

That text would need some refining, but I think that if we approach it that way, it is very doable.

I agree that what you suggest would also be helpful!

Part 2: Cryptographic verification

I'd love to require that, but there's a fundamental problem: where are the public keys? Some package management systems do support cryptographic verification, but there's no practical way to find the public keys of the developers, so those functions (where they exist) are often unused. If you're getting the software from a repo, you could check its signature, but that's not very different from just using TLS. Either way you're trusting the repo, and if the repo is subverted then so is its private key. There's a small advantage if the repo signing key is offline, but few major ecosystem repos (like PyPI) can have offline keys because they have to be able to automatically sign & deploy updates.

The "best practices" badge levels are all about identifying what you can do now. If you can work with the various package management systems & repos to implement this, then we can add it as a requirement. But it has to be practical before requiring it. If you can show me how it's reasonably practical in all major ecosystems, that would be great!

Seems like a high hurdle, but we're doing this a bit at a time. Python integrated TUF into Warehouse already (we're pushing for in-toto and a few other security tweaks as we speak to make it easier to do this). We hope others will follow suit, but this will take some time.

Part 3: Cryptographic verification of all steps

That looks like in-toto. There's ongoing work to begin deployment of that in special cases. If you can help us get that more widely used, that'd be great, and then we can add it!

Sure, where do you want to see that usage? We have a few thousand companies using it. Would something like better github integration (as a core feature and available to all) be enough?