CISA's product security bad practices guidance names 13 things software makers should not do, such as shipping default passwords or having no published way to report vulnerabilities. For a buyer, it works as a short checklist of questions to put to any vendor before you buy or renew.
The three groups
CISA sorts the 13 practices into product properties, security features, and organizational processes and policies. Here is each one in everyday language.
Product properties
- Memory safety. Building new products in languages that allow a class of memory bugs, with no plan to remove those bugs from older products.
- SQL injection. Putting user input straight into database queries.
- OS command injection. Putting user input straight into operating system commands.
- Default passwords. Shipping every unit with the same built-in password.
- Known exploited vulnerabilities. Shipping products that contain components on the KEV list, or not patching newly listed ones.
- Open source components. Shipping products that include open source components with critical vulnerabilities, which CISA defines as CVSS 9.0 or higher. The guidance also covers managing open source dependencies, for example keeping an SBOM and scanning components.
- Cryptography. Using insecure or deprecated algorithms, or not encrypting sensitive data.
- Hardcoded credentials. Storing secrets in source code.
Security features
- MFA. Not supporting multi-factor authentication, or not enabling it by default for administrator accounts.
- Evidence of intrusions. Not giving customers logs on configuration changes, identity and network activity, and data access.
Organizational processes and policies
- CVE issuance. Not issuing timely CVEs for critical or high-impact vulnerabilities, or leaving out the weakness type.
- Disclosure policy. Not having a published vulnerability disclosure policy that covers the product.
- Support periods. Not clearly stating support periods for on-premises products.
Which ones a buyer can check quickly
| Practice | A quick check |
|---|---|
| Disclosure policy | Look for a security page or a security.txt file on the vendor's site |
| Support periods | Find the end-of-support date on the product page or in the contract |
| MFA | Ask whether admin accounts require it by default |
| Open source components | Ask for the SBOM and how often it is scanned |
| Known exploited vulnerabilities | Ask how fast newly listed ones are patched |
| CVE issuance | Look at the vendor's advisory page for past entries |
The deeper items, such as memory safety and injection flaws, are harder to see from outside. For those, ask what testing the vendor does and whether it will share a summary.
How to use this in a purchase
- Pick the six rows above and put them in your security questionnaire.
- Score answers as clear, vague or missing.
- Treat "missing" as a follow-up question, not an automatic no.
- Record the answers so you can compare at renewal.
CISA frames these as practices to avoid, not as a certification. A vendor that avoids all 13 has not been audited by CISA, and the list does not cover everything that matters.
Where Safeguard fits
For teams that build software, practices 5 and 6 are the ones Safeguard helps with directly. It scans dependencies, produces SBOMs, flags components with known exploited or critical vulnerabilities, and lets you set policies and gates so they do not ship. A free scan is at gold.safeguard.sh/scan.
Quick check
Is the bad practices list a legal requirement?
CISA presents it as guidance for software makers. Check your own contracts and regulations for what is binding on you.
Which single question is most useful to ask a vendor?
Ask where you report a vulnerability and how long fixes take. A clear answer shows a working process behind the product.
Sources
Last reviewed: 19 October 2026.
