Remote profile

Start with customer field studies (C-10), threat models (C-08), and the cost of your recurring classes of coding error (Q-02).

Myth: "Our products are already SbD”
Reality: The incentives and steady stream of breaches make that unlikely.

While some manufacturers have made genuine progress reducing recurring classes of coding error, the industry as a whole has not. It's important to separate effort from outcomes — hiring an appsec team and acquiring tools are necessary but not sufficient to reduce customer harm.

If the cards this month made you nod, confused, or mad, maybe you want a deck for yourself or someone you know. Order here!
https://www.drivethrucards.com/en/product/584466/secure-by-design-story-cards-v2-4

That’s the idea behind the Secure by Design Story Cards: 90 cards that break the core ideas of secure-by-design software into small pieces you can pick up, argue with, and bring into engineering reviews, board meetings, procurement calls, and policy debates.

They’re written for everyone who shapes software security: makers, buyers, executives, regulators, developers. The problem doesn’t respect org charts, so the conversation shouldn’t either.

Every security update you rushed to install this month exists because a software manufacturer shipped a security defect in the first place.

The operator is the last line of defense. The manufacturer is the first. This month’s advice is almost all about the last.

📣 Cybersecurity Awareness Month asks operators to try harder. We spent it asking software manufacturers to ship better.

Since Oct 1, Lauren Zabierek and I have each posted one Secure by Design Story Card a day. By tomorrow: 62 of 90.

Why did we do this?

October is full of well-meaning advice for operators: install updates, turn on MFA, watch for password theft scams. None of it is wrong. But all of it points our attention downstream.

#SecureByDesign #CybersecurityAwarenessMonth

Systemic harm was being designed into everyday products. Insecure software is no different: a defect travels the supply chain to people who never bought it, booked as a breach at the buyer, not a defect in the product.

Harm nobody counts looks like no harm at all.

In 1962, Rachel Carson published Silent Spring. DDT was a Nobel-winning miracle chemical, sprayed everywhere. Carson showed it climbed the food chain, thinning eggshells of birds that never went near a field. Her title is the harm: a spring with no birdsong. The US banned it for agriculture ten years later.

Myth: “A secure laptop will cost $10k!”
Reality: Reality: The cost is already being paid, just not by the manufacturer.

Customers buy tools, staff teams, and absorb incidents to compensate for defects they did not create. Fixing a defect class upstream costs once. Mitigating it downstream costs once per customer, every year (see E-05).

The question isn't what secure software costs. It's why the expensive version is the one we chose.

The secure-by-design movement is a visionary project. Which "V" are you?

The Visionaries are those who see a better future and are working to build it.

They are the researchers, regulators, advocates, engineers, and executives who believe that software can and must be safer. They understand that the market won't fix itself — that structural change requires structural intervention.

Visionaries push for memory-safe languages, secure defaults, liability reform, and transparency. They build coalitions, shift incentives, and prove that safer software is possible.

Selling into the EU means designing for a reporting clock, not just a standard.

The EU's Cyber Resilience Act (Regulation 2024/2847) is the first EU-wide law imposing binding product security requirements on software and connected hardware, regardless of where the manufacturer is based.

Since September 11, 2026, manufacturers must warn their national CSIRT within 24 hours of learning a defect is actively exploited, notify fully within 72 hours, and file a final report within 14 days of a fix being available. ENISA sees all of it. Full requirements apply December 11, 2027.

Some vendors are beginning to change. They publish roadmaps to eliminate defect classes, bring developers with security expertise in early, and treat customer safety as a core metric.

The Vendors:
The Vendors are the software manufacturers who build and ship the products.

Today, most vendors can externalize the cost of insecure software onto customers and society — through EULAs, disclaimers, and the absence of legal accountability. This creates a market where the incentive to invest in security is weak.

Thirty years in, adaptability explains the pressure. It does not excuse the outcome.

Myth: “Attackers keep adapting”
Reality: The difference is real. A fire captain fights physics: unpredictable, indifferent, not trying to win. An army captain fights someone who can wait, feint, spend more, and come back tomorrow.

You fight an intelligent adversary by changing the landscape and raising the cost of their campaign. That argues for secure by design, not against it. Eliminating the Lucky 13 (see UV-01) does both; patching instances does neither.

Until incentives shift, the market will reward unsafe software.

Market Forces & Effects:
The software industry isn't a free and fair market — not when it comes to security.

High switching costs, vendor lock-in, and market concentration reduce competition. Information asymmetries prevent buyers from assessing product security. The result is a classic market failure:

• Secure software is underproduced
• Private costs to manufacturers are low
• External costs are borne by customers and national security

Elevating an opportunistic break-in to a spy-movie threat actor moves attention away from the mundane design failure that let it happen, an outcome that benefits the manufacturer whose product failed.

Myth: “It was a sophisticated attack”
Reality: Most breaches described in headlines as a "sophisticated" or "advanced" attack start with an ordinary technique: a phished credential, a social-engineered helpdesk call, a login with no MFA. The sophistication is rarely in the intrusion, it's in the story told about it afterward.

Do not judge me, but Department Story Christmas is back on @somafm !

I can almost taste the Frango Mints...

Join me!

https://somafm.com/deptstore/

Thanks to everyone who made that project happen!

https://www.cve.org/Media/News/item/blog/2026/10/20/CVE-Program-Validation-Library

Sometimes important work happens without fanfare. When CNAs submit CVE records, the system validates them against some basic standards. Last month, that validation code was refactored into its own library.

Now that the validation code is its own library, CNAs can run it in-house to ensure their CVE record submissions will not be rejected. It's also now easier to add additional validation code to raise the bar on record quality.

A VDP should be a baseline expectation for any software manufacturer.

Vulnerability Disclosure Policy:
A Vulnerability Disclosure Policy (VDP) defines how a software manufacturer will receive, respond to, and credit reports of security defects from external researchers.

A VDP signals to the security research community that the manufacturer is open to receiving vulnerability reports in good faith. Without a VDP, researchers often have no safe channel to report issues — and the manufacturer never learns of the defect, or learns of it only when it becomes public.

The right question isn't "Why would anyone try to compromise our customers via our product?" It's "How do I protect them from attackers who will exploit any weakness?"

Myth: "Our products are not targets"
Reality: If your products connect to anything valuable, they are a target.

Attackers aren't always aiming at your product specifically. They look for access, leverage, and opportunity. Most successful attacks don't start with a named target but with a weakness in code or a misconfigured setting. As AI drives down the cost of reaching each target, being small stops working as protection (see AI-07).

Other safety-critical professions require licensure built on the four Es: Education, Examination, Experience, and Ethics. A civil engineer or physician can lose the right to practice.

Software developers are routinely called "engineers," borrowing that credibility, but the title carries none of the accountability. There is no licensing exam, no ethics board, no credential to revoke.

The word implies a standard the field has never adopted.