CISA’s Secure by Design initiative has been building momentum throughout 2025, and this week’s updated guidance and the growing list of vendor commitments signal that we might be witnessing a genuine shift in how the software industry approaches security. After decades of treating security as an afterthought — something to bolt on after shipping — the regulatory and market pressure is converging to make “secure by default” more than just a slogan.
From Voluntary Pledges to Industry Expectations#
When CISA first launched the Secure by Design pledge earlier this year, I was cautiously optimistic but skeptical about enforcement. Voluntary commitments in tech have a mixed track record, to put it diplomatically. But the landscape has shifted faster than I expected.
Over 200 software companies have now signed the pledge, committing to concrete actions like eliminating default passwords, implementing multi-factor authentication by default, and reducing entire classes of vulnerabilities. More importantly, major enterprise procurement teams are starting to use pledge compliance as a vendor selection criterion. When security commitments affect revenue, they tend to get taken seriously.
The updated guidance released this week adds more specific technical recommendations around memory-safe languages, SBOM (Software Bill of Materials) requirements, and vulnerability disclosure timelines. These aren’t revolutionary ideas — the security community has been advocating for them for years — but having them codified in government-backed guidance gives engineering teams ammunition to justify the investment to business stakeholders.
The Memory Safety Conversation Gets Practical#
One of the most impactful elements of CISA’s push has been the emphasis on memory-safe languages. The NSA and CISA guidance recommending migration away from C and C++ for new projects has moved from “interesting recommendation” to “thing procurement officers ask about.”
I’ve been writing software long enough to remember when buffer overflows were considered an inevitable cost of doing business. The data is unambiguous — memory safety issues account for roughly 70% of serious vulnerabilities in large C/C++ codebases, according to studies from Microsoft and Google. The industry push toward Rust, Go, and other memory-safe alternatives isn’t just about developer preferences; it’s becoming a supply chain security requirement.
What’s practical about CISA’s approach is that they’re not demanding immediate rewrites of legacy systems. The guidance focuses on new development and critical components, which is the only realistic path forward. You can’t rewrite 40 years of C infrastructure overnight, but you can make sure your new HTTP parser or TLS implementation uses a language that won’t let you accidentally create a remote code execution vulnerability.
Supply Chain Security Matures#
The SBOM requirements that are now being woven into government procurement and increasingly into private sector contracts represent the other major shift. After the SolarWinds and Log4j incidents demonstrated how fragile software supply chains can be, the industry has been slowly building the tooling and processes to actually track what’s in our software.
Tools like Syft, Trivy, and the SPDX/CycloneDX standards have matured significantly. Most CI/CD pipelines can now generate an SBOM as part of the build process with minimal friction. The challenge has shifted from “how do we generate an SBOM” to “how do we make SBOMs actionable” — meaning, how do you efficiently correlate a newly discovered vulnerability against every deployed system that contains the affected component?
This is where I think the next wave of innovation will happen. The generation problem is largely solved. The consumption and response problem is where most organizations still struggle. When the next Log4j-scale vulnerability drops, can your organization answer “are we affected?” in minutes rather than days?
The Developer Experience Gap#
My one concern with the Secure by Design push is the developer experience gap. Security tooling has historically been built for security teams, not for developers. When you mandate SAST scans, dependency checks, and SBOM generation in every pipeline, you need those tools to be fast, accurate, and low-friction — or developers will find ways to work around them.
The best security tools in 2025 are the ones that feel invisible. GitHub’s Dependabot, Snyk’s IDE integrations, and similar tools that surface vulnerabilities at the point where developers can actually fix them — in the editor and in the PR — represent the right model. The worst are the ones that generate 500-item reports of mostly false positives that nobody reads.
My Take#
I’ve lived through enough security “revolutions” to be wary of declaring victory prematurely. But CISA’s Secure by Design initiative feels different because it’s attacking the problem from the economic side, not just the technical side. When secure software becomes a procurement advantage and insecure software becomes a liability, the incentive structure changes fundamentally.
For engineering teams, my advice is straightforward: if you haven’t already, integrate SBOM generation into your build pipeline this quarter. Evaluate your new projects’ language choices through a memory safety lens. And read the CISA guidance — it’s surprisingly practical and well-written for a government document.
The window to be ahead of these requirements is closing. Better to adopt them voluntarily now, on your own timeline, than to scramble when they become contractual obligations.