Heartbleed, etc.

“Most attacks exploit known vulnerabilities — where a patch has often been available for months, if not years.”

Verizon DBIR

Reusable code means reusable exploits

Most of the world’s software is now assembled from reusable open source components, yet open source continues to be a major source of risk. In fact, more than 8,000 new vulnerabilities were disclosed in open source components last year, according to IBM.
Vulnerabilities are extensively described in public forums, vulnerability databases, and even YouTube videos — providing cyberattackers with a clear roadmap to attack critical systems and devices.
Public vulnerabilities also provide a large and global attack surface for cyberattackers, making them a juicier target than finding zero-days in custom applications.

globe-1

clean-code-1

CLEAN CODE REQUIRES CONSTANT VIGILANCE

Keeping your code free of publicly-disclosed vulnerabilities is a major challenge.
Vulnerability information is community-maintained and often inaccurate or incomplete. Many teams don’t track which components they’re using, let alone their versions. And components are often haphazardly patched without updating version numbers — making it even more difficult to know which vulnerabilities apply specifically to your product.
Worst of all, not all vulnerabilities are reported to a central clearinghouse. This means you're constantly monitoring community databases, mailing lists and other channels to make sure you don't miss any new disclosures.

“The recent explosion of Internet-enabled devices ... has led to a huge increase in the number of CVE requests we have been receiving on a daily basis”

MITRE Common Vulnerabilities & Exposures (CVE), April 2016

EMBEDDED SYSTEMS CAN’T KEEP PACE WITH EVOLVING OPEN SOURCE

The challenge is even more pronounced in embedded systems.
Open source packages are often modified to support custom requirements and resource constraints. Upgrading a single component can break the rest of your code.
Plus, embedded Linux distros are often derived from enterprise versions but lag in security updates.

embedded-systems-1

simpler-approach-2

A simpler approach is required

Code security for embedded systems should be simple and automated.
It should deliver deep and accurate visibility into your code — even if you've modified open source components. And provide actionable, disclosure-driven, and continuously-updated information for quickly patching vulnerabilities.

Want to see how our simpler approach works for you? Sign up for our free code security audit.

Free Code Audit