Pinned (major.minor.patch) versions and ignore-scripts should be the default. It's insane that the default is to execute untrusted code from the Internet.
It reminds me of back when IE would let me download a bat file and execute it
I mean, modern package managers generally now come with lock files, which effectively auto-pin your dependencies, until you trigger a dependency update.
And while it isn't bullet-proof, it does result in you effectively having a dependency cooldown most of the time. You're only vulnerable, if you trigger the dependency update while the compromised dependency release is public.
Obviously, this can be bad enough, but it does also mean that an ecosystem with lock files is far less attractive to target with a supply-chain attack, since far fewer hosts will get compromised on average.
The deal isn't ignore-scripts: the junk slurped from randos on the net with no transparency and validation can contain actual bad code that noobs just jam into their project without thinking. All the supply chain attacks against npms, composer, pips, containers, they all included actual bad code beyond what lever install scripts may be on them.
But we don't, as a society, care enough about validation. Hell, the Debian package format doesn't have a complete validation chain in it, and we complained about that decades ago when considering a derivative of it for an enterprise Linux release of our own -- and that's the very reason it didn't make the cut.
“cooldown” is exactly what it sounds like: a window of time between when a dependency is published and when it’s considered suitable for use. The dependency is public during this window, meaning that “supply chain security” vendors can work their magic while the rest of us wait any problems out.
Most of the supply chain vulnerabilities I've seen published and talked about lately have been trying to do things like exfiltrate keys/secrets from developers, including ci.
So of you've got a pr open with the vulnerable package update on it then you've goofed. Even potentially without merging if you've not got ci set up very securely, which is probably more common than we'd like to admit
9 Comments
dohpaz42@lemmy.world · 24 pts · 276d
Color me curmudgeon, but automated dependency updates should never be a consideration.
Also, one thing I do like that Github does is that it can be configured to send you a report of dependency changes (in yarn, for example).
folekaule@lemmy.world · 21 pts · 276d
Pinned (major.minor.patch) versions and ignore-scripts should be the default. It's insane that the default is to execute untrusted code from the Internet.
It reminds me of back when IE would let me download a bat file and execute it
/Getoffmylawn
Ephera@lemmy.ml · 5 pts · 276d
I mean, modern package managers generally now come with lock files, which effectively auto-pin your dependencies, until you trigger a dependency update.
And while it isn't bullet-proof, it does result in you effectively having a dependency cooldown most of the time. You're only vulnerable, if you trigger the dependency update while the compromised dependency release is public.
Obviously, this can be bad enough, but it does also mean that an ecosystem with lock files is far less attractive to target with a supply-chain attack, since far fewer hosts will get compromised on average.
corsicanguppy@lemmy.ca · 2 pts · 276d
The deal isn't ignore-scripts: the junk slurped from randos on the net with no transparency and validation can contain actual bad code that noobs just jam into their project without thinking. All the supply chain attacks against npms, composer, pips, containers, they all included actual bad code beyond what lever install scripts may be on them.
But we don't, as a society, care enough about validation. Hell, the Debian package format doesn't have a complete validation chain in it, and we complained about that decades ago when considering a derivative of it for an enterprise Linux release of our own -- and that's the very reason it didn't make the cut.
MonkderVierte@lemmy.zip · 19 pts · 276d
elgordino@fedia.io · 10 pts · 276d
pnpm has minimumReleaseAge https://pnpm.io/settings#minimumreleaseage
GammaGames@beehaw.org · 9 pts · 276d
Been using renovate a while, 42 added this as a default!
friend_of_satan@lemmy.world · 3 pts · 276d
Disregard3145@lemmy.world · 2 pts · 275d
Most of the supply chain vulnerabilities I've seen published and talked about lately have been trying to do things like exfiltrate keys/secrets from developers, including ci.
So of you've got a pr open with the vulnerable package update on it then you've goofed. Even potentially without merging if you've not got ci set up very securely, which is probably more common than we'd like to admit
Vulwsztyn@programming.dev · 0 pts · 275d
That's not a good idea