In earlier blog posts in this series, we’ve learned more about how the vulnerability used to break into the San Francisco Municipal Transportation Agency’s computers may have come from a single vulnerable open source component. We’ve talked a little about how developers use open source components – and why it’s hard for them to know what’s in their applications. What this leaves us with, as people who produce software is to answer the question: “What now?”
After all, we understand that developers don’t always know what’s in their applications, and sometimes can’t afford slow down delivery velocity to update to the latest version of a component that’s years out of date. How can we tip the scales back in your favor?
Fortunately, we’ve been through the problem of how to address other types of security in the development process before, and we know what it takes. Solving the problem of vulnerable components requires setting policy, getting an initial baseline of your inventory of components, focusing on developer education, and integrating security testing. It’ll also require a shift in how you think about open source components.
Sometimes the biggest challenge in dealing with security issues is where to start. Sometimes it’s knowing where to focus your attention to ensure you’re meeting your company’s compliance goals. Security and compliance teams should set a corporate security policy that explicitly lays out which component vulnerabilities require action, and in what timeframe. As for developers, you can help raise the priority of upgrading vulnerable software components by asking for an explicit policy. This helps the business understand the potential trade-offs with improved time-to-market.
A policy establishing that component vulnerabilities are important to the business should treat this issue like other non-functional requirements, like availability. Having a policy can also help ensure that there’s traceability between security requirements and any requirements of industry regulation. Several industry regulations, including banking, healthcare and PCI rules, require organizations to manage risk from third-party components. Addressing component risk can also be one of a customer’s security requirements.
It’s hard to know the magnitude of the problem if you don’t know what your existing applications already have for open source components. There are several ways to build an inventory, including looking at source control or component repositories. But one of the most reliable methods may be leveraging security testing you are already doing. Some static analysis providers, like Veracode, may already be creating an inventory of components for you. An inventory can be invaluable to the security team’s response to a newly announced vulnerability, allowing you to focus your efforts on the applications that you know have the vulnerable component.
Some developers may be unaware that they need to monitor the open source components they use for security patches, or that the components they use may rely on other components that may not be secure. Fortunately, learning these points is easier than learning how to protect against injection vulnerabilities. We know developer education makes a big difference, whether delivered in one-on-one sessions or via more formal CBT courses. By reading our blog series on open source components, you’re already ahead of the curve.
Developing a baseline inventory is only valuable as long as no changes are made to the software. As development teams make more changes to their applications, it’s important to keep the inventory, and the security picture, up to date. Veracode makes this easy by collecting information about your application’s open source components at the same time that static analysis is conducted – including open source components used by compiled libraries for which you have no source code.
One of the reasons that open source has proliferated, besides the genuine usefulness of it, is the price tag. But open source isn’t free like the air you breathe. I find it helpful to think of open source as a balance sheet. The functionality it delivers can be an asset to a development team, but keep in mind that the asset is offset by technical debt that requires regular payments, in the form of applying regularly released updates to the open source library.
And just as with regular debt, failure to make regular payments on technical debt can have catastrophic consequences downstream. Security patches that would be relatively painless to apply one at a time can be costly if you have to update past many minor revisions. Bear in mind the requirement to pay down technical debt from the start can make the difference between code that continues to deliver value for a long time, and code that must be scrapped and rewritten when the debt burden gets too high.
This is the third part of a blog series on vulnerabilities in third-party components and what enterprise developers can do about them. Read the first part: Why the Ransomware Attack on San Francisco Is Such a Big Deal. Read part two: How One Open Source Component Put 25 Percent of Java Applications at Risk.