11–20 of 31 posts
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…
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…
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.
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] https://theupdateframework.io/ [2] https://in-toto.io/ [3] https://www.youtube.com/watch?v=9hCiHr1f0zM [4] https://dtdg.co/integrations-tuf-in-toto
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.
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.
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 T…
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 T…
How this compares with https://github.com/theupdateframework/notary ?
Asset Transparency doesn't require the publisher to be involved at all and can work on any URL on the internet that is publicly accessible. It also complementary to signing schemes.
Here is the Asset Transparency CLI fetching and verifying the contents of a notary release for example:
tl get https://github.com/theupdateframework/notary/releases/download/v0.6.1/notary-Linux-amd64
curl http://beta-asset.transparencylog.net/lookup/github.com/theupdateframework/notary/releases/download/v0.6.1/notary-Linux-amd64https://www.wired.com/story/inside-the-unnerving-supply-chai...
Something like Bleachbit seems more reputable, but not necessarily immune from similar attacks, but it's what I use instead of CCleaner.
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.