Skip to main content
November 16, 2012

Security Debt and Vulnerability Supply Chains

When we were kicking around ideas for a new SoSS supplement, I thought the vendor testing angle could be interesting. We had just launched our VAST program so the topic made our marketing folks happy, but also because I think the supply chain analogy can be an interesting lens to view the security industry. We can think about the software supply chain as the vulnerability supply chain.

In a sense, we are also buying the vulnerabilities in that software along with the capabilities we need to assemble the final solution we are building. We are buying the software vendors “security debt.” When we assemble the solution, we inherit the vulnerabilities from the components. With software supply chain security testing we can push the security testing back along the supply chain – back closer to where the software is coded. In the SDLC everyone understands that the earlier vulnerabilities are detected the less expensive they are to fix. The same goes for the supply chain. Detecting and mitigating vulnerabilities after the software is shipped to you is very expensive. Let’s lower the cost by getting the vendor to do the testing and fixing.

Moving testing back along the supply chain depends on enterprise’s demanding more secure software from all of their vendors. Think about Microsoft when they first got security religion. It was because customers, particularly in the defense industry, pushing back saying, “listen if you don’t close up these flaws we’ll deploy Linux because we’ll have the source code to fix the flaws ourselves.” It wasn’t that Microsoft was proactive, they were responding to their customers.

Two things about the results I find interesting. First that C/C++ languages appear in a much higher percentage, 25% vs 9%, than when we look at the broader market. Non-type safe languages like C/C++ are very flexible for programming but that makes it harder to write secure code in. This is one of the reasons why we see well known flaw types such as buffer overflow persist in 75% of the C/C++ apps we test.

Secondly, the flaw prevalence in general is higher than when we look at the broader market. One possible reason for this, is that we test software from a lot of smaller vendors. These small vendors typically don’t have the security resources of a large vendor or enterprise development teams. So this is probably the first time they are doing a security test at all and that is why you see the higher number of flaws. Ask your vendors for evidence of security testing in their SDLC. If you get a blank stare back you would be wise to do some independent security testing.

Related Content

Chris Wysopal, co-founder and CTO of Veracode, is recognized as an expert and a well-known speaker in the information security field. He has given keynotes at computer security events and has testified on Capitol Hill on the subjects of government computer security and how vulnerabilities are discovered in software. His opinions on Internet security are highly sought after and most major print and media outlets have featured stories on Mr. Wysopal and his work. At Veracode, Mr. Wysopal is responsible for the security analysis capabilities of Veracode technology.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.