Hacker News new | past | comments | ask | show | jobs | submit login
A toolbox for a secure software supply chain (chainguard.dev)
45 points by ghuntley on Aug 26, 2022 | hide | past | favorite | 7 comments



I really dislike how overloaded the term "supply chain" is.

I recently saw a "supply chain attack" on a Web3 company[0] and it turned out it was a contractor pushing malicious code.

I've worked on "code provenance" professionally before[1] which is, apparently, a subset of "supply chain security". Specifically, I worked to help make sure that the code a dev committed was signed by their laptop, up through the CI, through the vuln scanners, and then the artifacts were verified before being deployed.

It was a lot of work and it is it's own entire field (which is what the OP article is talking about).

But now I'm also working on supply chain security[2] because I'm building tech to scan for vulns in dependencies (like NPM) by blocking known malicious packages or just enforcing security policies based on known vulns in them.

How they are all bucketed under the same term, I don't know, and it hurts my soul. We need some better terms for this stuff.

Anybody have any ideas?

0: https://ambcrypto.com/exec-issues-fbi-warning-as-sushiswaps-...

1: https://medium.com/uber-security-privacy/code-provenance-app...

2: https://github.com/lunasec-io/lunasec


I disagree. All the examples you mention are part of the software supply chain.

To me it doesn't matter if code comes in through a vendor, a dependency or is written in house.

It's all well within the responsibility of the organization owning and deploying the artifacts.


The supply chain is a chain because it is like a relay race, information passes from person/organization/custodian and then to another. Unless they all cooperate in keeping the bureaucracy correct then there is no security, it can also be undermined while the information is in the of custody the traitor.

While you can benefit from being a traitor then there is no way to secure any supply chain.

We need a new economics if we want to solve the tragedy of the commons (in this case w.r.t. bureaucracy).


There is certainly a lot of value to provide a system that is easy to use for developers from commits to the distribution. There does not seem to be a simple solution to do that.


Def check out the gitsign project mentioned in the post: https://github.com/sigstore/gitsign


Supply chain attack is a trust issue. I don't know what these tools do but if it's software then there is one more link you must trust in supply chain.

Solution is to go the other way , you don't bloat your software with too many dependencies. That way you minimize your attack surface.


Yes, it's about trust.

But what aspects? Is it just "I trust that and there's not much there, ok we're secure?" It's a little more complicated.

The stuff in the article is about leaving audit trails to verifiable identities taking known actions. To quote Ronald Reagan, tongue in cheek, "trust but verify."




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: