News for hackers. Stuff that matters.
Re:Dev corrupts NPM libs 'colors' and 'faker', breaking thou... by Flocular on Sunday January 09, 2022 @05:38PM (#29868064)
Imagine they introduced something worse. Could any developer explain to a manager why you needed to import this package? "Why do we need colors there?", "Why can't we make that colored ourself?"
Re:Dev corrupts NPM libs 'colors' and 'faker', breaking thou... by Beta-7 on Sunday January 09, 2022 @05:53PM (#29868232)
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.

Re:Dev corrupts NPM libs 'colors' and 'faker', breaking thou... by aahortwwy on Sunday January 09, 2022 @07:05PM (#29868882)
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.

Re:Dev corrupts NPM libs 'colors' and 'faker', breaking thou... by Flocular on Monday January 10, 2022 @05:31AM (#29872774)
Are you mitigating supply chain attacks otherwise? If yes, how?
Re:Dev corrupts NPM libs 'colors' and 'faker', breaking thou... by aahortwwy on Monday January 10, 2022 @10:27PM (#29887079)
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.

Re:Dev corrupts NPM libs 'colors' and 'faker', breaking thou... by Flocular on Sunday January 09, 2022 @06:03PM (#29868326)
At my current job I'm trying to establish the same. Have to say, the recent news are water on my mills!
Re:Dev corrupts NPM libs 'colors' and 'faker', breaking thou... by chrisshroba on Sunday January 09, 2022 @05:51PM (#29868213)
An easy answer would be "we import thousands of packages either directly or recursively, so while we may be able to replicate the work of any one of those (which is unlikely to be true in the first place), it would take thousands+ of engineer hours to replicate all of them, and there was no way of knowing that this one among thousands would be sabotaged."
Re:Dev corrupts NPM libs 'colors' and 'faker', breaking thou... by iainmerrick on Sunday January 09, 2022 @05:45PM (#29868158)
“Why are you writing all this stuff by hand? Isn’t there a package for that?”