Open Source Components, a Fine Vintage or Sour Milk?

The U.S. recently overtook France as the world’s largest wine market.  And here at Sonatype, we can proudly say we’ve contributed to this achievement. By not only consuming our fair share of wine but by also being involved — outside of work — in crafting our own wines.

Over the 4th of July holiday, I was able to enjoy some of the wine I’ve aged over the years. For the best wines, aging can create spectacular results years down the line. Unfortunately, the same cannot be said for code and components used in today’s applications. Where aging improves a fine wine, code ages more like milk.

New vulnerabilities are frequently discovered in open source components previously thought to be safe, so to keep your applications from going sour, you should rely on automation to alert you when new risks are discovered in existing applications.

The same goes for development. The idea that old = reliable for open source components doesn’t hold true. In fact, one of the greatest benefits of the open source community is collaborative development. Developers are spending a great deal of time updating and fixing old component versions, the challenge resides in having the tools for developers to identify risky component versions from the start. Developers need to be informed of the risk early on and have the right tools in place to chose approved components that meet organizational and departmental security policies.

There is no way developers can spend the time to go off and check for the latest versions or to verify whether their version of that component (and its dependencies) are free from known vulnerabilities.  There are too many sources of information to look through, and too little time. Success within the development process requires automation — the closer to the developer’s integrated development environment (IDE) where the code and components are assembled, the better.

While there is some level of bolt-on application security positioned toward the end of development lifecycles, this often becomes a scan and scold approach leading to costly rework efforts. To no surprise developers often tell me, “rework is death”.  While security practices at all stages of application development are advised, we need to consider introducing automated security practices further left in the application development lifecycle.

The friction of requiring developers to search external vulnerability databases or waiting for manual approvals can be eliminated with security and license information integrated into the tools developers already use today. If developers can benefit from identifying the most current, most popular, lowest risk components earlier in the development lifecycle then maybe just maybe software won’t rot as quickly as milk. For more information on how to empower developers to choose better components from the start, read our latest paper 7 Security Gaps in the Neglected 90% of your Applications.