Slashdot Mirror
Half of Audited JavaScript Projects Contained a Vulnerability (theregister.co.uk)
NPM Inc. added a feature to JavaScript's package manager this spring letting users type npm audit fix to replace old, insecure project modules -- and the Register asked them how it's going?
Since April, according to the company, npm users have run 50 million automatic scans and have deliberately invoked the command 3.1 million times. And they're running 3.4 million security audits a week. Across all audits, 51 per cent found at least one vulnerability and 11 per cent identified a critical vulnerability. In a phone interview with The Register, Adam Baldwin, head of security at NPM, said he didn't have data on how many people are choosing to fix flagged flaws. "But what we've seen from pull requests suggests it's gaining traction," he said.
Incidentally, npm's thinking about security is finding similar expression elsewhere in the industry. Earlier this year, GitHub began alerting developers when their code contains insecure libraries. During a recent media briefing, GitHub's head of platform Sam Lambert said he hoped that the process could be made more automated through the mechanized submission of git pull requests that developers could simply accept to replace flawed code.
Baldwin said NPM might implement something similar, an intervention rather than a simple notification. "Currently it's not proactive policy enforcement," he said. "But it's something we're considering." That would appeal to NPM's growing enterprise constituency. "Enterprises for sure want the compliance and control," said Baldwin. "They want that ability to know the open source they're bringing in is safe or meets a certain set of criteria."
Wednesday NPM added "Report a Vulnerability" buttons to every NPM package web page, and also started checking new passwords against the "Have I Been Pwned?" database to spot already-compromised passwords. "The tools for avoiding problems and fixing them are getting better," writes the Register. But it'd be interesting to hear from Slashdot readers.
How do you feel about code repositories automatically offering replacements for insecure libraries?
Incidentally, npm's thinking about security is finding similar expression elsewhere in the industry. Earlier this year, GitHub began alerting developers when their code contains insecure libraries. During a recent media briefing, GitHub's head of platform Sam Lambert said he hoped that the process could be made more automated through the mechanized submission of git pull requests that developers could simply accept to replace flawed code.
Baldwin said NPM might implement something similar, an intervention rather than a simple notification. "Currently it's not proactive policy enforcement," he said. "But it's something we're considering." That would appeal to NPM's growing enterprise constituency. "Enterprises for sure want the compliance and control," said Baldwin. "They want that ability to know the open source they're bringing in is safe or meets a certain set of criteria."
Wednesday NPM added "Report a Vulnerability" buttons to every NPM package web page, and also started checking new passwords against the "Have I Been Pwned?" database to spot already-compromised passwords. "The tools for avoiding problems and fixing them are getting better," writes the Register. But it'd be interesting to hear from Slashdot readers.
How do you feel about code repositories automatically offering replacements for insecure libraries?
Stop using JavaScript to do backend operations!
Anons need not reply. Questions end with a question mark.
And then cue the confusion from all the people who think their code can't be insecure because they are using a safe language, not like C.
A while ago someone said here that "buffer overflow exploits are the low-hanging fruit of hackers, once they are gone there is plenty of other stuff." And that person was right.
"First they came for the slanderers and i said nothing."
Half of audited JavaScript projects *don't* contain a vulnerability. Seems like a win.
It must have been something you assimilated. . . .
My experience is that large corporations want security and compliance. What they don't want to do is actually change anything to achieve it, especially if that changing happens on anything other than their schedule. Updating dependencies to fix security issues means having to revalidate and recertify the entire software stack, after all, and they want to avoid that at all costs. They'll only grudgingly do it when some outside agency credibly threatens them with fines and penalties that exceed the cost of the recertification. This is particularly silly since if you keep up with updates regularly it's a relatively painless process that usually doesn't break anything and if it does you've got plenty of time to fix it on your schedule. It only becomes an issue when you've avoided updates for so long that your versions of the dependencies are obsolete/unsupported and the current versions have major API redesigns or have been completely replaced by something with a different API. That's when it gets painful.
This is what happens when maintenance is considered a cost center rather than a necessary aspect of earning revenue. It's like considering janitorial services to be a cost center: pretty quick your business gets filthy and nobody wants to come in the door.