Signs of hope for Secure by Design

Finally, some potential incentives!

When Secure by Design was launched a few years ago, I was critical of the fact that it:

1. was voluntary

2. lacked clear financial incentives to adopt

3. included signatories that continue to get their customers breached through inaction and poor security practices

A few years later, software exploitation is now the most common method of initial access in attacks¹.

I love the idea of incentivizing building more secure software, but software vulnerabilities leading to breaches haven’t been enough to move the needle. It’s easy to say that applying secure-by-design principles is the right thing to do, but it’s harder for software companies concerned with margins and competition to justify it.

However, a handful of class action lawsuits give us reason to hope. Progress Software’s MoveIT file transfer product led to hundreds of breaches back in 2023, which resulted in lawsuits that are still ongoing. Twice now, Progress has tried getting federal courts to toss out negligence claims and both times, it failed.

The potential for new incentives

Legal Liability: If customers can successfully sue the makers of vulnerable software for damages related to using that software, secure-by-design principles could get prioritized by software vendors. Software liability is not a new topic, and I doubt a few class actions will be enough to set the precedent we need for industry-wide change, but it would be a start.

Impact to Trust/Reputation: It is hard to imagine why anyone would continue to use products from vendors that regularly cause their customers to get breached, but there is evidence that this has significantly damaged the reputation of these companies and led to significant customer loss. Promising to do better in the future only works so many times. In any other market, unsafe products would get recalled and pulled from the market until fixes were applied.

Insurability: Even if a legal precedent is not set, a similar impact could come from cyber insurance, where using known risky software could increase your premiums or prevent you from getting coverage entirely.

When the risk of using legacy products is too high

A month ago, I introduced the concept of ‘vulnerability body counts’², which quantifies the damages that result from vulnerability exploitation. For example, the MoveIT vulnerabilities that triggered these lawsuits have resulted in at least 750 individual breaches³. Instead of viewing vulnerabilities and exploits in isolation, it makes sense to start considering whether some products are more likely to yield a higher quantity of critical vulnerabilities than others.

From a TPCRM and vulnerability management perspective, we can now assess when the risk of using a product is too high, even when fully patched and supported. Consider when:

1. a product is highly targeted by attackers

2. a product is exposed and reachable

3. patches are not reaching customers quickly enough

4. product design is inherently insecure

What should we do with this signal? I introduced the idea of IT asbestos last year, and I think this product qualifies. These are products that are:

1. Placed in exposed positions

2. Have ancient codebases built without secure by design principles, in non-memory-safe languages⁴

3. Are not receiving the necessary funding or attention to make them safe and secure to use (in other words, they’re not getting any better)

4. Leveraging legacy protocols or methods that have become obsolete, due to more secure methods and protocols (e.g. ZTNA remote access technologies instead of SSL/PPTP/L2TP VPN)

5. Constantly scanned for by attackers - particularly initial access brokers looking to gain footholds into enterprises that they can sell to the highest bidder

Conclusion

There are software products on the market that are simply too much of a liability to use. Even when fully patched and configured securely, they represent far more risk than their more modern, secure-by-design counterparts.

In the past, tech debt was typically defined by the use of systems or software that were no longer supported or had reached end-of-life. I think it’s time to extend this definition to processes and protocols that are inherently less secure than alternatives, and by extension to the products that depend on antiquated processes and protocols⁵.

The evidence we have on how breaches happen tells us that the technologies that originally made the Internet useful for businesses are now liabilities that attract attention from attackers. Only when buyers reward vendors who embrace Secure by Design will we see the change we need in the market. Simply signing the pledge was never enough - adherence to these principles must be demonstrated.

1. According to the Verizon 2026 Data Breach Investigations Report

2. A vulnerability that has resulted in two confirmed breaches (like the Struts2 vuln that was used to breach Equifax) has a body count of two. A vulnerability that has resulted in 1000 breaches, like CVE-2024-40766, used very effectively by the Akira ransomware group, has a body count of 1000+. The vast majority of vulnerabilities, even actively exploited vulnerabilities, have a body count of zero. My hope is that this concept makes it clear that not all exploitable vulnerabilities represent equal amounts of risk to the community.

3. According to Verizon’s excellent and very useful VERIS Community Database

4. A little C++ from 2002 never hurt anyone, right?

5. e.g. using FTP/SFTP/SCP for file transfers - see my post on IT Asbestos for more examples