Secure-by-Design Delusions

The challenges of contrasting cyber with other industries and glaring challenges with Secure-by-Design desires

CISA’s former Director, Jen Easterly, recently published an article on the organization’s website titled “Building a Secure-by-Design Ecosystem.”

The piece argues that we need to build a Secure-by-Design ecosystem. It emphasizes the work CISA has been doing around Secure-by-Design, from its publications to pledges and more, while drawing parallels to other industries, primarily the automobile industry.

I wanted to publish a contrasting piece, as Jen’s article really got me thinking.

But first, let me emphasize that this is not a critique of Jen or CISA. I recently wrapped up a stint as a Cyber Innovation Fellow (CIF) at CISA myself. I’m a big fan of Jen and her amazing work and impact. She will continue to have a role in our digital ecosystem, along with all of the incredible people at CISA with whom I’ve had a chance to collaborate and whose work I often share in my various writing, speaking, networking, and more.

That said, I do think there are pitfalls and challenges in contrasting cybersecurity with industries such as automobiles, as well as the Secure-by-Design push more broadly, some of which I’ve covered in other pieces, such as:

• A Digital Scouts Honor: A look at the recently announced Secure-by-Design Pledge led by CISA

• Secure-by-Design (and Demand): A look at the new CISA Secure-by-Design publication

Acknowledgment

First off, let’s acknowledge the incredible work of the CISA team and Jen when it comes to Secure-by-Design, which the article also covers, such as:

• Secure-by-Design Pledge - in May 2024, CISA launched their SbD pledge, which has scaled from 68 to 250+ signatories

• Industry SbD Leadership - CISA isn’t in this alone, as industry leaders such as Google and Microsoft have launched similar/well-aligned efforts related to SbD

• CISA’s Launch of SbD - CISA launched SbD with their original paper “Shifting the Balance of Cybersecurity Risk” in April 2023. The publication is full of great topics and recommendations for a systemic SbD shift

---

---

Interested in sponsoring an issue of Resilient Cyber?

This includes reaching over 30,000 subscribers, ranging from Developers, Engineers, Architects, CISO’s/Security Leaders and Business Executives

Reach out below!

---

Challenges

Now, we will discuss some challenges related to SbD and attempt to draw parallels to other industries, such as automobile manufacturing.

The framing in the CISA article, and in many SbD publications, is to draw parallels with the immaturity of Cybersecurity, which is arguably still in its infancy, and more mature industries such as pharmaceuticals, medical, and automobile manufacturing, the latter of which has gotten the most contrasts.

Jen’s article discusses how, in the mid-20th century, we had a crisis on the roads with poorly designed cars, high rates of injuries, and even death until automobile manufacturers were pushed to adopt more security and safety features to lead to systemic risk reduction (e.g., seat belts, airbags, and anti-lock brakes).

She goes on to state that we’re in the “before seat belts” era of software, where unsafe car design and highly consequential incidents led to widespread changes in design, development, and production.

I think we should unpack some challenges here that go beyond the parallel with automobiles and speak to the nuanced, unique nature of software and cybersecurity more broadly.

Automobile vs. Software Manufacturers

The first glaring one is simply the insane scale difference between Automobile vs. Software Manufacturers.

While estimates vary, and I used various sources to try and pin down exact figures, there are roughly 12-15 “major” automobile manufacturers and roughly < 1,000 when expanding beyond the giants that dominate the industry.

Looking at Software, of course, there is market dominance, with 10-20 giants (Microsoft, Oracle, SAP, IBM, Salesforce, et al.) controlling large portions of the market. However, thousands of others exist in niches such as Cybersecurity, Data Management, Design and Collaboration, HR, and more, and zooming out further, there are literally hundreds of thousands of software suppliers.

Unlike automobiles, which are capital-intensive endeavors requiring large CapEx investments, industrial manufacturing, physical facilities, equipment, labor forces, and more, software is much more democratized.

Software can be built and distributed by as little as a single person with a laptop and an Internet connection, and increasingly with the rise of GenAI/LLMs and copilots, at a rampant rate, and by some with limited to no development expertise.

Couple that with copilots and GenAI; some even speculate that we may see single-person companies that achieve “unicorn” status in the future. While this is more on the side of hype, it drives home the point that software is distinctly different in terms of development, distribution, and access than automobiles.

We have thousands of organizations producing software, and when scaling out to include the open-source ecosystem, we have hundreds of thousands to hundreds of millions of repositories. It may be tempting to say, "Well, that is open source, not commercial suppliers," but then we must be reminded that 97%~ of commercial code bases contain open source, and in fact, open source makes up 70%+ of those code bases entirely. The number of open source components in products has tripled in the last four years alone.

Source: 2024 OSSRA

To help explain the incomprehensible size of open source, which, as I mentioned, powers most modern applications and software, take a look at the chart below from Josh Bressers's blog post titled “Open Source is Bigger Than You Imagine.” It is worth noting that this chart depicts just the NPM package repository, let alone the entire OSS ecosystem.

Yes, that is 30 million packages in one of the major package repositories.

So, the commercial software ecosystem is significantly larger and different from automobiles. Millions of open-source components, projects, and libraries overwhelmingly power it. That is another key distinction from automobiles, which have clearly defined and documented supply chains and aren’t overwhelmingly run on pieces and parts randomly found on the Internet from anonymous and opaque sources.

Another key point to call out here is that while the automobile industry is a traditional “vertical,” software (and, by extension, cybersecurity) is horizontal.

Software and its security touch nearly every aspect of society, from consumer goods to critical infrastructure and national security weapons systems. It powers our medical facilities, schools, water treatment facilities, Federal agencies and civil institutions, law firms, digital consumer commerce, and the list goes on—you get the picture.

Software touches everything.

Safety, Ratings, and Penalties

Another angle underway is prescribing ratings for software-enabled products. Most notable here is the U.S. Cyber Trust Mark Initiative. The program is voluntary (emphasis on this word is intended) and focuses on “smart” IoT and connected devices. It aims to provide consumers with insight into which Internet and Bluetooth-enabled devices are “cybersecurity.”

The most common parallel drawn is related to that of the Energy Star programs, where products are rated and marked based on their purported energy efficiency. The program will involve organizations such as UL and some form of third-party collaboration for product testing and labeling. When consumers scan QR codes, it will provide them with information about the product, such as:

• How to change the default password

• How to configure the device securely

• Whether updates/patches are automatic and, if not, how consumers can access them

• The product's minimum support period end date or a statement that the device is not supported by the manufacturer and the consumer should not rely on the manufacturer to release security updates
  

It is a bit of irony that, among the push for Secure-by-Design/Default, the information provided to the consumer will include how to configure the device securely, something that CISA has been pushing for the vendors themselves to do and is the underlying theme of Secure-by-Default in particular.

Nonetheless, you can see how we’re moving towards creating similar schemes for software-enabled consumer products as we are with other industries, such as energy efficiency or crash test ratings.

Again, this is a voluntary program, and there aren’t necessarily penalties that will drive significant changes initially. However, it is easy to see how vendors may view the cyber trust mark as a competitive differentiator. Ideally, it is a signal that drives changes in consumer spending patterns, which has the upstream impact of potentially changing vendor security practices for their product design, development, and distribution.

Vulnerabilities

Jen’s piece calls for more software vendors to become Common Vulnerability and Exposure (CVE) Numbering Authorities (CNAs). For those unfamiliar, CNAs can submit vulnerabilities (CVEs) to be tracked by MITRE and, subsequently, the NIST National Vulnerability Database (CVE).

While I agree that we need more software vendors functioning as CNAs, this CNA growth would also exacerbate existing challenges in the vulnerability ecosystem.

While entire books have been written and can be written on Vulnerability Management (I know because I wrote one myself, “Effective Vulnerability Management,” for example), the vulnerability management ecosystem has some very specific issues.

The same NVD I mentioned above collapsed in 2024 when it stopped enriching and enumerating new CVEs. This impacted the entire industry, which still relies on it as the most widely used and cited vulnerability database.

I captured some of the early impacts and ramifications of the NVD collapse in a piece titled “Death Knell of the NVD?” and in an interview with industry leaders Josh Bressers and Dan Lorenc titled “Untangling the NVD Chaos.”

The NVD demonstrated it is struggling with the current scale and pace of vulnerabilities, and as more software vendors become CNA’s, coupled with improved vulnerability research, reporting/disclosure, and the ability of AI to facilitate vulnerability discovery, the problem is only going to get exacerbated. At the time of this writing the NVD still hasn’t fully recovered from its collapse in 2024, and is working on a backlog of vulnerabilities to enrich.

There are of course other vulnerability databases, which I tried to capture in a piece titled “An Incomplete Look at Vulnerability Databases & Scoring Methodologies”. So we have a disparate ecosystem of bespoke vulnerability databases with complimentary, contradictory and duplicative data for organizations to wrestle with.

Flipping to the organization side of the equation, vulnerability backlogs are reported to be in the hundreds of thousands to millions, as organizations are drowning and can’t keep up mitigation and remediation efforts with the rate of vulnerabilities coming at them.

It’s no surprise organizations are drowning either, as Vulnerability Researcher Jerry Gamblin recently shared that CVE’s are currently seeing 48.37% year-over-year (YoY) growth in 2025 compared to 2024, which also saw double digit growth (as did the year before it).

Organizations simply can’t keep up with the number of vulnerabilities associated with software.

In fact, this reality is one of the primary reasons as a society we desperately need a Secure-by-Design ecosystem like Jen and CISA advocates for, as well as for software suppliers to take more accountability for the vulnerabilities in their products, given they are best positioned to address the issue - as articulated in the latest U.S. National Cybersecurity Strategy (NCS), as seen below:

The problem is, we’re unlikely to get that, given various dynamics at play in the U.S. and around the world.

Secure-by-Design Itself

Another fundamental and significant challenge with the Secure-by-Design push is that it is far from a new concept. As I wrote in the piece “Cybersecurity First Principles and Shouting Into the Void”, the concept of building security in rather than bolting it on traces back over 50 years, to sources such as The Ware Report.

Jumping a few decades forward, 20 years ago, Carnegie Mellon in collaboration with the Department of Homeland Security launched their “Build Security In” portal, which “offers best practices, tools and other resources to help software developers, architects and security practitioners create more secure and reliable software.”

In a twist of irony, when I visited the page, it now redirects to CISA’s Secure-by-Design page.

What a weird strange trip its been, for 20 years to go by and have the concept repackaged and pushed, but still facing the same challenges.

The primary issue is:

We’re best practices rich but implementation poor.

As an industry, we’re up to our eyeballs in “best practices”, guides, publications, frameworks and more. From sources such as NIST, OWASP, Cloud Security Alliance, BSIMM and many, many others.

All of these best practices are of little utility if vendors aren’t incentivized to adopt and implement them, either by market forces or regulatory dynamics, both of which seem lacking, as I’ll discuss below.

While I applaud the Secure-by-Design effort CISA, there are some significant challenges and harsh realities that are worth discussing. I recently saw some celebratory posts on LinkedIn and even awards being given out for “Making Secure-by-Design a Reality”, and well, I think we’re not quite there and may want to hold the champagne for now.

The Secure-by-Design effort from CISA again is a voluntary pledge that organizations take. As I have discussed several times, many of the signatories are cybersecurity companies, who of course are incentivized to push the Secure-by-Design narrative since their products, services and associated revenues are driven by security spend/investment.

There are currently 283 signatories of the pledge and only 7.5% have provided any updates for the Secure-by-Design Pledge Progress Report, and of those who have provided any update, 75% of those again come from security companies. Those are firms who are incentivized to drive the Secure-by-Design mantra as a market narrative to drive purchases of their products. Keep these figures in mind, with our discussion above about the fact that there are thousands of software providers, and the number continues to grow with the democratization of development, and GenAI.

The voluntary nature is accompanied by a lack of any actual validation of said implementation. If you want an example of how self-attestation voluntary efforts go, take a look at the Department of Defense (DoD) where the compliance regime NIST 800-171 for the Defense Industrial Base (DIB) failed miserably, as organizations who claimed compliance have experienced several breaches contradicting their claims, leading to the creation of the Cybersecurity Maturity Model (CMMC).

Or for another closer to home example, CISA has their own “Cross-Sector Cybersecurity Performance Goals (CPG)’s” for U.S. Critical Infrastructure. These are voluntary goals for critical infrastructure providers and in early 2025 CISA provided a report on CPG adoption.

The percentage of ALL critical infrastructure entities that met the CPGs?

2%.

Yes, just 2% of all critical infrastructure entities met the voluntary-based CPGs.

Let’s take a look at the signatories. One that jumps out is Fortinet. Despite feel good press releases and self-congratulatory public virtue signaling, such as signing the Secure-by-Design Pledge, Fortinet’s year in 2024 revealed something a bit different, with several highly visible security incidents, active exploitation, numerous zero day discoveries and associated incidents impacting customers and consumers, ironically enough, including the U.S. Federal government.

Surely there will be some market reactions to this rough security year Fortinet had, given we continue to hear about market share, financial losses, customer trust and any other FUD-driven lines from security practitioners trying to drive security investment and prioritization?

Not quite.

In fact, Fortinet was the best performing public cybersecurity company in 2024, despite the security incidents, numerous zero days, active exploitation and impact on customers, including Government agencies.

Fortinet shows no signs of slowing down despite security slip ups either, as their stock soared in Q4 2024, as their revenue demonstrated double digital 17% year-over-year (YoY) growth, with revenue totally $1.66B and approaching the coveted $100B market cap, sitting at $80B roughly at the time of this writing.

I don’t want to just pick on Fortinet though, because while they are a great example, they’re far from the only one.

Everyone’s favorite Microsoft demonstrates similar behavior. While continuing to grow, boasting tens of billions in security revenue alone, Microsoft had several notable security incidents in the last 24 months alone, including impacting several U.S. Federal agencies, being called a “national security threat” by members of Congress, and being investigated by Cyber Safety Review Board (CSRB) and continue to reign supreme at the top of the CISA Known Exploited Vulnerability (KEV) list.

They did all of this while concurrently pulling down massive Federal IT contracts.

Microsoft did try and release what they have called the “Secure Future Initiative” which focuses on Secure-by-Design, Secure-by-Default and Security Operations. Microsoft’s CEO even released a memo titled “prioritizing security above all else”.

There’s just a couple of issues with this. First, that simply isn’t how businesses operate. While “security above all else” may sound and feel good, and alleviate some of the concern around Microsoft’s insecurity and negative PR, the reality is that businesses don’t exist for security, they exit to generate value for shareholders and we can rest assured that security will not come ahead of competing pressures such as speed to market and revenue.

Secondly, if you’re thinking that messaging from Microsoft sounds familiar, that’s because it is a repackaging of Bill Gate’s “Trustworthy Computing” memo from 20+ years earlier, after Microsoft experienced another series of highly public and damaging security challenges.

I discuss this in my previous article “Systemic Concentrated Cyber Risks: Discussing monocultures, systemic dependencies and digital fragility”, which I wrote in the wake of the Crowdstrike incident. In that article I discuss a paper authored 22 years ago by security legends Dan Geer and Bruce Schneier titled “CyberInsecurity: The Cost of a Monopoly: How the Dominance of Microsoft’s Products Poses a Risk to Security”.

Microsoft continues to experience incredible success, even pulling down tens of billions in security revenue itself.

There are of course nuances and context involved here too, industry leading companies are more enticing targets for attackers, due to their out-sized footprint across the ecosystem and broad adoption and use of their products.

That said, heavy is the head that wears the crown as they say, and we can’t ignore the realities of incidents and exploitation just because a company is financially successful.

Well, we can, and do, but perhaps shouldn’t.

Closing Thoughts

None of this is intended to disagree with the concept of Secure-by-Design, or the fact that we should be building security in, rather than bolting it on, as we like to say. Nor is it intended to be a negative critique of the amazing people doing work to create a more resilient digital ecosystem.

In fact, I have been actively trying to do exactly that as a cyber practitioner with 20+ years of experience throughout my career.

It is however an attempt to bring us back to reality and point out that while we may be in love with the idea of putting security on par with competing incentives such as revenue and speed to market, how that plays out in real life is much different than in our vision.

Now, perhaps consumer sentiment changes and incidents begin to drive changes in purchasing patterns and/or we see more rigorous cybersecurity regulation that drives changes in behavior from software vendors (although this is unlikely under the new U.S. presidential administration which is taking a much more deregulatory approach).

That remains to be seen, and for now we have to keep doing the best that we can to drive systemic changes in behavior from software vendors, consumers, work to improve the relationship between security <> developers and more, all in hopes of driving a Secure-by-Design ecosystem.

I’m doing my best, and I know many others are too.

But, we have to be sure we’re doing it with eyes wide open to reality.