Make memory safety a product roadmap, not a patching promise

Source fact: memory-safety defects are a persistent vulnerability class

CISA, NSA, FBI, and international cybersecurity authorities describe memory-safety vulnerabilities as among the most prevalent classes of disclosed software vulnerability. Examples include buffer overflows, use-after-free errors, uninitialized memory, and double-free conditions. Successful exploitation can expose data, corrupt execution, crash a service, or allow unauthorized code execution.

The joint guidance explains that memory-safe programming languages move much of the responsibility for valid memory access from individual developers to the language, compiler, or runtime. The agencies urge software manufacturers to create and publish memory-safety roadmaps rather than relying indefinitely on training, testing, and patches to compensate for the same recurring class of defect.

NSA separately recommends using memory-safe languages when possible and applying code-hardening defenses when unsafe languages must remain. CISA’s analysis of critical open-source projects also emphasizes a dependency boundary: an application written in a memory-safe language may still rely on libraries or interfaces containing memory-unsafe code.

Source fact: memory safety is not the same as complete software security

A memory-safe language can prevent or sharply reduce specific memory-handling errors; it does not automatically prevent broken authorization, injection, insecure design, logic errors, weak cryptography, exposed secrets, or unsafe deployment. Native extensions, foreign-function interfaces, embedded libraries, and operating-system components may preserve memory-unsafe paths inside an otherwise safe product.

A useful roadmap therefore describes boundaries and evidence. A claim that a product “uses Rust,” “uses a managed runtime,” or “has secure coding training” does not reveal which high-risk components remain unsafe, whether dependencies are covered, or whether new unsafe code is still being added.

DSE recommendation: establish a defensible baseline

For internally developed software, inventory languages by repository and component, including generated code, firmware, drivers, third-party libraries, native extensions, build tools, and transitive dependencies where evidence is available. Identify components exposed to untrusted network traffic, files, media, device input, or privilege boundaries. These are often better early targets than choosing projects only by line count.

For purchased products, ask the manufacturer for a roadmap that identifies accountable leadership, scope, milestones, treatment of open-source and third-party dependencies, criteria for exceptions, and how customers will receive progress and residual-risk information. Protect legitimate proprietary details, but do not accept secrecy as a substitute for an engineering plan.

DSE recommendation: divide the roadmap into four workstreams

1. New development. Define approved memory-safe languages and runtimes for new services, parsers, agents, and exposed components. Require an engineering exception before introducing new memory-unsafe code.
2. High-risk migration. Prioritize parsers, network-facing services, privileged components, update mechanisms, and code with a history of memory-safety defects. Rewrite bounded components through tested interfaces instead of promising an immediate whole-product rewrite.
3. Unsafe-code containment. Where migration is not yet practical, use supported compiler hardening, platform protections, sandboxing, least privilege, protocol isolation, fuzzing, static and dynamic analysis, and prompt vulnerability response.
4. Dependency governance. Track the language and maintenance status of critical dependencies, constrain unsafe interfaces, monitor vulnerabilities, and document when an upstream project—not the product team—controls remediation.

DSE recommendation: measure outcomes that customers can verify

Track the percentage of new security-sensitive components implemented without unsafe code; exposed components migrated or isolated; approved exceptions and their age; memory-safety vulnerabilities discovered in first-party and dependency code; time to remediate; fuzzing and analysis coverage; and roadmap milestones completed. Avoid rewarding raw lines rewritten if the highest-risk interfaces remain unchanged.

Migration needs compatibility and rollback discipline. Define behavior, performance, resource, update, telemetry, and recovery acceptance tests before replacing a mature component. Preserve the ability to restore a supported version if the new implementation introduces operational risk.

DSE recommendation: use procurement leverage without creating false certainty

Add memory-safety questions to software and connected-device reviews. Ask whether the supplier has an executive-owned roadmap, which product layers remain memory-unsafe, how unsafe dependencies are identified, how researchers can report defects, and what support period applies to migrated and legacy components.

Treat transparent residual risk as a sign of maturity. The objective is not a logo or an absolute claim that vulnerabilities are impossible. It is sustained reduction of an exploitable defect class, backed by architecture, milestones, testing, disclosure, and accountable ownership.

Official references

• CISA and partners: The Case for Memory Safe Roadmaps
• NSA: Software Memory Safety
• CISA and partners: Exploring Memory Safety in Critical Open Source Projects
• CISA and FBI: Product Security Bad Practices update