ONCD puts memory safety into software architecture decisions

A customer can apply every available patch and still have no way to prevent the next memory corruption vulnerability in a purchased product. The manufacturer controls the implementation language and development budget. That mismatch is the practical problem behind the Office of the National Cyber Director announcement on 26 February. ONCD asks technology manufacturers to adopt memory-safe programming languages to prevent classes of vulnerabilities. It also calls for research into measuring software security, because buyers need better evidence about the products they depend on.

C was my first language, and I still regard its small language definition as a strength. That affection does not establish that C is the best default for a new component exposed to hostile input. The language can be understood while a particular program remains difficult to establish as safe. Its surrounding interfaces and lifetime rules determine much of that difficulty.

Prevention changes the architecture discussion

The report, Back to the Building Blocks, distinguishes spatial memory errors from temporal errors. The former involve accesses outside an object boundary. Temporal errors involve access at an invalid time or state, including access after an object has been freed. It recommends memory-safe languages for new products and a risk-based hybrid approach for existing code. Hardware protection and formal methods receive separate treatment as complementary approaches.

That distinction changes what an architecture decision needs to explain. A function can receive the right pointer value and still lack sufficient information about its valid lifetime. A size can describe an allocated buffer while a later operation computes the wrong offset. Treating these as separate obligations helps explain why a successful example execution cannot establish the safety of every permitted execution. This is a reasoning problem about the component contract, even before it becomes a tooling problem.

My reading of the recommendation is that language selection should include the cost of maintaining those obligations. The relevant cost is larger than the effort required to write the initial implementation. Every future change must preserve the assumptions that make the implementation valid. When those assumptions exist mainly in comments or developer knowledge, a new contributor must reconstruct them before changing the code safely.

A proposal for a new C component therefore needs a specific reason for accepting that burden. An existing platform interface or a constrained target may supply one. Familiarity alone is a weaker argument, because it does not explain how the product will prevent the recurring class of failure. The engineering discussion should connect the requirement to the implementation constraint, then identify which obligations the chosen tools can enforce.

Existing software needs a boundary that can be described

The hybrid approach is useful because a mature product rarely has one replaceable implementation unit. Its interfaces divide the work into pieces with different responsibilities. The report permits prioritizing important functions or libraries by risk. That gives an incremental proposal a more meaningful scope than a demand to rewrite an entire system at once.

An appropriate unit for such a proposal is a component whose inputs and ownership rules can be described independently. For example, a parser replacement can have a contract stating what input it accepts and how it reports a rejected message. The proposal then needs to address every object crossing the integration boundary. A change of implementation language does not answer who releases an object returned to the caller, or whether that caller may retain a reference after the next invocation.

This is an architectural inference from the hybrid recommendation. The replacement is useful only if the surrounding contract preserves its guarantees. If the caller can violate an assumption the replacement needs, the migration has moved the location of the obligation without resolving it. A narrowly specified interface makes the remaining obligation easier to identify. That can be a substantial improvement even when the complete product continues to contain C.

I place considerable value on C interoperability. It is one reason the language remains relevant to systems built with other languages. The same perspective makes integration contracts central to a memory-safety plan. The plan should say which side owns each allocation and what events end access to it. Those are reviewable statements about the proposed design, without requiring a claim that every part of the existing product is being replaced.

The roadmap has to be a product commitment

ONCD explicitly connects its announcement to shifting security responsibility toward organizations capable of managing the risk. An individual user cannot change a supplier's allocation strategy or replace a dependency inside a closed product. The supplier can allocate engineering time to those changes. A public commitment makes that difference in control relevant to procurement and product planning.

The earlier joint guidance, The Case for Memory Safe Roadmaps, calls on manufacturers to publish plans for eliminating memory-safety vulnerabilities. Its executive summary asks executives to identify senior staff responsible for the roadmap and help realign resources. The December announcement identifies CISA, NSA, FBI and international partners as the authors. February's White House position develops an existing direction in government guidance.

A roadmap interpreted as a technical preference will have little effect if product scheduling continues to reward feature delivery without funding maintenance changes. This is my assessment of the organizational implication. A replacement component consumes budget before its absence of future defects can appear in a release announcement. The person accountable for the product needs to decide that this work belongs in the schedule and explain how its scope relates to customer exposure.

That does not require describing every C component as equally urgent. A roadmap can distinguish a component that handles externally supplied data from one with a narrow, controlled input contract. It can also record where a replacement depends on another interface changing first. Such distinctions turn a language preference into a sequence of proposed product changes. A statement that the organization supports memory safety supplies much less information to a customer.

Security measurement remains an open part of the proposal

The report's second subject is software measurability. ONCD describes reliable cybersecurity quality metrics as a research problem and discusses how better measures might inform purchasing and development. Its argument acknowledges that counting known vulnerabilities does not by itself predict future security. The desired result is better evidence for decisions, including decisions by software buyers.

This part matters when interpreting a supplier's language claim. A percentage of code written in a particular language is easy to communicate, but its security meaning depends on what the code does. A small component exposed to untrusted input may deserve more attention than a much larger internal component. Code volume cannot express that distinction without further information about responsibilities and integration boundaries.

The same reasoning applies to a falling vulnerability count. It might indicate that preventive changes worked. It might also reflect changes in what researchers examined or what the supplier disclosed. A buyer needs enough context to understand which interpretation the evidence supports. Treating uncertainty explicitly is more useful than assigning a precise security score to an input that cannot justify it.

For an engineering organization, the immediate implication is to retain evidence about the decisions it controls. A replacement proposal can identify the unsafe operations it removes and the boundary assumptions it leaves behind. A completed implementation can demonstrate that the intended interface has replaced the previous one. These observations do not amount to a universal security metric, but they let reviewers assess whether a specific architectural commitment has been fulfilled.

The scope of the recommendation matters

The February announcement is a policy recommendation to manufacturers and researchers. It does not specify a C prohibition, a universal replacement deadline or a complete migration procedure. Reading it as any of those would obscure the actual responsibility it assigns. The manufacturer must decide how to reduce the recurring exposure in its own product, and the research community must improve the evidence available to assess such decisions.

For a C implementation, that leaves a concrete design question. Which memory obligations must every change preserve, and which can a different implementation enforce? Where replacement is practical, the comparison should include the obligations removed. Where C remains necessary, the design needs a precise account of the remaining access and lifetime rules. That account gives maintainers something they can inspect when the next change crosses the component boundary.