[Macha]

This is a general problem with many security scanning tools, and when a security team is empowered to give deadlines to fix any issue they report, leads to much frustration and poor relations in teams.

Imagine if you had 3 days to fix the regex DoS issue shown there, screw your release freeze and your current sprint plans, and you have the real working environment in some companies.

I've also heard reports of people trying to claim bug bounties for similar reports, or security vendors that run automated tools that detect for issues of similar (lack of) value.

[_jal]

Among other things, it illustrates the insufficiency of a single numeric value for assessing 'badness', which in turn masks a management issue.

CVEs try to supplement with flags for remotely exploitable, etc. but it still intentionally leaves a lot of space for interpretation, which is necessary for any normal enterprise.

The problem comes in when analysts (or their managers) interpret inflexibly, without appropriate technical context, or without understanding business impact and tradeoffs.

If you look at the workflow, it is hard to close the loop from engineering or IT back to security. We need a set of controls for secops departments' output relevance and departmental interoperation.

[woutr_be]

This is actively going on where I work. Granted, it’s a financial company, so they take security pretty serious. During our last release, we had to go through 3 different teams, all doing different security scans.

One if them is scanning all your dependencies, and its so frustrating. Because that team obviously has no idea what any of the dependencies do or how they’re being used. All they see is a red flag, and tell you to fix it. Good luck when they tell you this days before a release, and a week after the code is frozen. They’ll just block your release without a second thought.

Funnily, in our last release, some of our NPM packages were flagged as a risk, obviously without explanation. The thing was, these packages where dependencies of another package. Obviously we can’t go around updating open source code, just because the security team in our company told us.

[charcircuit]

>Obviously we can’t go around updating open source code, just because the security team in our company told us.

This isn't obvious to me. Most open source projects accept contribution from others.

[woutr_be]

> This isn't obvious to me. Most open source projects accept contribution from others.

Of course they do, and I'm more than happy to help with open source projects. My point was that, we can't do it, just because a security review at my company says so. It's not just as simple as updating the version of the affected package, there's also testing involved, potentially fixing issues due to using a later version. This would almost be a full-time job.

[Macha]

Who says it's important to that maintainer that their project used as a build time dependency has a vulnerability if provided untrusted user input?

What if it requires major upgrades of their framework or toolchain they don't want someone doing drive by?

What if they require a CLA that your legal team won't let you sign?