Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

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

Tim Greene | April 12, 2016
Look into vendors software supply chain, check the maturity of their software lifecycle programs

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.


Previous Page  1  2  3  Next Page 

Sign up for Computerworld eNewsletters.