[Beta-7]

At my last job we (InfoSec) had the devs fill out "ownership" forms for when they want to include something third-party into the product. Other than forcing the team to do due diligence on the third-party it also made them responsible for keeping it secure and them the people "at fault" if something went wrong due to it.

While it was seen as an unnecessary hurdle set up by us I hope it started some meaningful conversations in the teams and maybe even end up with them "reinventing" the wheel for the better.

[aahortwwy]

These sorts of "security" measures kill productivity and ultimately accrue (along with others) to the point where your organization moves so slowly that its lunch gets eaten by upstart competitors who aren't burdened by self-imposed make-work.

I've seen it happen.*

EDIT: * While working in infosec, I'll add.

[Flocular]

Are you mitigating supply chain attacks otherwise? If yes, how?

[aahortwwy]

Yes. A myriad of methods falling into two main categories:

1. Robust build and deployment processes. Locked-down build servers, proxied/cached package registries, locked dependencies, automated dependency upgrades, tests, rollbacks, etc. Pretty much exactly what you need to mitigate unexpected breaking changes in dependencies, regardless of whether they're security risks or not.

2. Comprehensive dependency inventory. List of all your dependencies, where they're used, what vulnerabilities they're affected by, various other metadata, automated threat-hunting, manual review and annotation.

Trust but verify. No need for developers to fill out forms, wait on your (context-free) approval, resort to implementing worse versions of things themselves because they don't want to jump through hoops, etc.

[Flocular]

At my current job I'm trying to establish the same. Have to say, the recent news are water on my mills!