Yeah I completely understand their intent, but I might get 30 vulnerabilities across a multiple repos flagged in a week. It is already tedious to check them all and assess if they're worth worrying about let alone having to update them. These are 99% Javascript though - I suspect other ecosystems are much more manageable.

▲

Gigachad 2 hours ago | parent | next [-]

It's easier to keep stuff up to date these days. If you have a project with typescript, unit tests, and end to end tests like cypress you can just have dependabot create the PRs to update packages. If everything passes you just have to hit the merge button.

Just updating everything is probably easier than assessing if it's possible to trigger an exploit with the way you use the package.

▲

froddd 2 hours ago | parent | next [-]

This is exactly how developers of malware want you to behave. Update without really thinking about it.

I do wonder how long it will take before an attack is developed by submitting a semi-genuine vulnerability, shortly followed by a ‘fix’ including malicious code.

▲

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

Yep this is what has happened to small teams. You really only have time to approve the dependabot changes and go go go. Otherwise you'll never get anything productive done.

The other option is to simply ignore updates and do them on a schedule, e.g. once every 1-2 months.

▲

ThreatSystems an hour ago | parent | prev [-]

In agreement with frodd above.

Dependencies and supply chain attacks are probably the greatest risk to a lot of software orgs, as they run them across all their environments: Development (with secrets and other valuable artefacts on developer VMs), CI/CD pipelines which may have access tokens to production (and other) environments, and production itself.

Notably even security companies are being impacted by this[0]. The scale of these attacks has amplified quite significantly the past three years, but are not solely exclusive to the javascript ecosystem [1] or even just namesquatting/typosquatting [2].

The resolution is broader security awareness, "onion layered" security controls and implementing simple non-burden inducing processes and policies. Sometimes not updating (what was wrong with the previous version of a dependency if there was no immediate vulnerability or production issue caused by it?) or having a two week cool down for updates (which some supply chain tooling natively supports) can appease some security functions through clear communication of the supply chain risk etc.

If anyone has interest in courses aligned to your org on improving developer and broader engineering management awareness on this, e-mails in my profile :).

[0] - https://socket.dev/blog/ongoing-supply-chain-attack-targets-...

[1] - https://orca.security/resources/blog/hades-pypi-supply-chain...

[2] - https://checkmarx.com/zero-post/python-pypi-supply-chain-att...

	▲	an hour ago \| parent [-]
		[deleted]

▲

varjag an hour ago | parent | prev [-]

I unironically think the solution is vibecoding your own Javascript blobs that use no frameworks and have no (or minimal) external dependencies. At this point it is entirely feasible for many kinds of projects.