What can the financial services industry learn from the U.S. Department of Homeland Security? In this third segment of my blog series on open source component security as it relates to the recently updated Financial Services Information Sharing and Analysis Center (FS-ISAC) guidelines, I explore the need for speed: humans vs. machines.
One mantra of the Homeland Security Agency is – “if you see something, say something” – which works on a human level to keep us safe. This same mantra has been used across the open source community to keep components secure, by identifying vulnerabilities and sharing that knowledge through public channels like the Common Vulnerabilities and Exposures (CVE) database. But it is now time we recognize that “if you see something, say something” only works for open source at human speed.
Just as the U.S. Department of Homeland Security relies on electronic surveillance to keep citizens safe, the open source software community also needs to embrace this approach. To properly ensure open source is secure, we need to work at machine speed.
We have longed surpassed a tipping point in open source development and usage of open source components. Not only do custom applications rely heavily on such components, so do the open source components themselves. Let's take the Java developer community as an example.
Looking at the Maven ecosystem and traffic associated with the Central Repository, you can readily see years of exponential growth of open source component downloads. The same patterns appear with RubyGems, NPM and other major open source ecosystems. We have entered an era of massive and highly effective component re-use, where everyone can, paraphrasing Einstein, stand on the shoulders of open source giants.
Recent research also shows that 64 million vulnerable Java open source components were downloaded in 2013. While developers can rely on the Common Vulnerabilities and Exposures (CVE) database, manual review of this database for every component is simply not feasible if an organization wants to release its software on time.
Making the challenge more considerable, organizations also have trouble keeping track of which components, including the specific versions, are used in which applications. And further amplifying the concern, you need to consider the component dependencies (five on average, but can range to hundreds).
I would argue that a manual approach today is truly impossible given:
The better approach is to have humans establish risk thresholds and supporting policies. To have machines automate and enforce those policies. And to have humans manage the inevitable exceptions.That is, we need to complement human speed approaches with machine speed capabilities.
Whether organizations use software-based technologies and data services from Sonatype or other vendors, we are now well beyond maintaining open source security at human speed. Would you agree?
If you missed the first two segments of this blog series, you can find them here: Part 1, Part 2.
To learn why Sonatype is a preferred application security vendor for financial organizations visit http://www.sonatype.com/spotlight/fs-isac
