CISA’s new product security bad practices: mitigate risks with Secure by Design principles

Along with the FBI, the Cybersecurity and Infrastructure Security Agency (CISA) has published its new product guidelines guidance, highlighting several “bad practices” that software manufacturers need to avoid to protect end users. These new guidelines take focus on their recent initiative aimed at improving product security by discouraging bad practices in software development, particularly for critical infrastructure and national security. 

In this post, we’ll delve into the recently published guidelines by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI), which offer invaluable recommendations for software manufacturers. Although not mandated, CISA provides a clear list of DO’s and DON’Ts for software vendors, while planning for next year budget you can’t go wrong with prioritizing these initiatives into to the roadmap.

CISA’s Secure by Design vision 

In today’s fast-paced digital landscape, security needs to be more than just an afterthought. As software systems continue to underpin critical infrastructure and national functions, ensuring that security is embedded throughout the software development lifecycle is paramount. 

As America’s Cyber Defense Agency, CISA has introduced “Secure by Design” guidelines to revolutionize how technology providers develop software. In a world increasingly dependent on digital infrastructure, cyberattacks and vulnerabilities are no longer rare events but daily threats. With the new guidelines, CISA seeks to shift the cybersecurity burden from consumers to technology providers, urging them to take responsibility for ensuring that products are safe from the start. 

At its core, “Secure by Design” means prioritizing security throughout the entire product development lifecycle. Instead of retrofitting security features after a product’s release or reacting to vulnerabilities, manufacturers are expected to embed strong security mechanisms during the initial design and development phases. This approach drastically reduces exploitable flaws, making technology safer for users.  

The Secure by Design initiative emphasizes that security should be an integral component from the very beginning of product development. These voluntary guidelines highlight the most dangerous security practices and provide actionable insights to help developers safeguard their products – particularly those used in critical infrastructure or National Critical Functions (NCFs). 

Some of the key features of Secure by Design include Built-in security mechanisms, Default security configurations and Transparency. 

Products should be secure out-of-the-box without needing consumers to adjust settings. For example, critical security features like multi-factor authentication (MFA), single sign-on (SSO), and logging should come pre-configured and available at no extra cost. Additionally, all products should have a secure default baseline, meaning critical security controls are enabled automatically, minimizing the need for user intervention. Furthermore, companies are also urged to embrace radical transparency, providing clear and accurate vulnerability advisories and CVE records to inform consumers about potential security flaws. 

Further Reading: NIST Secure Software Development Framework 

Security built from the ground up

The guidelines also underscore the importance of executive-level responsibility for cybersecurity. CISA argues that cybersecurity should not be treated as an afterthought but must be a core business requirement for all technology providers. Leaders in tech need to foster a culture where security is woven into the DNA of every product. 

Also, as part of CISA’s plan to foster tech ecosystem security, it has defined a Call to Action – Unsafe at Any Speed: CISA’s experts, such as Bob Lord and Jack Cable, further break down the concept of Secure by Design, emphasizing that many current products are unsafe “at any speed” – to borrow a term from automotive safety. 

For security professionals and software developers, pursuing CISA certification can be a valuable step in gaining a deeper understanding of these guidelines and applying them effectively. For those involved in securing critical infrastructure, CISA training can provide essential knowledge on how to implement these principles during software development. 

CISA’s top product security bad practices to avoid

CISA and the FBI outline several critical bad practices that software manufacturers need to eliminate. These practices increase the likelihood of exploitation, putting sensitive data, national security, and the economy at risk. Below, we explore the key product security bad practices and offer recommendations on how to mitigate them. The bad practices highlighted in CISA and the FBI’s document fall into three categories: 

1. Product characteristics – focus on the security-related attributes observable in a software product. 
2. Security features – which refer to the product’s built-in security functionalities. 
3. Organizational processes and policies – cover how manufacturers ensure transparency and security within their operations 

 

Product characteristics

Unsafe Memory Languages (CWE-119) –

Building critical infrastructure or NCF software in memory-unsafe languages like C or C++ significantly elevates the risk to national security and other vital sectors. For existing systems written in unsafe languages, failing to present a memory safety roadmap by January 1, 2026, is similarly dangerous. 

This roadmap should prioritize fixing memory safety flaws in critical components, such as network-facing or cryptographic code. 

Recommended action: Use memory-safe languages or hardware safeguards to minimize memory vulnerabilities. Manufacturers should also publish their memory safety roadmap by the 2026 deadline. 

SQL Query Vulnerabilities (CWE-89) –

Allowing user input to be embedded directly in SQL query strings within software serving critical infrastructure or NCFs creates significant security risks. 

Recommended action: Prevent SQL injection by mandating the use of parameterized queries in all cases. 

Further Reading: CISA SQL Injection Secure by Design Alert 

OS Command Injection (CWE-78) –

Permitting user input to be directly inserted into operating system command strings for products related to critical infrastructure presents considerable security threats. 

Recommended action: Ensure that user input is separated from OS command logic to eliminate command injection risks.  

Default Passwords (CWE-1392/CWE-1393) –

Products released with default passwords, often shared across all instances of the product, introduce high levels of risk to critical infrastructure. 

Recommended action: Implement unique, instance-specific initial passwords, require the user to set a password during setup, and phase out default passwords across existing systems. 

Further Reading: CISA Default Passwords Secure by Design Alert 

Known Exploited Vulnerabilities (KEVs) –

One of the core tenets of product security is the rapid remediation of known vulnerabilities. Releasing products with known vulnerabilities, particularly those cataloged in CISA’s Known Exploited Vulnerabilities (KEV) list, poses an immediate threat to national security. If vulnerabilities are disclosed post-release, failing to issue patches promptly is equally dangerous. 

Releasing software that includes components listed in CISA’s Known Exploited Vulnerabilities (KEV) Catalog, or failing to address such vulnerabilities in a timely manner, puts critical infrastructure at risk. 

Recommended action: Patch all known vulnerabilities before release. If a KEV is published after a product’s release, issue a patch promptly and notify users of the associated risks if unpatched. 

Vulnerable Open Source Software (OSS) –

Releasing software for critical infrastructure that incorporates open source components with known vulnerabilities increases risk, especially if manufacturers don’t quickly address new vulnerabilities disclosed post-release. 

Recommended action: Maintain a software bill of materials (SBOM), regularly scan OSS components for vulnerabilities and ensure all third-party dependencies are kept secure and up to date. 

Further Reading: ESF Recommended Practices for Managing Open Source Software and Software Bill of Materials 

 

Security features

Lack of Multi-Factor Authentication (MFA) –

Products used in critical infrastructure that don’t support multi-factor authentication, especially for administrator accounts, significantly increase security risks. 

Recommended action: Enable MFA by default for admin accounts by January 2026. Products that handle authentication should support MFA directly or via third-party identity providers. 

Lack of Intrusion Evidence Collection –

Products failing to provide logs or artifacts for detecting security intrusions present major risks to critical systems.

Recommended action: Include standard logging and monitoring features in the base version of products and retain cloud-based logs for a minimum of six months without extra charges.

 

Organizational policies

Delays in Publishing CVEs with CWEs –

Failing to issue CVEs in a timely fashion for high-severity vulnerabilities, or not including the CWE field, poses significant security risks for critical infrastructure. 

Recommended action: Manufacturers should quickly publish detailed CVEs, including CWE references, for all severe vulnerabilities. 

Absence of a Vulnerability Disclosure Policy (VDP) –

Not having a vulnerability disclosure policy (VDP) that covers critical infrastructure products undermines transparency and increases risks. 

Recommended action: Publicize a VDP that authorizes responsible testing, pledges not to pursue legal action against researchers, and ensures prompt disclosure of reported vulnerabilities. Manufacturers should address valid issues swiftly. 

By adhering to these comprehensive practices, manufacturers can greatly reduce security risks for critical infrastructure and NCFs, thus protecting national security, economic stability, and public safety. 

Unsafe at any speed: why these changes are urgently needed

CISA’s vision is built on the premise that too many products on the market today are fundamentally insecure. From poor password policies to the lack of encryption, many products are prone to compromise right from the start. The Secure by Design principles aim to prevent these systemic vulnerabilities from ever reaching consumers. 

CISA likens today’s insecure software products to unsafe cars – just as vehicles undergo crash testing before reaching consumers, so should software products be rigorously tested for security flaws before launch.

Companies can no longer afford to rely on post-release patching as the primary defense mechanism. Instead, they must invest in secure design practices from the outset, making it difficult for cybercriminals to exploit vulnerabilities. 

Their solution is straightforward: security should be a fundamental design principle, not a feature bolted on after development. By shifting the focus back to the software manufacturers, CISA is placing the onus on technology providers to ensure that their products are secure out-of-the-box. The guidelines call on software manufacturers to actively invest in secure design practices, reduce customer risk, and build products that protect digital sovereignty and national security. 

Professionals seeking to expand their expertise in the field can benefit from enrolling in a CISA exam, which covers key aspects of cybersecurity, including risk management and compliance with standards like Secure by Design. 

How Can Companies Align with CISA’s Product Security Bad Practices? 

For companies looking to adopt these principles, CISA’s guidelines provide a clear framework, with the goal being to shift the burden of security away from end-users and ensure that security is baked into products from the design stage. 

Here are some actionable steps that organizations can take to align their development processes with Secure by Design principles: 

1. Executive Leadership on Security – Security must be owned at the executive level, with dedicated teams and resources focused on integrating security into the design and development process. Organizations should also consider encouraging their teams to participate in CISA Training CISA certification programs to ensure they are well-versed in the latest security standards and best practices. 
2. Early Integration of Security – Companies should incorporate security measures into the initial design phase of the software development lifecycle. This includes secure coding practices, regular code reviews, and security testing. To cover the entire attack surface, organizations should leverage a comprehensive suite of security tools such as Static Application Security Testing (SAST), Software Composition Analysis (SCA), and External Attack Surface Management (EASM). These tools help identify vulnerabilities in both custom code and third-party components, ensuring that potential risks are mitigated before products are released. 
3. Transparent Vulnerability Disclosure – Organizations should commit to radical transparency, disclosing security vulnerabilities openly and providing clear advisories to customers. This includes maintaining an accurate and up-to-date list of known vulnerabilities (such as CVE records) that impact their products. 
4. Security Audits and Compliance – Regular third-party audits and compliance checks ensure that security is not just a theoretical principle but a practical reality across the organization. 
5. Security by Default – Configure products to ship with the highest level of security enabled by default, ensuring that consumers don’t inadvertently expose themselves to risk. 
   

Conclusion

As cyber threats grow in sophistication, so do the consequences of vulnerabilities in software that powers critical infrastructure. Insecure software used in sectors such as energy, healthcare, and finance could lead to widespread disruption or even endanger public safety. CISA’s Secure by Design framework encourages manufacturers to take proactive measures to ensure their products not only meet operational needs but also protect users and the broader community from emerging cyber risks.  

This new CISA guide seeks to encourage software manufacturers to focus on reducing customer risks by embedding security principles throughout product development. It is targeted at vendors producing software for environments such as on-premise systems, cloud services, or software as a service (SaaS), especially those serving critical infrastructure or NCFs. While the guidelines are advisory and carry no enforcement obligation, CISA highly recommends that manufacturers avoid the security pitfalls outlined. 

To reinforce this commitment, encouraging cybersecurity professionals to undergo CISA training and certification will help ensure they have the skills necessary to adhere to these principles. By adhering to these guidelines, software makers demonstrate that they take responsibility for their customers’ security, which aligns with the core principle of Secure by Design. Although CISA stresses the importance of these recommendations, compliance is not mandatory

Further reading

Each new vulnerability is a reminder of where we stand and what we need to do better. Check out the following resources to help you maintain cyber hygiene and stay ahead of the threat actors: 

1. Q3 2024 Vulnerability Watch
2. The MITRE ATT&CK framework: Getting started
3. The true impact of exploitable vulnerabilities for 2024
4. Vulnerability disclosure policy (and how to get it right)
5. How to properly tackle zero-day threats