DEVOPSdigest

CISA's Product Security Bad Practices paper is one that every company should review as it details the "exceptionally risky software development activities" that are all too common in the industry. A critical bad practice, CISA points out, is the use of memory-unsafe programming languages such as C and C++, which are still widely used but increase risk. CISA also targets other harmful practices, such as allowing user-provided input in SQL query strings and OS command strings, the use of open-source software with known vulnerabilities, and a lack of multi-factor authentication (MFA), among other transgressions.

While CISA's efforts can help companies navigate the "need for speed" in a fast-moving DevOps environment, IT and security leaders across the private sector must do their part to prepare their companies for the necessary changes.

Secure-by-Design Is Taking Names

As of this writing, 296 organizations have signed the Secure-by-Design pledge, from widely used developer platforms like GitHub to industry heavyweights like Google. Similar initiatives have been launched in other countries, including Australia, reflecting the reality that secure software needs to be a global effort. But there is a long way to go, considering the thousands of organizations that produce software.

As the name suggests, Secure-by-Design promotes shifting left in the SDLC to gain control over the proliferation of security vulnerabilities in deployed software. This is especially important as the pace of software development has been accelerated by the use of AI to write code, sometimes with just as many — or more — vulnerabilities compared with software made by humans.

In addition to shifting left, the pledge addresses other security best practices, such as using MFA, eliminating default passwords, quickly applying security patches, and eliminating entire classes of vulnerabilities. The pledge asks signees to demonstrate progress toward each of its seven goals within a year.

Leaving Memory-Unsafe Languages Behind

The recent guidance on eliminating bad practices also suggests some relatively new advice, such as avoiding using memory-unsafe languages. These languages allow operations that can corrupt memory and lead to vulnerabilities such as buffer overflows and memory leaks.

CISA admonishes developers for using languages such as C and C++ despite the availability of memory-safe languages such as C#, Rust, Go, Java, Swift, Python, and JavaScript. Memory-unsafe languages, which include assembly language, are also common in open-source code. Joint research by CISA, the FBI, ACSC and the Canadian Centre for Cyber Security (CCCS) examined 172 projects from the Open Source Security Foundation's (OpenSSF) Securing Critical Projects working group and found that 55% of the total lines of code — in 52% of the projects — were written in memory-unsafe languages.

CISA recognizes that organizations can't simply transition their projects to memory-safe languages overnight, but it does set a deadline of Jan. 1, 2026 for organizations to publish a memory safety roadmap. A roadmap should outline a plan to eliminate memory safety vulnerabilities in priority components, such as network-facing code or code-handling sensitive functions like cryptography. Eliminating memory-unsafe languages can help in removing those classes of vulnerabilities.

As with other poor security practices, failing to correct the problem "significantly elevates risk to national security, national economic security, and national public health and safety," CISA says.

Secure Coding is the Foundation of a Secure Culture

What can organizations do to push their adoption of Secure-by-Design practices and put themselves on the path to a safer, more secure environment?

Improving the skill sets of developers is a critical first step. Software engineers traditionally get little or no cybersecurity training at higher educational institutions. They typically develop software — at an increasingly rapid pace — and then security teams are forced to play catch-up with a deluge of code. Training that provides developers with the ability to write secure code at the start of the SDLC and assess the code generated by AI or acquired from open-source repositories and other third parties, while working with security teams, can significantly reduce the number of vulnerabilities in an organization's software.

Upskilling programs, which need to be continuous, should involve flexible, hands-on training that addresses real-world scenarios and is thorough enough to instill a security mindset where employing security best practices becomes second nature for developers. The program should expand developer skills in a number of ways, from utilizing safe coding patterns to teaching a threat modeling process in which developers adopt an attacker's role and simulate attacks. This allows them to see how attacks could play out in their environment, and how to proactively defend against them.

Providing training isn't quite enough, though — organizations need to be sure that the training provides the necessary skills that truly connect with developers. Data-driven skills verification can give organizations visibility into training programs, helping to establish baselines for security skills while measuring the progress of individual developers and the organization as a whole. Measuring performance in specific areas, such as within programming languages or specific vulnerability management, paves the way to achieving holistic Secure-by-Design goals, in addition to the safety gains that would be realized from phasing out memory-unsafe languages.

Developer upskilling is a necessary step towards adopting an enterprise-wide security culture that extends from entry-level workers all the way up to the C-Suite. That kind of cultural shift is essential for improving software quality and requires a comprehensive approach. The various elements of that new security-first mindset, including adopting enterprise-wide security procedures, adding multi-factor authentication, training developers to write secure code, or even transitioning to the exclusive use of memory-safe languages, will all be needed to improve the sometimes abysmal quality of software code that Secure-by-Design guidelines were created to address.