Why Your Security-by-Design Strategy Is Failing the Real World

TLDR: Most modern software development treats security as a bolt-on feature rather than a foundational requirement, leading to recurring classes of vulnerabilities like memory corruption and SQL injection. This talk argues that manufacturers must shift the burden of security from end-users to themselves by adopting memory-safe languages and transparent vulnerability reporting. Pentesters and researchers should focus on identifying these systemic design flaws rather than just finding individual bugs to help drive industry-wide change.

Security professionals spend an absurd amount of time playing whack-a-mole. We find a bug, we report it, the vendor patches it, and six months later, a different researcher finds the exact same class of vulnerability in a different part of the codebase. This cycle is not a sign of a healthy security industry. It is a sign of a broken manufacturing process. We are currently operating in an environment where the burden of security is placed entirely on the end-user, who is expected to manage patches, configure complex hardening guides, and monitor logs for systems that were never designed to be secure in the first place.

The Myth of the Secure Configuration

The industry has spent decades pushing the responsibility for security onto the customer. We see this in the endless stream of hardening guides that require a PhD in systems administration to implement correctly. If a product requires a 50-page document to be "secure," it is not secure by design. It is broken by design.

When we look at the OWASP Top 10, specifically A07:2021-Identification and Authentication Failures, we see the same patterns repeating. Default passwords, lack of multi-factor authentication, and weak session management are not technical accidents. They are choices made during the product development lifecycle. When a manufacturer ships a device with a default admin password, they are essentially handing the keys to the kingdom to anyone with a search engine.

Memory Safety and the Root Cause Problem

The most glaring example of this systemic failure is memory safety. We have known for decades that languages like C and C++ are prone to buffer overflows, use-after-free, and other memory corruption issues. Yet, we continue to build critical infrastructure on these foundations. When two-thirds of vulnerabilities in memory-unsafe languages are caused by memory safety issues, we are not looking at a series of unfortunate mistakes. We are looking at a fundamental flaw in our choice of tools.

For a pentester, this is the most frustrating part of the job. You spend days crafting a payload to exploit a buffer overflow, only to realize that the same class of vulnerability has been exploited in this specific product line for years. If you want to make a real impact, stop looking for the next zero-day in a legacy component and start looking at the architecture. Ask yourself: why is this component still written in a language that allows this class of vulnerability?

Shifting the Burden to the Manufacturer

The goal of the security-by-design movement is to force a change in the economic incentives of software development. Currently, it is cheaper for a manufacturer to ship a buggy product and let the customer deal with the fallout than it is to invest in secure development practices. We need to flip this model.

This starts with Software Bill of Materials (SBOM) transparency. If you are testing a product, you should be able to see exactly what components are inside it. If a vendor cannot provide an accurate SBOM, they do not know what they are shipping. As researchers, we should be pushing for this transparency as a baseline requirement. If we can identify the components, we can identify the risk.

What Pentesters Can Do Today

You are the ones on the front lines. When you are performing an engagement, do not just report the bugs you find. Report the design failures that allowed those bugs to exist. If you find a SQL injection, do not just provide the payload. Point out that the application is using raw queries instead of parameterized queries, which is a solved problem.

If you are a bug bounty hunter, look for patterns. If you find a vulnerability in one part of an application, check the rest of the codebase for the same pattern. Manufacturers are creatures of habit. If they made a mistake in one module, they likely made it everywhere. By reporting these as systemic issues rather than isolated bugs, you provide the data that security teams need to force a change in the development process.

We need to stop accepting the status quo where "secure" is a premium feature that costs extra. Security is a quality attribute, just like performance or reliability. If a product is not secure, it is not finished. The next time you are testing a system, look past the individual vulnerabilities and ask if the product was built to be secure or if it was built to be patched. The answer to that question is the difference between a secure future and the same old cycle of exploits.