[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?