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.
\n\nThe 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.
\n\nNSA 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.
\n\nA 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.
\n\nA 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.
\n\nFor 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.
\n\nFor 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.
\n\nTrack 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.
\n\nMigration 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.
\n\nAdd 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.
\n\nTreat 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.
\n\n