CISA/FBI Product Security Bad Practices, explained

Product Security Bad Practices is joint, voluntary guidance from the Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) — referred to in the document itself as "the authoring organizations" — published under CISA's Secure by Design initiative. Per its own Overview, it is "intended for software manufacturers who develop software products and services, including on-premises software, cloud services, and software as a service (SaaS)" and explicitly "also applies to software products that run on operational technology (OT) products or embedded systems." It lists 13 practices the authoring organizations consider "exceptionally risky," each paired with a recommended action, particularly for manufacturers whose software is "used in service of critical infrastructure or national critical functions (NCFs)." The document is distributed as TLP:CLEAR (unrestricted public disclosure) and states plainly: "The guidance contained in this document is non-binding, and while the authoring organizations encourage avoiding these bad practices, this document imposes no requirement to do so."

Per the document's own Change Record, Version 1.0 was published in October 2024 as an initial draft, and Version 2.0 followed in January 2025 after CISA "received 78 public comments" during the Request for Information period referenced in the Federal Register docket (CISA-2024-0028). Version 2.0's changes include: three entirely new bad practices (use of known insecure or outdated cryptographic functions, hardcoded credentials or secrets in source code, and failure to clearly communicate a product's support period); additional context in the memory-safety section; more worked examples for preventing SQL injection and OS command injection; clarified patch timelines for Known Exploited Vulnerabilities (KEVs); new operational-technology-specific language for multi-factor authentication (MFA); and an added expectation that manufacturers support phishing-resistant MFA specifically, not just any second factor.

The catalog groups its 13 items into three categories it defines itself: "Product properties, which describe the observable, security-related qualities of a software product" (8 items — new products in memory-unsafe languages without a roadmap, SQL injection via unparameterized queries, OS command injection, default passwords, shipping with a component already on CISA's Known Exploited Vulnerabilities catalog, shipping open-source components with a CVSS 9.0+ vulnerability, insecure/deprecated cryptography such as TLS 1.0/1.1, MD5, SHA-1 or DES, and hardcoded credentials or secrets in source code); "Security features, which describe the security functionalities that a product supports" (2 items — no native or federated multi-factor authentication, and insufficient logging to reconstruct common intrusion types); and "Organizational processes and policies, which describe the actions taken by a software manufacturer to ensure strong transparency in its approach to security" (3 items — not issuing timely CVEs with a CWE field for critical/high-severity flaws, no published vulnerability disclosure policy, and not clearly communicating an on-premises product's support period). The document is explicit that this list "is focused and does not include every possible inadvisable cybersecurity practice" — omission from the list is not an endorsement.

Bad practice #1 states that developing "new product lines for use in service of critical infrastructure or NCFs in a memory-unsafe language (e.g., C or C++) where readily available alternative memory-safe languages could be used is dangerous," and separately, that for existing products in memory-unsafe languages, "not having a published memory safety roadmap is dangerous." The recommended action sets a concrete deadline: "software manufacturers should publish a memory safety roadmap by the end of 2025, outlining their prioritized approach to eliminating memory safety vulnerabilities in priority code components written in memory unsafe languages" (e.g., network-facing code or cryptographic routines). This obligation is scoped — it "does not apply to products that have an announced end-of-support date that is prior to Jan. 1, 2030" — and the document's own Note acknowledges migration is incremental, citing interim steps like hardware/compiler mitigations and rewriting only the highest-risk components first. CWE-119 is the associated weakness class.

No. The document states this directly in its Overview: it is "voluntary guidance," and "this document imposes no requirement to do so" (to avoid the listed practices). It carries no enforcement mechanism of its own. That said, several of the same practices already show up as hard requirements elsewhere — default passwords and a vulnerability disclosure policy are PSTI and EU Cyber Resilience Act obligations, for example — so treating the catalog as voluntary-today, likely-regulated-tomorrow is a reasonable reading rather than dismissing it as non-actionable.