Software supply chain security
github.blog
Software supply chain security
1–10 of 31 posts
Re: Software supply chain security
#2Estimates of prevalence do assume detection. How would we detect that a dependency that was installed a few deployments and reboots ago was compromised?
How does the classic infosec triad (Confidentiality, Integrity, Availability) apply to software supply chain security?
Confidentiality: Presumably we're talking about open source projects; which aren't confidential. Projects may request responsible disclosure in an e.g. security.txt; and vuln reports may be confidential for at least a little while.
Integrity: Secure transport protocols, checksums, and cryptographic code signing are ways to mitigate data integrity risks. GitHub supports SSH, 2FA, and GPG keys. Can all keys in the package signature keyring be used to sign any package? Can we verify a public key over a different channel? When we specify exact versions of software dependencies, can we also record package hashes which the package installer(s) will verify?
Availability: What are the internal and external data, network, and service dependencies for the development and deployment DevSecOps workflows? Can we deploy from local package mirrors? Who is responsible for securing and updating local package mirrors? Are these service dependencies all HA? Does everything in this system also depend upon the load balancer? Does our container registry support e.g. Docker Notary (TUF)? How should we mirror TUF package repos?
See also: "Guidance for [[transparent] proxy cache] partial mirrors?" https://github.com/theupdateframework/specification/issues/1...
Re: Software supply chain security
#3Estimates of prevalence do assume detection. How would we detect that a dependency that was installed a few deployments and reboots ago was compromised? How does the classic infosec triad (Confidentiality, Integrity, Availability) apply to software supply chain security? Confidentiality: Presumably we're talking about open source projects; which aren't confidential. Projects may request responsible disclosure in an e…
A toolset that answers some of your questions is grafeas- a metadata store at https://github.com/grafeas/grafeas- and kritis, a policy engine at https://github.com/grafeas/kritis.
Cheers.
Re: Software supply chain security
#4Estimates of prevalence do assume detection. How would we detect that a dependency that was installed a few deployments and reboots ago was compromised? How does the classic infosec triad (Confidentiality, Integrity, Availability) apply to software supply chain security? Confidentiality: Presumably we're talking about open source projects; which aren't confidential. Projects may request responsible disclosure in an e…
OUTSTANDING comment; excellent questions. Bookmarked. Thanks for this concise high-level infosec punchlist.
Re: Software supply chain security
#5Don't miss how we used TUF [1] and in-toto [2] to build compromise-resilient CI/CD (the first in the industry AFAICT) for the Datadog Agent integrations [3][4] that detects attacks anywhere between our developers and end-users
[1] https://theupdateframework.io/
Re: Software supply chain security
#6I think a big step forward is for folks to pin versions of things. NPM and pip and many other systems let software depend on a semantic versioning of their dependencies which makes it impossible to know what will be installed. If you at least know what is going to be installed and the URL is known then you can rely on a third party notary to tell you the expected contents...
Which is what we are building with Asset Transparency to provide a public transparency log backed database of URL content digests.
https://www.transparencylog.com
We have started to build tools for integrating into release pipelines too:
https://www.transparencylog.com/software-release-process-int...
I think it would be great to see package management systems use things like this. Go already does.
If anyone wants to get started quickly checkout our CLI tool:
Re: Software supply chain security
#7Please stop with the blog spam, upvote astroturfing and "great article/comment!" stuff. I understand you are payed for evangelism but just take it somewhere else.
Re: Software supply chain security
#8Just use software that is in Debian stable.
If a library is not in Debian, then pack it and become a Debian developer and solve that problem for you and thousands of other people that are affected.
Software supply chain is a very old Problem and already solved. No need to reinvent the wheel for each generation of software developers.
Re: Software supply chain security
#9Related: GNU Guix [0] and Bootstrappable Builds [1]. Guix tries to reproducibly bootstrap an entire Linux distribution from a ever-shrinking binary seed.
Re: Software supply chain security
#10Just use software that is in Debian stable. If a library is not in Debian, then pack it and become a Debian developer and solve that problem for you and thousands of other people that are affected. Software supply chain is a very old Problem and already solved. No need to reinvent the wheel for each generation of software developers.
Just run apt install billion-$$$-arr regulated-institution and write a systemd unit file, then run apt upgrade occasionally. What’s the problem?