"Just wait 2 weeks to use new versions by default" is an amazing defense method against supply chain attacks.

booi 3 days ago | parent | next [-]

Is there some sort of easy operational way to do this? There are well known tech companies that do this internally but afaik this isn't a feature of OSS registries like verdaccio

▲

fclairamb 3 days ago | parent | next [-]

Renovate is a great (and free) tool to update your dependencies. By default it will update packages in the hours (often minutes) of their release but you can change that behavior with the minimumReleaseAge parameter.

https://docs.renovatebot.com/configuration-options/#minimumr...

▲

jamietanna 3 days ago | parent | next [-]

Yep, Renovate's `minimumReleaseAge` is what you want here

Dependabot has recently added this functionality too - it's called `cooldown`

https://docs.github.com/en/code-security/dependabot/working-...

(I'm soon to be working at Mend on Renovate full time, but have been a big fan of Renovate over other tools for years)

	▲	jamietanna 2 days ago \| parent [-]
		For anyone following, we (Renovate maintainers) are making this an inbuilt "best practice" that users who already opt into using the `config:best-practices` preset will start getting for free! https://github.com/renovatebot/renovate/pull/37967

▲

Apfel 3 days ago | parent | prev [-]

The one big problem Renovate brings is when it automerges and breaks everything with e.g. a TypeScript upgrade. It's simple enough to handle and prevent but has required quite a lot of developer education for those who are not particularly frontend-focused in my experience.

	▲	jamietanna 3 days ago \| parent [-]
		Interesting, so you've enabled Renovate's automerge functionality for dependencies? Renovate uses signals like your CI to work out whether things break before an automerge occurs - does that mean your CI didn't catch the breakage? Or something I've missed? (there's also the "merge confidence" that can help here) (I'm soon to be working at Mend on Renovate full time)

▲

wallrat 3 days ago | parent | prev [-]

There are dependency firewalls that let you enforce this (e.g. https://docs.bytesafe.dev/policies/delay-upstream/). Don't know any OSS solutions though.

▲

kevinrineer 4 days ago | parent | prev [-]

Its also really ineffective defense against 0 days!

▲

easterncalculus 3 days ago | parent | next [-]

In the context of a single system, there is no such thing as an "effective defense against 0 days" - that's marketing babble. A zero day by definition is an exploit with no defense. That's literally what that means.

▲

hdjrudni 3 days ago | parent [-]

That doesn't sound right.

> A zero-day exploit is a cyberattack vector that takes advantage of an unknown or unaddressed security flaw in computer software, hardware or firmware. "Zero day" refers to the fact that the software or device vendor has zero days to fix the flaw because malicious actors can already use it to access vulnerable systems.

If I never install the infected software, I'm not vulnerable, even if no one knows of its existence.

That said, you could argue that because it's a zero day and no one caught it, it can lie dormant for >2 weeks so your "just wait awhile" strategy might not work if no one catches it in that period.

But if you're a hacker, sitting on a goldmine of infected computers... do you really want to wait it out to scoop up more victims before activating it? It might be caught.

	▲	saberience 3 days ago \| parent [-]
		Yeah but zero days usually refers to some software which is commonly installed. E.g. a zero day in the version of windows or mac os that most people are using. No one bothers finding 0-days in software which no one has installed.

▲

blamestross 4 days ago | parent | prev | next [-]

Sadly we don't have any defense against 0 days if an emergency patch is indistinguishable from an attack itself.

Better defense would be to delete or quarantine the compromised versions, fail to build and escalate to a human for zero-day defense.

	▲	minitech 3 days ago \| parent [-]
		> Sadly we don't have any defense against 0 days if an emergency patch is indistinguishable from an attack itself. Reading the code content of emergency patches should be part of the job. Of course, with better code trust tools (there seem to have been some attempts at that lately, not sure where they’re at), we can delegate that and still do much better than the current state of things.

▲

ozim 3 days ago | parent | prev [-]

IF I put my risk management hat on - 0 days in npm ecosystem are not that much of a problem.

They stop working before can use them.