Open source code is common, potentially dangerous, in enterprise apps

Look into vendors software supply chain, check the maturity of their software lifecycle programs

The Open Source Vulnerability Database shut down this week posed yet another security challenge for developers who routinely inject massive amounts of free off-the-shelf code into new software.

As the name suggests, OSVD was a resource where non-commercial developers could look – free - for patches to known vulnerabilities.

+More on Network World: 10 best cloud SLA practices+

Without it, other vulnerability repositories remain, but its closure points up one of the problems with how open source code is used, particularly in enterprise development: often once it’s incorporated into apps, it might never be updated to fix vulnerabilities that are discovered later.

And that is a big problem. “Everyone uses open source,” says Mark Curphey, CEO SourceClear, a startup focused on securing open-source software, particularly for corporate developers. “Ninety percent of code could be stuff they didn’t create.”

The percentage might actually be closer to 75%, but that’s still significant, says Mike Pittinger, vice president of strategy for Black Duck, whose automated platforms help customers ensure open source code remains free of vulnerabilities.

Other companies offer similar services, including WhiteSource, which handles the commercial use of information compiled in the OSVD. It discovers open source components in its customers’ apps and alerts when vulnerable code is added to ongoing software projects or when new vulnerabilities pop up that affect customers’ existing software.

+ RELATED: Open source security is not as big of a concern as it once was +

Urgency to rapidly develop software leads to popular use of open source code. It’s available, often free and vetted by involved communities. But that urgency can lead to sparse records about what versions of what open source software is used, says Pittinger, leaving corporate security pros guessing when they’re trying to figure out how vulnerable their in-house apps are.

Unless developers log what open source code they use in an automated fashion, compiling that information later will be basically a best guess. “It’s only as accurate as is the memory of the development team,” he says.

Attackers are well aware of this use of open source code. They monitor GitHub, for example, to see who contributes what code and whose code had problems. Then they follow the people who follow them to find out what they’re working on, hoping they will use some of the vulnerable code they’ve found on GitHub, Curphey says.

Recently a JavaScript coder who was ticked off about a challenge to his use of the name kik for one of his software packages retaliated by pulling all his open source contributions from a public registry, creating widespread problems for developers who relied on them.

The outcry was so loud that the registry, npm, went against the coder’s wishes and republished one 11-line piece of code whose absence was causing the most trouble.

Problem solved, at least in this instance. But the underlying issue – the routine practice of reusing open source code in new software – remains.

It’s not just open source

The problem extends to commercial software, too, and vendors should be held to a high standard, he says. They should disclose what open source is in their software, track it and issue patches when new vulnerabilities are discovered, he says.

Keeping track of the software supply chain in complex applications is important. Just last month researchers found more than 1,400 vulnerabilities in a networked medical supply cabinet due to third-party software incorporated in its stack including Microsoft Windows XP, Symantec pcAnywhere and SAP Crystal Reports 8.5.

Keeping track is so important that later this month the Food and Drug Administration will start work on the final draft of regulations for medical devices and how to deal with software vulnerabilities that present themselves after medical devices have shipped.

Code security issues can extend to popular network devices, even security gear. Famously, Juniper announced back in December that its NetScreen gear had been backdoored and unauthorized code injected into the operating system. How is still a mystery – at least to the public. Unknown parties apparently installed the backdoor intentionally, leaving it to be exploited at will, but exploitable vulnerabilities may be the result of poor coding, inadequate quality assurance or honest error.

Investigating what happened should have involved an examination of what Curphey calls code genetics – where the code came from and who wrote it. Both need to be examined to determine how it happened and whether the genetics reveal further threat. “It could have been a rogue developer. If so, what else did that developer touch?” he says.

It’s one of the basics of software security, but patching is something that is often ignored or put off until a more convenient time. That leaves a window of opportunity for attackers, who are well aware of this tendency on the part of network admins, says John Pironti, president of IP Architects.

Take Microsoft’s Patch Tuesday, which addresses weaknesses discovered month-by-month. Because many organizations don’t patch right away it results in a Patch Tuesday contest, he says. The game is, “How fast can I reverse-engineer the Microsoft patches?” he says. Attackers try to figure out what flaws the patches correct, create ways to exploit them, then seek vulnerable systems to attack before they are patched.

In the Juniper NetScreen case it’s likely many customers using the gear haven’t installed the patches yet and won’t for a long time, he says. “This will be used for years.”

There are steps to take that reduce risk:

  • Understand what open source or third-party is in the software you buy.
  • Ask vendors to document how they monitor ongoing health of components they are using and how they fix flaws. How mature is their software development lifecycle program that monitors code from birth to grave?
  • If there’s a commercial third-party library being used, is there an SLA with that vendor to ensure faulty components get patched?
  • Are commercial software developers using static and dynamic analysis and threat modeling to check the viability of their software?
  • Set priorities about which applications are monitored and maintained most closely based on how critical the apps are to the business and the value of the resources they touch.

Enterprises need to set up and maintain persistent programs to upgrade and patch their software as fixes become available. “Security is ephemeral,” Pittinger says. “Today’s scan is good, but that can change.”

And when buying applications businesses should grill the developers about security of their supply chain, how they screen the code they use and what their program is for patching their products once they’re in the hands of their customers. “We need to raise the expectations we have for software vendors,” Pironti says.

Join the CSO newsletter!

Error: Please check your email address.

More about JuniperMicrosoftNetScreenSymantec

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Tim Greene

Latest Videos

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

  • 150x50

    IDG Live Webinar:The right collaboration strategy will help your business take flight

    Speakers - Mike Harris, Engineering Services Manager, Jetstar - Christopher Johnson, IT Director APAC, 20th Century Fox - Brent Maxwell, Director of Information Systems, THE ICONIC - IDG MC/Moderator Anthony Caruana

    Play Video

More videos

Blog Posts