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

Show HN: Tips to stay safe from NPM supply chain attacks

github.com

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#51

Post by grim_io »

potamic wrote: post #47
kpcyrd wrote: post #42

Also, don't use npx. With the colors incident back in 2022, random stuff started to break not when people updated their dependencies, but immediately, because npx would resolve dependencies when the command is executed. This means it's not really possible to reason about what code is going to execute, and forensics is going to have a really hard time figuring out what a computer has executed. If your software uses np…

> npx would resolve dependencies when the command is executed I hate that this is becoming a thing. I was pretty miffed some time back when I realized go build just went ahead and installed a whole new version of golang on my machine. These are devtools ffs, why so much mollycoddling! And what happened to half a century of good conventions where the default is always to prompt?

And what happened to half a century of good conventions where the default is always to prompt?

The good old "be careful what you wish for" :)

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#52

Post by turtleyacht »

zenmac wrote: post #4
turtleyacht wrote: post #2

For reducing external dependencies, it would be nice to somehow know every call made to a package, generating the call tree to replace. That becomes the API of the internal, replacement package.

You mean this: https://npmgraph.js.org

Thank-you, that looks pretty useful. Prior attempts involved `git blame' in projects' package.json per package. For example, to find when a project adopted React x+1 in which version, to determine the next minimum upgrade (to React ^x.y).

Consuming a package also means following its development alongside one's own. Multiplied by each dependency, it's a commitment to a particular constellation of dependencies. Migration guides and codemods help, but ultimately maintenance requires active participation.

That takes time--often more than what's available.

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#53

Post by turtleyacht »

cj wrote: post #9
privatelypublic wrote: post #3

Earlier quoted context omitted.

Not sure that's possible with JS.

You could theoretically overwrite the public functions of a module, inject some logging code, then execute the originally intended function when it's called with ".apply()" and passing the original arguments in. That might get you part of the way there.

Yes, some automated instrumentation equivalent of `debugger' at the start of the module's first such function, and stepping into each function down to some depth, then starting over with the next line of the module's implementation.

A partial or semi-automated, tool-assisted approach might be possible, if there were a way to restart Node.js between decisions. Each decision point writes an entry "event" that records the filename, function, caller, line number, etc. Then `debugger' is inserted before the next line, and so on.

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#55

Post by knlsn »

HoyaSaxa wrote: post #6

For most projects, overriding every single transitive dependencies to be pinned is impractical. Instead, for those using npm, I'd highly suggest using `npm ci` both locally and of course on CI/CD. This will ensure the (transitive) dependencies pinned in the lockfile are used. TIL on the `npm install --before="$(date -v -1d)"` trick; thanks for that! Using that to update (transitive) dependencies should be really help…

For GitHub Actions, i found http://safedep.io/ to be helpful, not only it guard against known attacks, but also it has its own malware detection engine.

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#56

Post by knlsn »

politelemon wrote: post #16
indigodaddy wrote: post #5

Someone recommended this to me on another thread and tried it yesterday and it seems very good: https://github.com/safedep/vet

Isn't this just checking packages against known cves, which wouldn't help for undiscovered or unannounced vulnerabilities. Let me know if I've misunderstood, I'm basing off the documentation site. Also I find the irony goes hard in their recommendation of installing another attack surface (brew) on Linux and missing the point.

I think, they have an malware detection engine of their own, so not only they help protect from known vulnerabilityes / malwares but also have thier own database

their blog: https://safedep.io/dynamic-analysis-oss-package-at-scale/

Post reply on HN