Building a Memory Safety Roadmap Before January 2026 - A Practical Guide

[eng_director_luis]

With less than a year until the CISA deadline for publishing memory safety roadmaps, here’s a practical framework for creating one.

What CISA Expects

The roadmap should detail:

1. How you’ll modify your SDLC to reduce memory-unsafe code
2. Prioritized approach to eliminating memory safety vulnerabilities
3. Focus on priority components (network-facing, cryptographic operations)
4. Timeline and milestones

Let’s break this down into actionable steps.

Phase 1: Inventory (Weeks 1-4)

Catalog Your Codebase

• List all repositories and their primary languages
• Identify C/C++ components and their line counts
• Map native dependencies in higher-level languages
• Document third-party libraries with C/C++ cores

Tool Recommendations:

• GitHub’s dependency graph
• SCA tools (Snyk, Dependabot) for dependency mapping
• cloc for line count by language

Phase 2: Risk Assessment (Weeks 5-8)

Classify Components by Risk

High Risk (Priority 1):

• Network-facing code that parses untrusted input
• Cryptographic implementations
• Authentication and authorization boundaries
• Code running with elevated privileges

Medium Risk (Priority 2):

• Internal services handling sensitive data
• File parsing and processing
• IPC mechanisms

Lower Risk (Priority 3):

• Internal tools with limited exposure
• Code running in sandboxed environments
• Non-sensitive data processing

Phase 3: Strategy Selection (Weeks 9-12)

For each high-risk component, choose an approach:

Option A: Rewrite
Full rewrite in a memory-safe language. Highest security benefit, highest cost.

Option B: Wrapper/Isolation
Keep C/C++ code but isolate it (sandboxing, process separation, capability restrictions).

Option C: Hardening
Apply memory safety mitigations (ASLR, stack canaries, sanitizers) without rewrite.

Option D: Replace with Library
Switch to a maintained, memory-safe library that provides equivalent functionality.

Phase 4: Timeline Development (Weeks 13-16)

Realistic Milestones:

• Q1 2026: Roadmap published, inventory complete
• Q2-Q4 2026: Priority 1 components addressed
• 2027: Priority 2 components addressed
• 2028+: Priority 3 and ongoing maintenance

Be Honest About Timelines
A 5-year roadmap is credible if it’s realistic. An 18-month roadmap that you’ll miss is worse than a longer one you’ll achieve.

Phase 5: Documentation

The Roadmap Document Should Include:

1. Executive summary for non-technical stakeholders
2. Methodology for inventory and risk assessment
3. Component-by-component analysis and strategy
4. Timeline with milestones and success criteria
5. Resource requirements (budget, headcount, training)
6. Governance and progress tracking approach

What “Good” Looks Like

A credible roadmap shows:

• You understand your memory safety exposure
• You’ve prioritized based on actual risk
• Your timeline is realistic given resources
• You have executive commitment to the plan
• You’re tracking progress with metrics

The goal isn’t perfection by January 2026. It’s a credible plan that shows security maturity.

[cto_michelle]

Luis’s framework is solid. Let me add the executive presentation angle.

Presenting to the Board

When I present the memory safety roadmap to our board, I frame it around three dimensions:

1. Risk Reduction
“70% of security vulnerabilities in C/C++ code are memory safety issues. Our current exposure is X components handling Y% of our security-sensitive operations. This roadmap reduces that exposure by Z% over N years.”

2. Compliance and Market Access
“Federal procurement is moving toward memory safety requirements. Our roadmap positions us to maintain and expand government revenue. Additionally, enterprise customers are beginning to ask these questions in security questionnaires.”

3. Investment and ROI
“The roadmap requires $X investment over Y years. The return is reduced security incident costs, maintained market access, and competitive differentiation.”

The Questions Boards Ask

“Why now?”
Federal guidance, January 2026 deadline, and enterprise customers beginning to ask. Waiting increases compliance risk and competitive disadvantage.

“What if we don’t do this?”
Risk of exclusion from federal sales, negative findings in security audits, potential liability exposure if a breach stems from known memory safety issues.

“What’s the minimum viable investment?”
At minimum: inventory, risk assessment, and published roadmap. Actual migration can be phased based on risk prioritization.

“How do we know this is working?”
Metrics: percentage of codebase in memory-safe languages, reduction in memory safety CVEs, progress against roadmap milestones.

The Executive Summary Format

I recommend a one-page executive summary:

1. The Situation: Government mandates, enterprise expectations, security realities
2. Our Position: Current memory safety exposure and risk assessment
3. The Plan: Phased approach with milestones
4. The Ask: Resources required and expected outcomes
5. Success Metrics: How we’ll measure progress

Make it digestible for non-technical board members while demonstrating technical rigor.

[security_sam]

Luis’s risk classification is good. Let me expand on how to prioritize by attack surface.

Attack Surface Analysis for Memory Safety

Not all C/C++ code carries the same risk. Prioritize based on:

Tier 1: Immediate Priority

Network-Facing Parsers

• HTTP request handling
• TLS/SSL implementations
• Protocol parsers (DNS, SMTP, etc.)
• WebSocket handlers
• API input parsing

These are directly reachable by attackers over the network. A memory bug here is often directly exploitable.

Cryptographic Code

• Key generation and handling
• Encryption/decryption routines
• Signature verification
• Certificate parsing

Memory bugs in crypto code can leak keys or bypass security checks.

Privilege Boundaries

• Authentication mechanisms
• Authorization checks
• Sandbox implementations
• Kernel-userspace interfaces

Tier 2: High Priority

File Format Parsers

• Image processing (PNG, JPEG, etc.)
• Document parsing (PDF, Office formats)
• Media handling (audio, video codecs)
• Archive extraction (ZIP, tar, etc.)

These handle complex, potentially malicious input but typically require user interaction to trigger.

IPC and Serialization

• Message passing between processes
• Shared memory handling
• RPC mechanisms
• Serialization/deserialization (protobuf, msgpack)

Tier 3: Monitor and Plan

Internal Services

• Services behind authentication
• Admin tools and dashboards
• Internal APIs

Still vulnerable, but attack requires internal access or compromised credentials.

The Prioritization Formula

Priority = (Attack Surface Exposure) x (Data Sensitivity) x (Privilege Level)

A network-facing parser handling sensitive data running with elevated privileges = highest priority.

An internal tool processing non-sensitive data running sandboxed = lower priority.

Practical Output

Your risk assessment should produce a ranked list:

1. Component A (Tier 1, network-facing auth) - Rewrite Q2 2026
2. Component B (Tier 1, TLS handling) - Replace with memory-safe library Q3 2026
3. Component C (Tier 2, image processing) - Sandbox and harden Q4 2026
4. etc.

This prioritization makes your roadmap defensible to auditors and realistic for engineering.

[vp_eng_keisha]

The organizational change management aspect of language transitions is often underestimated.

The People Side of Memory Safety Roadmaps

It’s Not Just a Technical Migration

Changing programming languages affects:

• How engineers work day-to-day
• Career development and skill relevance
• Team composition and hiring
• Code review and quality processes
• Deployment and operations

Managing Engineer Concerns

Common Concerns:

“Am I going to have to learn a new language?”
Yes, probably. Frame it as career development, not obsolescence.

“Is my current expertise becoming irrelevant?”
No. C/C++ knowledge remains valuable for migration work and understanding legacy systems.

“Will this slow us down?”
Initially, yes. Be honest about the productivity dip during transition.

How to Address:

1. Training investment - Allocate time and budget for learning
2. Gradual transition - Don’t require everyone to learn immediately
3. Champions first - Start with volunteers who are excited
4. Clear expectations - What’s required vs optional and when

Team Structure Considerations

Option A: Dedicated Migration Team
A small team focuses on rewrites while others maintain existing code.

• Pro: Focused expertise, faster migration
• Con: Knowledge siloing, “not my code” syndrome

Option B: Distributed Ownership
Teams that own components do their own migrations.

• Pro: Ownership continuity, broader skill building
• Con: Slower, requires more widespread training

Option C: Hybrid
Central team provides expertise and guidance; product teams do the work.

• Pro: Balance of expertise and ownership
• Con: Coordination overhead

The Hiring Angle

If you’re migrating to Rust:

• Start building hiring capability now
• Consider apprenticeship programs for current engineers
• Be realistic about the talent market - experienced Rust engineers are scarce

Your roadmap should include a talent strategy alongside the technical plan.