CISA and the FBI's Product Security Bad Practices, version 2.0 (revised 17 January 2025), lists 13 practices software manufacturers should avoid, such as default passwords, hardcoded credentials and known exploited vulnerabilities in shipped components. The document says it is non-binding. It works well as a pre-sales self-check.
What the document is
It is guidance for manufacturers who develop software products and services, with an emphasis on products used in critical infrastructure. Version 1.0 appeared in October 2024. The document states that its guidance is non-binding.
The 13 practices as a self-check
| Group | Practice to avoid | Ask yourself |
|---|---|---|
| Product properties | New product lines in memory-unsafe languages for critical infrastructure, and no memory safety roadmap | Do we have a written roadmap? |
| Product properties | User input placed directly in SQL strings | Do we use parameterized queries everywhere? |
| Product properties | User input placed directly in OS command strings | Do we avoid shell calls with raw input? |
| Product properties | Default passwords | Is every password unique or forced to change? |
| Product properties | Shipping components with known exploited vulnerabilities, or not patching new ones promptly | Do we check against the KEV catalog? |
| Product properties | Shipping open source components with critical vulnerabilities, or not patching later ones | Do scans run before each release? |
| Product properties | Known insecure or deprecated cryptography, or unencrypted sensitive data | Have we reviewed algorithms and transport? |
| Product properties | Hardcoded credentials or secrets in source | Do we scan for secrets? |
| Security features | No MFA in the baseline product, or not enabled by default for administrators | Is MFA available and defaulted for admins? |
| Security features | Not giving customers logs and artifacts to gather evidence of intrusions | Can customers export audit logs? |
| Organizational | Not issuing CVEs in a timely way, or omitting the CWE field | Do we publish CVE records with CWE? |
| Organizational | No published vulnerability disclosure policy covering the product | Is our policy public and current? |
| Organizational | For on-premises products, not communicating the support period | Is end of support stated for each version? |
How to use it before a sale
- Score each row as yes, partly or no, with a link to evidence.
- Fix the "no" answers that cost little, such as publishing a policy page.
- For the larger gaps, write a dated plan. The memory safety row is the clearest case, and this checklist can help.
- Keep the sheet current. A stale one is worse than none.
What it does not do
It is not an attestation, a certification or a federal procurement rule. A buyer may borrow it as a list of questions. See Secure by Demand for the buyer-side set.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are tracked from detection to fix. That tracking supports the rows on shipped vulnerable components.
Quick check
Are the bad practices legally binding?
No. The document describes its guidance as non-binding.
How many practices are listed?
Thirteen in version 2.0, across product properties, security features and organizational processes.
Safeguard provides SBOM and dependency scanning, zero-day discovery and policies and gates, which map to several of these rows. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
