Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Pragmatic way to avoid supply chain attacks as a developer

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 23 posts

Ask HN: Pragmatic way to avoid supply chain attacks as a developer

#1

Post by RoboTeddy »

In the usual course of writing software, it's common to install huge dependency chains (npm, pypi), and any vulnerable package could spell doom. There's some nasty stuff out there, like https://pytorch.org/blog/compromised-nightly-dependency/ which uploaded people's SSH keys to the attacker.

It's easy to say just "use containers" or "use VMs" — but are there pragmatic workflows for doing these things that don't suffer from too many performance problems or general pain/inconvenience?

Are containers the way to go, or VMs? Which virtualization software? Is it best to use one isolated environment per project no matter how small, or for convenience's sake have a grab-bag VM that contains many projects all of which are low value?

Theorycrafting is welcome, but am particularly interested in hearing from anyone who has made this work well in practice.

Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer

#4

Post by comprev »

A large portion of my role at $DayJob is around improving supply chain security.

Some examples of how we do it:

- Devs can only use hardened (by us) Docker images hosted inside our infrastructure. Policies enforce this during CI and runtime on clusters.

- All Maven/PIP/NodeJS/etc. dependencies are pulled through via proxy and scanned before first use. All future CI jobs pull from this internal cache.

- Only a handful of CI runners have outbound connectivity to the public internet (via firewalls). These runners have specific tags for jobs needing connectivity. All other runners pull dependencies / push artefacts from within our network.

- The CI Runners with Internet connectivity have domains whitelisted at the firewall level, and so far very few requests have been made to add new domains.

- External assets, e.g an OpenJDK artefact, have their checksums validated during the build stage of our base images. This checksum is included in Docker image metadata should we wish to download the asset again and compare against the public one.

Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer

#5

Post by mikewarot »

The root cause of many of our woes is ambient authority. This is the metaphorical equivalent of building an electrical grid without fuses or circuit breakers.

You have to trust everything, and any breach of trust breaks it all. This approach is insane, and yet, widely accepted as the way things were always done, and will always be done.

If you ever get the chance to use capability based security, otherwise known as the principle of least privilege, or multilevel security, do so.

Know that permission flags in Android, or the UAC crap in Windows, or AppArmor are NOT capability based security.

Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer

#8

Post by h4ck_th3_pl4n3t »

CycloneDX tools offer packages for each and every programming language. [1]

The dependency track project accumulates all dependency vulnerabilities in a dashboard. [2]

Container SBOMs can be generated with syft and grype [3] [4]

[1] https://github.com/CycloneDX

[2] https://github.com/DependencyTrack

[3] https://github.com/anchore/syft

[4] https://github.com/anchore/grype

Re: Ask HN: Pragmatic way to avoid supply chain attacks as a developer

#10

Post by boricj »

h4ck_th3_pl4n3t wrote: post #8

CycloneDX tools offer packages for each and every programming language. [1] The dependency track project accumulates all dependency vulnerabilities in a dashboard. [2] Container SBOMs can be generated with syft and grype [3] [4] [1] https://github.com/CycloneDX [2] https://github.com/DependencyTrack [3] https://github.com/anchore/syft [4] https://github.com/anchore/grype

SBOMs can't flag vulnerable dependencies until after those are publicly known. Traceability is useful when mitigating a crisis, but it won't prevent one.
Post reply on HN