Security1 publisherNot yet confirmed elsewhere2 min readPublished
CISA and the FBI put "exceptionally risky" software practices in writing, and buyers get the list
The guidance is non-binding. It is also a named list a critical-infrastructure buyer can read back to a vendor, starting with memory-unsafe code and the published plan for getting out of it.
The Watch · Security desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Federal authors published voluntary guidance naming product security practices they call exceptionally risky, aimed at software used in critical infrastructure and national critical functions.
- The practices are sorted into three categories: product properties, security features, and organizational processes and policies.
- Scope covers on-premises software, cloud services and SaaS, plus software running on operational technology products and embedded systems.
- Building new critical-infrastructure product lines in C or C++ where memory-safe alternatives are readily available is listed as dangerous to national security.
- For products already written in memory-unsafe languages, the bad practice is having no published memory safety roadmap.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- contradiction The same document rates these practices as elevating national security risk and disclaims imposing any requirement, so the only lever that bites is a contract clause someone chooses to write.
- capability A buyer can now ask for a specific artifact, a prioritized plan covering network-facing and cryptographic code, instead of accepting a general assurance about secure development.
- decision Vendors sitting on long-lived C and C++ products must pick which document to publish, and the cheaper option tells every customer when the product stops being supported.
- constraint A clean pass is a floor, not a defence: the authors say omission from the list implies no judgement that a practice carries acceptable risk.
The enforcement mechanism is stated in the document itself. CISA writes that following the recommendations will signal to customers that a manufacturer is taking ownership of customer security outcomes, which it calls a key secure by design principle [7]. That is a sentence about who does the checking, and it is not the agency. The wording came from CISA and the FBI [3]; the leverage arrives at renewal, in the hands of whoever signs the purchase order.
The memory safety roadmap is the part of this that survives contact with a lawyer, because it is an artifact with a date on it. Publishing one is not the whole ask. Manufacturers are expected to demonstrate that the roadmap will lead to a significant, prioritized reduction in memory safety vulnerabilities, and to demonstrate that they are making a reasonable effort to follow it [13]. That second clause is what separates a PDF from a commitment, and it hands a buyer a question for the following year's review: what actually moved.
Then there is the carve-out. Publication of a roadmap does not apply to products with an announced end-of-support date prior to Jan. 1, 2030 [14]. Anything a vendor still intends to sell into a water utility or a hospital in 2031 does not fit through that gap. Either answer is informative to the customer, which is the quiet effect of the clause: it turns a security question into a lifecycle disclosure, and vendors have historically been reluctant to put support horizons in writing at all.
The note attached to the item concedes the cost rather than pretending it away. CISA acknowledges that significant time and resources are needed to migrate to memory-safe languages, and suggests writing new components in memory-safe languages while hardware or compiler controls mitigate what remains [15]. So "we still ship C" is an answerable position, provided the other half of the sentence exists. What is no longer easy is the position that nothing is planned, since the absence of a plan is now the named bad practice, not merely the presence of old code.
Read as a whole, the list is a triage output. The authoring organizations say the items were chosen based on the threat landscape as the most dangerous and pressing practices to avoid [9], and the document also carries a change record [16], which is how a living checklist announces that it intends to grow. For anyone building a vendor questionnaire, the memory safety item is the one with a calendar date in it, and dated requirements are the ones that get quoted back first.
What to watch
- A major vendor announcing an end-of-support date before Jan. 1, 2030 for a flagship product instead of publishing a memory safety roadmap.
- Whether this wording migrates from voluntary guidance into federal acquisition requirements or attestation forms.
- Additions and edits logged in the document's change record, which would show which practices the agencies escalate next.