It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)

Bilal_io 2 hours ago | parent | next [-]

The problem would be the dependencies of your dependencies, and keep going many levels.

▲

nafey an hour ago | parent | next [-]

The problem is that node.js doesn't have a good standard library so one must rely on external packages to build even basic apps.

	▲	skydhash 21 minutes ago \| parent [-]
		Can you tell us what exactly is missing? A network api? Process execution? IO? Math?

▲

pipo234 2 hours ago | parent | prev [-]

But presumably, you only include dependencies that you trust and those dependencies themselves do their trusting more strictly than you. Trust is built on vetting, signatures and reputation.

That is, at least what we do, in theory. In practice, we cross fingers and let the LLM pick dependencies, are satisfied if it just works and we either update our deps frequently or infrequently.

	▲	jruohonen an hour ago \| parent \| next [-]
		> Trust is built on vetting, signatures and reputation. https://news.ycombinator.com/item?id=47017833 Well, now with an irony, but sadly, of course.
	▲	no-name-here an hour ago \| parent \| prev [-]
		Would red hat be considered a trusted/reputable vendor?

▲

Cthulhu_ 2 hours ago | parent | prev | next [-]

Nothing that couldn't be automated; in Go land this is (arguably) called vendoring (https://go.dev/ref/mod#vendoring). Good to offload or reduce dependencies on 3rd party dependency hosters, pull a dependency into your own code review tools, and to ensure reproducible builds long term.

	▲	Izkata 2 hours ago \| parent \| next [-]
		It's a generic and very old term for committing dependencies to your repo, it's not go-specific.
	▲	gbuk2013 2 hours ago \| parent \| prev [-]
		I mean there’s nothing stopping you from committing node_modules to git (after running something like https://github.com/timoxley/cruft on it) and reviewing code changes on dependency updates. I even managed to make that part of the workflow on one team I worked with but several other teams since thought it was a crazy idea. :)

▲

repelsteeltje an hour ago | parent | prev | next [-]

That might change the odds, but unless you fork diligently (and monkeypatch each and every future vulnerability) you might ship a compromised fork forever.

▲

olejorgenb an hour ago | parent [-]

Except most of the attacks so far has not landed actually source code changes to git IIRC. They have targeting the release files directly.

	▲	lights0123 an hour ago \| parent [-]
		Software vulnerabilities are often not placed maliciously, and are present in the original source. If you don't patch them if discovered later, you'll be vulnerable to them.

▲

whynotmaybe 30 minutes ago | parent | prev | next [-]

Shouldn't you also restrict version number for a package not just the latest?

▲

paulddraper an hour ago | parent | prev | next [-]

The problem is the volume of dependencies. Most modern JavaScript, Python, Rust, Go, etc. projects have many dozens of transitive dependencies.

▲

marcosdumay 37 minutes ago | parent | next [-]

Hum... You should check your JavaScript numbers again.

I have never seen a project that uses npm and has only dozens of dependencies. Normal numbers are in the 10s of thousands (including different versions of some deps).

	▲	19 minutes ago \| parent [-]
		[deleted]

▲

mbreese an hour ago | parent | prev [-]

Let’s not ignore that dependencies are far more common in JS than any of those other languages. My Go or Python projects generally only include a handful of external packages. Node projects on the other hand…

	▲	paulddraper 27 minutes ago \| parent [-]
		Really? My requirements.txt does tend to be shorter than package.json, but not by a massive amount.

▲

dboreham 2 hours ago | parent | prev | next [-]

I think the general idea that your supply chain should be rooted in source repositories and associated commit hashes is the right one. Tooling can be made to automate the process of putting together a product from those defined sources. Some languages/systems already have some support for this. E.g. Golang and Rust. The concept of a "binary" artifact is really dead now everyone uses git and builds are quick. It lives on in things like npm and docker hub but we don't actually need it.

▲

twodave 2 hours ago | parent | prev [-]

For smaller shops (by small I mean <1,000 employees) this isn't even tenable. We (engineering team of about 10 people) mitigate what we can via tooling and cooldown periods/minimum release age. This will work as long as these malicious packages remain reasonably detectable. I think that's the proper balance, because we can adjust the # of days we are willing to risk against the SOTA of detection tooling.