Qualys and Sonatype Lifecycle

Shifting security further left.
thumbnail-Qualys

Strategies to Ban Avoidable Open Source Risk: A Discussion With Andrew Wild, Former Chief Security Officer, Qualys

At the Gartner Security & Risk Management Summit in June 2014, Wayne Jackson, CEO of Sonatype, assembled a team of security practitioners to discuss “Strategies to Ban Avoidable Open Source Risk.” Andrew Wild, Former Chief Security Officer at Qualys, shared his insights and experiences building an effective secure software development lifecycle that also addressed avoiding open source risk. Here are excerpts from the panel discussion.

Jackson: The 2014 Sonatype Open Source Development and Application Security Survey showed the application is the most commonly targeted attack victor and yet we spend relatively little time and relatively little money securing that attack vector. What are your thoughts about why that might be and how you think that might be changing?

Wild: I think a lot of it has to do with the history of information security in organizations. Information security has worked very hard over the years to integrate with IT and with the business. But integrating with the development engineering side hasn’t been a focus in many organizations and, as a result, we do not see the vulnerabilities that are there. We see the exploits.

It is getting attention now, but the tools are often lacking or they are just not deployed within the organization. The information security organization doesn’t have that relationship with the engineering team to get them into the Software Development Life Cycle (SDLC) or they are just more comfortable sticking with what they know best: budgeting for rewalls and endpoint security.

Jackson: It’s still remarkable how many people in very senior positions have no idea of the extent of their use of open source and whether they are vulnerable or not.

Wild: We are making progress in terms of awareness and policies. It’s not uncommon now to read in 1 publicly traded companies’ filings public statements that a risk factor is the use of open source software and there could be licensing impacts from that. How that risk is stated and disclosed, actually mitigated or managed inside, well that’s a totally different matter I think but it’s beginning to appear more and more. There is awareness that it is a risk that needs to be managed. I think in many organizations, it’s one of many and it may not get the prioritization it really deserves. “

“We wanted to give developers the tools to help them with their decision-making when selecting open source components.”

CHIEF SECURITY OFFICER
Qualys

Jackson: Folks are coming to the reality that their infrastructure is built on open source. Human-based policies that follow older methodologies—to establish whitelists and blacklists, request approvals and so on—are really falling short because too much open source being used is too complex.

Wild: One of my priorities was to gain visibility. At Qualys, we have a defined software development lifecycle. We use an Agile development philosophy, but there was a disconnect between the visibility the security team had and with the developers. You talked about the developers not tracking or knowing. Well, why would they? They built it; it passed through QA testing. Operations is typically the group that on an ongoing basis is managing vulnerabilities. The operations team is handed an assembled piece of code to run. They may not necessarily have detailed visibilities into all the components that make up that system. This creates potential disconnects. So to gain that visibility into the build process—and to identify potential open source components being used before the build process is complete—is something I thought was very significant and would really augment our capability to develop safe code.

Jackson: You are building the code that keeps other people safe too.

Wild: Yes! So it’s important that we do it right. Just because you buy a security product, don’t assume the people that built it know anything about security ... at the code level. It’s really hard to get right and not fall into a false sense of security just because something has the word “security” in it.

Jackson: Toyota has a process where they try to optimize their supply chain thinking around producing more products more quickly with more predictability, with more efficiency over time. To your point about awareness being the first step, learnings from the Toyota supply chain philosophy are all about creating awareness so that employees who are empowered to make decisions can do so in a more real-time way. There are guardrails, so that predictability is preserved and optimized over time.

Wild: In the private sector, third-party risk management is maturing very rapidly, perhaps not as rapidly as 2 it should. But I’ve seen just in the three years that I’ve been at Qualys tremendous change in the volume and complexity of the questions that come from customers asking about the Qualys security program, asking about the software development lifecycle, how it works, what we have, what controls we have, and our use of open source software. So this is beginning to become part of the purchasing of the procurement process and, at least in the private sector, I think that is going to have an effect. How that translates to actual implemented security improvements remains to be seen, but I do think there is a concerted effort and push that is coming from the advancement and maturity of third-party risk management.