Why Your "Secure" Software Supply Chain is Still Running on 2007-Era Vulnerabilities

TLDR: Despite decades of industry focus on advanced threat hunting, the vast majority of critical infrastructure compromises still stem from the same "unforgivable" memory safety and injection vulnerabilities identified by MITRE in 2007. This keynote argues that we have normalized these defects as inevitable, shifting the burden of security onto the victim rather than the vendor. Pentesters and researchers should stop treating these as "interesting" findings and start framing them as fundamental product defects that demand vendor accountability.

Security researchers often fall into the trap of chasing the latest zero-day or complex chain, ignoring the fact that the most effective way to compromise a target remains the same as it was fifteen years ago. We spend our time hunting for exotic logic flaws while the front door is left wide open by basic memory safety violations and classic injection bugs. The industry has collectively decided that these vulnerabilities are just part of the cost of doing business, a "natural disaster" that we are powerless to prevent. This mindset is not just lazy; it is dangerous.

The Myth of the Sophisticated Attacker

When we talk about threat actors like Lazarus Group or Volt Typhoon, we often frame them as masterminds wielding an endless supply of novel exploits. In reality, these groups are highly effective because they don't need to be creative. They rely on the fact that we have failed to address the low-hanging fruit.

The OWASP Top 10 has consistently featured Injection and Identification and Authentication Failures for a reason. These are not technical challenges that lack a solution; they are design choices that prioritize speed-to-market over basic safety. When a vendor ships a product that is vulnerable to SQL Injection or Directory Traversal, they aren't just making a mistake. They are shipping a defective product.

Why We Need to Stop Calling Them "Vulnerabilities"

Calling these issues "vulnerabilities" is a linguistic trick that diffuses responsibility. It implies that the flaw is an inherent property of the software, like a natural feature of the landscape. If we instead call them "product defects," the conversation changes. A car manufacturer wouldn't ship a vehicle with a faulty braking system and then blame the driver for not being a professional mechanic. Yet, in software, we expect the end user to "patch" their way out of a fundamentally broken design.

For a pentester, this means the engagement often starts and ends with the same set of checks. If you are still finding T1190-exploit-public-facing-app or T1566-phishing on a regular basis, you aren't just testing the security of the application; you are documenting the negligence of the vendor.

Consider the following common pattern in legacy enterprise software:

-- Classic injection vulnerability in a login module
SELECT * FROM users WHERE username = '$username' AND password = '$password';

If you can still drop a payload like ' OR '1'='1 into that field in 2024, the issue isn't the lack of a WAF or a missing security patch. The issue is that the vendor failed to use parameterized queries, a standard practice for over two decades. This is not a "sophisticated" finding. It is a failure of basic engineering.

The Shift to Secure by Design

The Secure by Design initiative is an attempt to force this conversation back to the source. It isn't about adding more security tools to the stack; it is about demanding that the software we procure is built to be resilient from the start. For researchers and bug bounty hunters, this means your reports should be more than just a proof-of-concept. They should be a clear indictment of the development lifecycle that allowed such a defect to reach production.

When you file a report, don't just explain how to exploit the bug. Explain why the architecture failed to prevent it. If you are testing a product that requires constant, urgent patching to stay secure, you are dealing with a "canary in a coal mine." These products are not just insecure; they are a liability to the entire supply chain.

What Pentesters Should Do Next

We need to stop being the cleanup crew for bad engineering. On your next engagement, look beyond the immediate exploit. Ask the client about their procurement process. Are they asking their vendors if they have signed the Secure by Design Pledge? Are they evaluating the vendor's commitment to memory-safe languages?

If we continue to accept the status quo, we are just enabling the cycle of "patch-and-pray" that has defined the last twenty years of our industry. The goal should be to make our jobs as security professionals obsolete by forcing the market to produce software that doesn't require a constant stream of security researchers to keep it from falling apart. It is a hard problem, but it is not an impossible one. We have the technical knowledge to build secure systems. Now we just need the collective will to demand them.