The cybersecurity industry has reached an inflection point where counting vulnerabilities no longer serves as a meaningful metric for security success. Alex Kreilein, VP of Product Security at Qualys, makes a compelling case for why organizations need to shift from endless vulnerability chasing to strategic risk operations that deliver measurable business outcomes.
Speaking to us at Qualys’ newly rebranded Risk Operations Conference (formerly QSC), Kreilein outlines how the traditional vulnerability management approach creates friction, wastes engineering time, and fails to address the underlying security challenges organizations face. His perspective comes from hands-on experience managing product security at scale and understanding what actually makes attackers’ jobs more expensive.
The fundamental difference between risk and vulnerabilities
Kreilein draws a clear distinction that many security programs miss: “Risk is separate from vulnerabilities. Vulnerabilities are an attribute to the calculation that is risk.” This seemingly simple statement has profound implications for how security teams operate.
Traditional vulnerability management sends teams chasing CVEs without context, making engineers do work they don’t want to do, and creating what Kreilein calls “an endless game of whack-a-mole.” Instead, he advocates for understanding exposure and value at risk. Quality over quantity analysis that focuses resources where they actually matter.
“What I really want is 10,000 hours back,” Kreilein explains. “I would rather get that time and invest it in things that are productive.” This means moving away from volume metrics toward understanding which vulnerabilities actually create exposure in specific environments.
Why SBOMs alone don’t solve the problem
Software Bills of Materials (SBOMs) have become a buzzword in security, especially following various regulatory pushes in the United States. Kreilein acknowledges their value but cautions against misunderstanding their purpose.
“Software bills of materials are just an ingredients list,” he notes. “That’s helpful because the idea is that through transparency we will have a shared understanding. The problem is that they don’t deliver a shared understanding because the expectation of anyone in security who reads the SBOM is the first job they’ll do is run those versions against vulnerability databases.”
This creates a predictable problem: security teams receive SBOMs, scan them for vulnerabilities, and generate alerts for every CVE match, regardless of whether those vulnerabilities actually affect the product. The result is unnecessary escalations and wasted time investigating false positives.
For developers, however, SBOMs offer different value. Kreilein points out that organizations often discover they’re using 12 different logging libraries when they thought they had standardized on one. “That’s really inefficient,” he observes. “Should we then not consolidate down to one, or perhaps two? Eliminate the need for carrying extra weight in our backpack, because that’s all stuff that we have to test for.”
Also available as Techzine TV Podcast
Subscribe to Techzine TV Podcast and watch and/or listen to our other episodes via Spotify, Apple , YouTube or another service of your choice.
If you want to listen to this episode of the Techzine TV Podcast, but not watch it, that’s possible too. You can find our podcast on all well-known and not-s
VEX: The missing piece for effective vulnerability communication
To make SBOMs truly useful, Kreilein introduces VEX (Vulnerability Exploitability Exchange), an open standards framework that addresses the context problem. VEX provides four status messages: affected, not affected, under investigation, and fixed.
“What we want to start doing is using a project called VEX that gives four possible status messages,” Kreilein explains. “Now we’re actually communicating with each other in a machine readable format, which is nice in itself, but we’re really communicating with each other in a shared language and taxonomy.”
He provides a concrete example with Log4Shell, the critical vulnerability that created chaos across the industry: “If we go and remove access to the JNDI class path, we can use the vulnerable version and we’ve eliminated the risk. Which means that if you look at the SBOM, you’ll get a true positive detection on the CVE, but it’s not applicable. My product is not affected.”
By combining SBOMs with VEX status messages and publishing through CSAF (Common Security Advisory Framework), organizations can finally answer the real question security teams need answered: Is this vulnerability actually exploitable in our specific implementation?
The real root cause of vulnerability debt
When asked why developers struggle to remediate vulnerabilities quickly, Kreilein offers an insight that challenges conventional security thinking: “The real root cause of vulnerability debt is not insecurity, but is almost always fragility and lack of test efficacy.”
Developers aren’t refusing to patch because they don’t care about security. They’re worried that upgrading a component will break the application. “If my application is brittle and can’t take change, I cannot upgrade to the non-vulnerable version,” Kreilein explains. “If I don’t have effective test automation and integration and unit testing, I can’t guarantee that this upgrade won’t break the application.”
This reframing shifts the security conversation from compliance and mandates to engineering fundamentals. Better test coverage, better reference architectures, and better secure-by-design practices become security initiatives. Not because they’re security tools, but because they enable the outcomes security teams actually need.
Agentic AI as a productivity multiplier
Rather than fearing AI’s role in development, Kreilein sees agentic AI as an opportunity to help developers be more productive on the strategic work that creates good security outcomes.
“I have yet to meet the developer who doesn’t care about security,” he notes. However, they want something that is material and real and important and something that helps solve other problems. “The problem is not that this version is vulnerable. The problem is that I’m worried that upgrading to that version will be a breaking change.”
Agentic AI can help address the root causes: improving test automation, suggesting non-breaking upgrade paths, and handling the tedious work that keeps developers from addressing security issues promptly. “What I’m excited about for MCP servers, what I’m excited about for agentic AI, is helping people be more productive on the things that are strategic, that create the outcome of good security.”
Security architecture from the start
Kreilein draws on his background in standards engineering to emphasize a persistent problem: security teams aren’t involved in V1 of new protocols or systems. This leads to predictable failures, like WEP (Wireless Encryption Protocol), where “a bunch of engineers decided to roll their own crypto instead of using a known algorithm.”
The solution isn’t purely technical. It’s about changing when and how security participates in design. “Good systems design is about advocating for the whole system,” Kreilein argues. “Not just advocating for performance at the expense of security or cost at the expense of security, but integrating cost, security and performance as part of your decision calculation.”
He points to TLS 1.3 as a success story where the IETF specifically optimized the handshake to be more performant than 1.2 without sacrificing security. “That took hundreds of standards engineers thousands, if not tens of thousands of hours,” he acknowledges. “What I would like to see them do is instead of waiting for putting that improvement in 1.3, we find a way to integrate that analysis through better design reviews, architecture analysis, threat modeling, failure mode analysis, cost modeling in V1 or in V0.”
The role of regulation and market forces
While acknowledging that many in the US technology sector view European regulations as burdensome, Kreilein takes a contrarian view: “I see it as clarity and business certainty. They took the time to write down and tell me what I needed to do, and now I can fold that into my plan.”
He sees frameworks like CISA’s Secure by Design and Secure by Demand as helpful market signals. “I think Americans would be well served to understand the value of it,” he suggests, noting that prescriptive guidance removes uncertainty that slows progress.
The key is understanding that compliance represents a floor, not a ceiling. “Compliance is part of security, and it’s an important part of security because it gives you enforcement and mandate, which is helpful and very needed, but does not actually offer the outcomes that we want.”
Making attackers’ jobs expensive
Kreilein offers a counterintuitive security principle: release code more frequently, not less. “If attackers are effective because they gain persistence, that means time. The more ephemeral my code is, the less persistence they’re going to gain.”
By taking away the persistence that attackers need for success, frequent releases make attacks more expensive to execute. “If I can take away the one requisite attribute to their success, I make their job so much more expensive. If that’s true, shouldn’t I want to release every day?”
This challenges the traditional change management mindset that views releases as risky events to be minimized. Instead, Kreilein frames frequent releases as a security control. One that reduces the window for exploitation and limits the accumulation of dormant vulnerabilities.
The path forward
Kreilein’s vision for risk operations moves security teams away from endless vulnerability reporting toward strategic business partnership. This requires better tooling (like VEX-enhanced SBOMs), better engineering practices (like comprehensive test automation), and better collaboration between security and development teams.
“My excitement for this is that I think it’s possible to do that now, which is a real shift from our intention to our ability,” Kreilein concludes. The tools and frameworks exist. The question is whether organizations will embrace the cultural and operational changes needed to move from vulnerability whack-a-mole to genuine risk operations.
Also watch: Why your SOC needs a ROC