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 also by 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 safe. 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 spend a lot of time updating and fixing old component versions. The challenge is to have developers have the tools to identify risky component versions from the start. Developers need to be informed early on of the risk and have the tools to choose approved components that meet organizational and departmental security policies.
There is no way developers can spend the time to check for the latest versions or 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 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 life cycles, 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 life cycle.
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 life cycle, 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.