Software supply chain security

83 点作者 mayakacz超过 4 年前

11 条评论

westurner超过 4 年前

Estimates 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?" <a href="https://github.com/theupdateframework/specification/issues/110" rel="nofollow">https://github.com/theupdateframework/specification/issues/1...</a>

评论 #24371406 未加载

评论 #24371442 未加载

评论 #24373094 未加载

trishankdatadog超过 4 年前

Don'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] <a href="https://theupdateframework.io/" rel="nofollow">https://theupdateframework.io/</a>[2] <a href="https://in-toto.io/" rel="nofollow">https://in-toto.io/</a>[3] <a href="https://www.youtube.com/watch?v=9hCiHr1f0zM" rel="nofollow">https://www.youtube.com/watch?v=9hCiHr1f0zM</a>[4] <a href="https://dtdg.co/integrations-tuf-in-toto" rel="nofollow">https://dtdg.co/integrations-tuf-in-toto</a>

评论 #24373371 未加载

philips超过 4 年前

I 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.<a href="https://www.transparencylog.com" rel="nofollow">https://www.transparencylog.com</a>We have started to build tools for integrating into release pipelines too:<a href="https://www.transparencylog.com/software-release-process-integration/" rel="nofollow">https://www.transparencylog.com/software-release-process-int...</a>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:<a href="https://github.com/transparencylog/tl" rel="nofollow">https://github.com/transparencylog/tl</a>

评论 #24374205 未加载

brobdingnagians超过 4 年前

By default, have your firewall block _all_ outward connections. Only whitelist the ones you know you need. And as narrow as possible (i.e. specific hosts).Minimize the number of dependencies. Systems that make it hard to add dependencies have the virtue of thinking harder about whether you want to add them. Having a few central libraries that do exactly what you need is better than drawing in the kitchen sink.It is often easier to write a specific function that does precisely what you need than people think.That is easier to change, and easier to maintain in the long run, than ingesting a huge library with its dependencies that do things you will probably never need.

snicker7超过 4 年前

Related: GNU Guix [0] and Bootstrappable Builds [1]. Guix tries to reproducibly bootstrap an entire Linux distribution from a ever-shrinking binary seed.[0]: <a href="https://guix.gnu.org/" rel="nofollow">https://guix.gnu.org/</a>[1]: <a href="https://bootstrappable.org/" rel="nofollow">https://bootstrappable.org/</a>

pornel超过 4 年前

I'm a proponent of distributed code reviews as a solution: <a href="https://github.com/crev-dev/crev" rel="nofollow">https://github.com/crev-dev/crev</a>Ultimately, someone has to manually review the code. Antivirus-like heuristics won't catch everything. Sandboxing may prevent some exfiltration, but can't prevent malicious code from returning malicious results (e.g. imagine a password checking library modified to always accept attacker's password - it can be sandboxed like a nuclear reactor and still screw you). If you verify the code is actually safe and does what it says, then it doesn't matter where the code came from, who wrote it, which CI server published it.But reviewing code is tedious. It's wasteful for every user to individually review the same code over and over again. You can trust code if enough people who you trust have reviewed it.

holri超过 4 年前

Just 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.

评论 #24372796 未加载

Tainnor超过 4 年前

Maybe we need some sort of "trust model" for dependencies. E.g. if you depend on a package, you'll have to explicitly state that you trust it. Conversely, a package author may declare that not only are they responsible for their own code, they have also either only used trusted dependencies, or declare their own trust (e.g. by review) of certain dependencies, so that you can transitively build up a trust chain...In practice, that would all be much more difficult, of course. But it would surface the underlying issue which is that while code reuse is fine and acceptable, using unvetted code is not.

katsume3超过 4 年前

And more reading on this matter, relevant to CCleaner's supply chain mishap:<a href="https://www.wired.com/story/inside-the-unnerving-supply-chain-attack-that-corrupted-ccleaner/" rel="nofollow">https://www.wired.com/story/inside-the-unnerving-supply-chai...</a>Something like Bleachbit seems more reputable, but not necessarily immune from similar attacks, but it's what I use instead of CCleaner.

评论 #24376031 未加载

评论 #24375697 未加载

marcus_holmes超过 4 年前

I'm glad this is beginning to be taken seriously. And that the answer isn't "sandbox every dependency" which is ridiculous.

评论 #24375608 未加载

trabant00超过 4 年前

Please 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.