This stuff has been brewing for years, but since technically you could fix all instances with minimal StackOverflow downtime [1] and a slightly different pattern, few people worked on either using engines with data structures less prone to the worst case or adding the generic workarounds for those that have them.

e.g. in cPython, until 3.11, there was no support for atomic grouping (roughly translation: "never backtrack inside of this expression"). There is little useful advice a linter can give, if there is no predictable-runtime way to express what you want within a single match step, because you really do want to unwind the stack and check for repeats (just without any of the exponential runtime stuff, please).

[1]: https://meta.stackoverflow.com/questions/328376/why-does-sta...

No I think he was just looking to raise his profile, not to help.

It's only a real issue if it is in runtime code that parses untrusted input. 99% of the regex lints/CVEs that get flagged our way are in build-time code.

Developer's machines are high value targets. They were absolutely right to point that out.

Working in the EU energy sector where we have to work with NIS2 compliance, I'd argue that your security team rightly pointed it out. I suspect that's what you mean though, and the rightly is just there because you agree with it but don't like it. We work with even more tight dependencies policies than just having alerts. We have a set of pre-approved and yearly vetted packages, like pandas or pyarrow for Python data work. Aside from that we have some isolated development environments where your pipeline can get access to something like SQLC for Go. Which is essentially where your dev dependency lives in it's own environment where it can produce the code it needs to and then submit it for approval into your regular dev environment.

Ironically we'd probably need to run Dependabot itself in a mirrored environment since it too has external dependencies we'd probably not want to vet.

I do think external dependencies are among our biggest security threats though. It's so hard to vet them, and compliance basically comes down to "We trust the apache software foundation enough, and pyarrow is vital to our business, so we accept the risks", and then you lock versions and aren't the first to update except for vulnerabilities. Shadow AI is obviously the number one security threat right now, especially in enterprise with people who are very tech savvy. This makes dependencies so much worse though, because now everyone can (if their systems aren't locked down tight) do so many crazy things. Both with the "non-sanctioned" AI but also with the code it can generate for them.

Everyone talking about malware in dev dependencies as if dependabot only raises issues about that, but it does not. It raises warnings about all sort of "vulnerabilities" irrespective of the threat model.

Even worse, it incentivizes randomly updating dependencies, which is what actually allows supply chain attacks.

A lot of the recent npm attacks have been exfiltration from dev machines, which would just as likely from dev dependencies.

Dev dependencies is how they compromised SolarWinds and thereby most of the US federal government.

> The attackers used a supply chain attack. The attackers accessed the build system belonging to the software company SolarWinds, possibly via SolarWinds's Microsoft Office 365 account, which had also been compromised at some point. SolarWinds was using build management and continuous integration server TeamCity provided by the Czech company JetBrains. In 2021 The New York Times stated that unknown parties apparently embedded malware in JetBrains' software and through this way compromised also SolarWinds.

https://en.wikipedia.org/wiki/2020_United_States_federal_gov...

I don’t know what kind of software you write, how valuable your company’s infrastructure is, etc. But supply chain and insider threat in security/infrastructure is a big topic — that I’m sure they’re concerned about because that’s their area of responsibility.

Even if I’m personally sympathetic to not wanting to deal with the churn of dev dependency updates.