Why We Need to Stop Calling Them Vulnerabilities and Start Calling Them Product Defects

TLDR: CISA Director Jen Easterly recently argued that the cybersecurity industry must shift its language from "vulnerabilities" to "product defects" to force accountability onto manufacturers. This change in framing aims to move the burden of security away from end-users and onto the companies shipping insecure code. For researchers and pentesters, this signals a shift toward focusing on systemic design failures rather than just individual bugs.

Security researchers have spent decades filing bug reports, chasing CVEs, and explaining the same classes of flaws to the same vendors. We find a buffer overflow, we report it, the vendor patches it, and six months later, another one appears in the same codebase. This cycle is broken. The recent conversation at DEF CON between CISA Director Jen Easterly and the security community highlighted a necessary evolution in how we talk about the software we break. If we want to move the needle, we have to stop treating every flaw as an isolated "vulnerability" and start treating them as what they actually are: product defects.

The Problem with the Vulnerability Label

Calling something a "vulnerability" implies that the flaw is an inherent, unavoidable risk of using technology. It sounds like a natural disaster or a force of nature. When a piece of software ships with a classic CWE-89: Improper Neutralization of Special Elements used in an SQL Command, we call it a vulnerability. But if a car manufacturer shipped a vehicle with a faulty brake line, we would call that a product defect. We would expect a recall, a lawsuit, and a fundamental change in the manufacturing process.

Software vendors have enjoyed a unique immunity from this standard. They ship products with CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer and expect the customer to handle the risk through patching, firewalls, or "robust security posture." By reframing these as defects, we shift the conversation from "how do we mitigate this" to "why did you ship this in a broken state."

Systemic Failure vs. Individual Bugs

For those of us in the trenches, this shift is more than just semantics. When we perform a penetration test, we often find ourselves documenting the same issues across different applications from the same vendor. If we categorize these as defects, we can start to map them to OWASP Top 10 categories not just as individual findings, but as evidence of a failed development lifecycle.

Consider the prevalence of CVE-2023-3519, a critical remote code execution flaw in Citrix ADC. When a vendor ships a product that allows unauthenticated remote code execution, that is not a minor oversight. It is a failure of the product's core design. If we treat these as defects, the focus moves from the specific exploit chain to the lack of memory safety or the absence of secure coding practices in the vendor's CI/CD pipeline.

What This Means for Your Next Engagement

Pentesters and bug bounty hunters are the ones who actually see the code quality. When you are writing your next report, consider how you frame your findings. Instead of just providing a proof-of-concept for a specific CWE-79: Improper Neutralization of Input During Web Page Generation, explicitly call out the lack of input validation as a defect in the application's design.

This approach forces the client to acknowledge that the issue isn't just a "bug" that can be ignored until the next maintenance window. It is a defect that reflects on the quality of their engineering team. When you present your findings to stakeholders, use the language of quality assurance. Ask them why their development process allowed a defect of this nature to reach production. This is the kind of pressure that forces organizations to invest in better tooling, static analysis, and secure development training.

Moving Toward Accountability

Defenders are already overwhelmed. They are drowning in patches and alerts for defects that should never have existed in the first place. By demanding that vendors take responsibility for the defects they ship, we are not just helping ourselves; we are helping the entire ecosystem.

We need to stop being the unpaid quality assurance department for the world's largest software companies. Every time you find a flaw that could have been prevented by basic secure coding standards, remember that you are looking at a defect. The next time you sit down to write a report, don't just describe the vulnerability. Describe the defect. Explain the failure in the manufacturing process that allowed it to exist. If we keep the pressure on the vendors to fix their processes, we might finally see a reduction in the volume of low-hanging fruit that currently consumes so much of our time.

The goal is to make the cost of shipping a defect higher than the cost of building it securely. We have the data to prove that these aren't just "vulnerabilities." They are failures of engineering, and it is time we started calling them out as such. Keep digging, keep reporting, and keep holding them to the standard that every other industry is held to.