Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Programming

Half of Audited JavaScript Projects Contained a Vulnerability (theregister.co.uk) 62

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?
This discussion has been archived. No new comments can be posted.

Half of Audited JavaScript Projects Contained a Vulnerability

Comments Filter:
  • This will be abused, but how?
  • by Anonymous Coward

    More secure than Windows.

  • I seriously doubt only half. better title "JavaScript auditing so poor that half are given a clean bill of health"
  • Simple solution: (Score:4, Interesting)

    by Gravis Zero ( 934156 ) on Saturday August 25, 2018 @08:38PM (#57194894)

    Stop using JavaScript to do backend operations!

    • by Anonymous Coward

      Obvious outcome for low barrier to entry. Any Stackoverflow copy-and-paste dev or front end kiddie who fancies themselves an engineer can throw together crappy JavaScript code, and the rest of us have to use it indirectly on the web because companies think it's a good idea to use that garbage.

      Thanks nodejs!

  • It's the language (Score:5, Insightful)

    by phantomfive ( 622387 ) on Saturday August 25, 2018 @10:03PM (#57195156) Journal
    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.
  • by fahrbot-bot ( 874524 ) on Saturday August 25, 2018 @10:06PM (#57195162)

    Half of audited JavaScript projects *don't* contain a vulnerability. Seems like a win.

    • by Anonymous Coward

      No, at least half do. The other half don't contain vulnerabilities the researchers currently know about and looked for.

  • So they will send my plain text or unsalted & hashed password over the TLS-wire to the "trusted" pwned DB for a match?

    No thanks!

  • by Todd Knarr ( 15451 ) on Sunday August 26, 2018 @12:01AM (#57195464) Homepage

    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.

  • by drewsup ( 990717 ) on Sunday August 26, 2018 @03:27AM (#57195894)

    Hey, things are looking up for JS!

  • JavaScript itself is a vulnerability. Why do I have domain blocking of CSS but not JS in browsers?

  • by PinkyGigglebrain ( 730753 ) on Sunday August 26, 2018 @08:31PM (#57200158)
    This is one of main reasons why I have NoScript [noscript.net] installed on all my browsers, and if a browser isn't supported by NoScript I don't use that browser.

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...