The Cybersecurity and Infrastructure Security’s Secure-by-Design campaign marks a genuine turning point in software security, spearheading a concerted effort to raise the standards of software security and quality, and putting responsibility for software security squarely on the shoulders of software manufacturers.

Although CISA’s directives only have teeth involving sales to the U.S. government, its principles are drawing widespread support, with hundreds of vendors voluntarily signing the Secure-by-Design Pledge to uphold the standards.

The campaign also has the support of the National Security Agency and the FBI, and is being mirrored in other countries, including Australia, Canada, the United Kingdom, Germany, the Netherlands and New Zealand.

Broad public- and private-sector support on national and international levels doesn’t guarantee success. After all, secure software design has always been a good idea, but it has played second (or even third) fiddle to rapid development and deployment in ever-accelerating DevOps environments. Why? It’s not straightforward to accomplish, and threat actors remain at a distinct advantage.

Some security professionals, while thoroughly on-board with the fundamental concept of Secure-by-Design, are calling attention to the difficulties of implementing CISA’s guidelines in a diverse and constantly morphing software ecosystem, as several of them told ReversingLabs.

For example, some software designs are too unique for a one-size-fits-all approach, they said. And although a Secure-by-Design approach may work for new software, it can be very difficult to implement these practices with already deployed software that is undergoing constant upgrades and revisions that make software and applications increasingly complex.

These are valid points; but while it’s true that the initial pain of implementing Secure-by-Design should not be underestimated, the long-term benefits are too great to ignore.

Working to Change the Status Quo

Implementing Secure-by-Design principles is a big job that will take time and effort, considering that among CISA’s recommendations is eliminating entire categories of vulnerabilities, such as cross-site scripting (XSS) and OS command injection vulnerabilities, as well as the use of memory-unsafe programming languages, such as C and C++. These are challenges that are firmly embedded in a lot of software. Research by CISA, the FBI and cybersecurity agencies in Australia and Canada found that 55 percent of the total lines of code in projects the group examined were written in memory-unsafe languages.

However, as the cyber threat landscape becomes increasingly sophisticated and pernicious, we must do what we can to change the status quo. A traditional approach to the security of the software development lifecycle (SDLC) provides, at best, only the bare minimum of protection. We can no longer afford for security to be applied after the fact, often when applications are already in production. Security best practices must be applied at the start of the SDLC, with developers and security teams working together.

We can’t let the presence of legacy code or code monoliths be an excuse for inaction; we may not be able to correct every mistake, but organisations need to invest the time and resources necessary to improve the future of software security. We must change the culture in software development if we are to - eventually - gain the high ground against attackers.

A flexible, data-driven approach to implementing Secure-by-Design principles is likely the most effective path forward. It can help assuage legitimate concerns about the difficulty of applying guidelines established by the government to unique, constantly evolving software environments, while enabling a level of transparency that can help organisations succeed.

CISA says it wants to put the onus on software manufacturers, but a transparent process with industry and government working together could balance any carrot-and-stick approach and lead to effective results. It’s better to have organisations focused on the positive—successfully implementing Secure-by-Design—rather than the negative—worrying primarily about avoiding liability.

Developer Risk Management Is Central to Modern Secure Design

At the heart of Secure-by-Design efforts is a commitment to upskill and position developers as the heart of the security program. CISA’s pledge asks organisations to implement a range of best practices, from multi-factor authentication (MFA) to timely deployment of security patches.

Several other best practices are intended to increase transparency, such as publishing a vulnerability disclosure policy and adhering to reporting requirements. Secure software hinges on introducing security at the beginning of the SDLC, and to do that, you need security-skilled developers with verified knowledge of applying best practices.

They must be able to code securely, as well as catch errors in code generated by AI assistants, which are increasingly used to help produce code more quickly. They also need to be able to spot errors and vulnerabilities in code that come from open-source repositories and third-party partners.

Developers, who traditionally receive little if any security training in software engineering education programs, need ongoing, hands-on learning pathways that uses baselines and benchmarks to ensure that the knowledge they receive effectively addresses current cybersecurity challenges.

This program must be flexible enough to fit with their work schedules and tailored to the languages they work with and the applications they build. It also must be continuous so that security becomes an inseparable part of their work, reflecting—ideally—an organisation’s security-first culture.

The key to making it all work is ensuring that developers are in fact learning and applying new skills. Establishing a baseline of necessary skills and using benchmarks to measure progress can not only improve software quality within an organization, but also contribute to improved security within the industry.

Benchmarks such as those in our Trust Score technology can track the progress of individual developers, teams and the organisation overall, measuring that progress against both internal and industry-wide standards. Benchmarks also help identify areas that need improvement. A transparent process among software manufacturers can raise the level of software security across the board within the industry.

Conclusion

A Secure-by-Design approach is the future, at least if the future is a place where we can have faith in the quality and security of software. CISA’s leadership in this area is welcome, and software manufacturers are right to get on board, implementing a culture of security built on Secure-by-Design principles. But all sides need to acknowledge that implementing these principles is difficult and that they must work together toward realistic goals.

A data-driven approach that recognizes the challenges software manufacturers face can help organisations make measurable progress and allow the initiative to expand, something that it will need to do to achieve global success. After all, the hundreds of organisations that have signed the Secure-by-Design pledge—including many major vendors—represent only a fraction of the thousands of organizations, groups and individuals who develop software.

Major players can set an example that others will inevitably follow, especially if buyers and users insist that software abides by Secure-by-Design principles. This unified approach with everyone working together is really the only way to ensure that our evolving, connected environments are built securely and that our applications, data and personal information are fully protected from an increasingly dangerous threat landscape.

Pieter Danhieux CEO & Co-Founder Secure Code Warrior