Hacker News Reader

Comment by rcarmo | Hacker News Reader

i have a personal take on this, which is that people have yet to realize that pulling new shiny dependencies off GitHub (or entire unaudited container images off Docker Hub) and putting them directly into production is not necessarily a good idea…

View on HN

I mean, it's a speed v. security thing. Every engineer (and I don't mean software engineers here) will tell you this is insane. You can't trust your bricks and yet, you're building a cathedral.

I know that automating stuff to check for CVEs and vulnerabilities of sorts is getting a lot of traction recently, but I don't think this is really sufficient. Who do you trust? Are we going to see some companies creating a "Security Seal of Approval" for packages?

I'm not sure what's the answer here, but certainly it isn't what we have been doing for the last couple years.

You can trust those who depend upon a lifelihood from you.

You can trust who you pay properly.

Who entrust the survival of theire family to your continued existence.

Whos bread i take, whos song i sing.

Thats the supply chain.

Turns out there is no free lunch to be had even in open source.

There are a few companies in this space that are trying to do the "Security Seal of Approval" thing to various degrees.

Tidelift is one company that has a bunch of "catalogs"[0] of packages. I'm not sure how their package metadata is generated though -- maybe semi-manually?

There is also Bytesafe[1] which is supposed to help give you a way to "firewall" yourself from unapproved dependencies. I don't think they sell data though. Just tools.

A company based on the Open Source project, packj[2], is Ossilate[3] which is trying to use automated analysis for analyzing 3rd party packages.

And another that's in this space is Socket.dev[4] which tries to warn you in your PRs about bad packages.

I know about this space because I work on a project[5] that's also related to supply chain security. It's a bit different from all of the above since we're focused on patching known vulns, but the idea of "vetted packages" has crossed my mind before.

Are there any other services in this space that I missed?

0: https://tidelift.com/solutions/catalogs

1: https://bytesafe.dev/

2: https://github.com/ossillate-inc/packj

3: https://ossillate.com/

4: https://socket.dev/

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

This is only insane in the engineering world because actual human lives are depending on the structural integrity of your cathedral.

Even if you face a supply chain attack, the only value lost may be money for most businesses, and not enough that worrying about supply chain attacks is worth it.

Actual human lives depend on software development. Hospitals, Airports, Airplanes, missiles, satellites. If any of these are attacked via supply chain lives will be lost and countries could even collapse if the attack was severe enough.

Almost neither of which use a lot of dependencies.

It's still C and C++ world out there, and everything gets shrink wrapped. It's more likely that you would find a logic bug or a well known security issue in a single library than somehow infest the supply chain of these particular applications.

Every piece of off the shelf software is labelled and audited in that world.

Isn't this what Linux distributions like Red Hat Enterprise Linux are doing? Providing a secure (among other things) platform on which you can build on?

Or people do realise the risk and are balancing the risk of speed of dev with the likelihood of something going wrong (and them being blamed for it). Imperfect systems often produce a lot of value, even if it means playing a game of spinning plates to keep it going. It's very possible that the value produced by this system overshadows the lost value from an ocassional black swan event as a result of the systems failure modes.

At least github supports 2FA, signing of commits, SSO, etc. It can be a lot more trustworthy than a package distro.

Reply on news.ycombinator.com