Published on
In today's interconnected world, where software powers everything from our cars to critical infrastructure, insecure coding practices can have devastating consequences.
The Cybersecurity and Infrastructure Security Agency (CISA) and the FBI recently released a joint guide highlighting exceptionally risky software development practices that all organizations should avoid.
Whether you're a small startup or a large enterprise, secure coding is no longer optional – it's essential for protecting your data, your customers, and your reputation.
Let's dive into the top 10 insecure development techniques that you need to eliminate from your codebase today.
The Top 10 Insecure Software Development Techniques
Development in Memory Unsafe Languages
CWE-119 and related weaknesses
Developing software in memory-unsafe languages like C and C++ poses security risks and increases development costs due to potential memory corruption vulnerabilities and the complexity of patching them.
To prevent the emergence of memory safety vulnerabilities, software developers should prioritize creating products using memory-safe programming languages or hardware capabilities. This systematic approach minimizes the risk of introducing such vulnerabilities.
Inclusion of User-Provided Input in SQL Query Strings
Including user input in SQL queries can lead to SQL injection attacks, causing data breaches and system compromise, especially in critical infrastructure, where it can disrupt services and jeopardize security.
How to Prevent SQL Injection Vulnerabilities: How Prepared Statements Work
To prevent SQL injection vulnerabilities, products should be constructed to consistently enforce the use of parametrized queries, systematically preventing their introduction.
Inclusion of User-Provided Input in Operating System Command Strings
User-provided input directly in operating system commands is dangerous and elevates risk. It allows attackers to inject malicious commands, giving them control over the system. This vulnerability significantly threatens critical infrastructure, national security, economic stability, and public safety.
To prevent command injection vulnerabilities, software manufacturers should consistently implement measures that clearly distinguish between command inputs and the actual command. This systematic approach helps eliminate vulnerabilities and enhance the security of their products.
Presence of Default Passwords
Software default passwords pose a critical risk, as they allow attackers to access systems and data. This can lead to data breaches, financial loss, and service disruptions, particularly for critical infrastructure.
To enhance security, software manufacturers must eliminate default passwords by implementing unique initial passwords, requiring users to set strong passwords during installation, or using time-limited setup passwords that prompt for secure configuration. This is crucial to protect critical infrastructure and national security.
Presence of Known Exploited Vulnerabilities
Releasing products with exploitable vulnerabilities listed in CISA's KEV Catalog is dangerous and increases risk. Known exploited vulnerabilities in software can lead to attacks, compromising data, disrupting operations, and causing financial losses. This is especially dangerous for critical infrastructure, where it could disrupt essential services and national security.
Before software release, manufacturers should address all known exploited vulnerabilities in software components through patches. Upon the publication of a new KEV in CISA's catalog, manufacturers must promptly provide users with a free patch (within 30 days at most) and explicitly highlight the risks of not installing the patch.
Presence of Open-Source Software with Known Exploitable Vulnerabilities
Using open-source software with known vulnerabilities in your critical infrastructure product significantly elevates risk, making it susceptible to attacks and potential disruptions.
Secure Your Software's Foundation: Supply Chain Security Training from Security Journey
Software manufacturers must responsibly engage with open-source software to ensure product security and sustainability. This includes maintaining an SBOM and establishing a secure management process. Regular vulnerability scans and timely updates are crucial. By doing so, they contribute to the open-source community and enhance overall security.
Lack of Multifactor Authentication
Products in critical infrastructure without multifactor authentication (MFA) are dangerous and increase risk. Lack of MFA leaves accounts vulnerable to compromise with a single compromised credential, posing a significant security risk, especially for critical infrastructure, where unauthorized access could disrupt essential services and jeopardize national security, economic stability, and public health.
For improved security, software manufacturers should integrate multifactor authentication or support external identity providers in their products, enabling users to authenticate using existing credentials securely.
Lack of Capability to Gather Evidence of Intrusions
Lack of baseline security tools jeopardizes systems, hindering incident response and making identifying configuration changes, unauthorized access, and data breaches difficult. The inability to gather intrusion evidence further complicates incident response and recovery.
Software manufacturers should include industry-standard logs in their baseline products for transparency and analysis. Logs should cover the specified areas. Cloud-based services and SaaS products must keep these logs for at least six months without extra charges.
Failing to Publish Timely CVEs with CWEs
Software manufacturers should promptly issue CVEs for critical or high-impact vulnerabilities, including CWE fields. Failing to do so hinders security flaw identification and mitigation, leaving systems vulnerable. This undermines collective efforts to improve software security and protect infrastructure.
Software manufacturers should promptly publish complete CVEs, including the appropriate CWE field, for all critical or high-impact vulnerabilities.
Failing to Publish a Vulnerability Disclosure Policy
Not having a published vulnerability disclosure policy for critical infrastructure products is dangerous as it discourages security researchers from reporting vulnerabilities, leaving systems vulnerable to attacks and potentially causing significant harm.
Implement a Vulnerability Disclosure Policy (VDP) to encourage public testing reporting of software vulnerabilities and provide legal protection to responsible reporters. This fosters transparency collaboration, and enhances software security.
Is Your Code Secure? Take Action Now!
Insecure development techniques are a ticking time bomb waiting to explode in the form of data breaches, system compromises, and reputational damage. Prioritizing secure coding practices isn't just a best practice – it's necessary for organizations of all sizes. By fostering a security-first culture, investing in developer training, and implementing robust security measures throughout the SDLC, you can build innovative and resilient software.
Ready to take the next step in your secure coding journey?
Don't wait for a security incident to force your hand. Take action today and build a more secure future for your organization.
Read more from:
OWASP