The Cybersecurity and Infrastructure Security Agency (CISA) and its government and international partners released guidance in April urging manufacturers to take the necessary steps to ship products that are secure by design and secure by default.
Software supply chains deliver applications and code used to build new software, including those that support national defense, public safety, healthcare, and financial transactions. Yet, attackers are everywhere, and their attacks are more sophisticated. As a result, the security of software supply chains demands more attention than ever.
For security by design to work, we need to make security continuous and integrated throughout the entire software lifecycle. As with the design of a car, if the right parts are not used, if the implementation does not get performed correctly, and if components are not tested for mistakes during the development, it doesn’t matter how sleek a design has been crafted. Security by design means manufacturers will strive to make software secure before it gets released to the public.
Many vendors make software secure over time by just patching vulnerabilities that are found when the software is in production. But what happens before the software gets released? Vendors must have the processes, techniques, and technologies in place to make sure they are doing less patching of software in the field. They must find the vulnerabilities in their code instead of having them discovered by their customers, security researchers, or even attackers.
Applications are bound to have flaw build-up over time. Nearly 32% of applications are found to have flaws when they first move into production; by the time they have been in production for five years, nearly 70% contain at least one security flaw, according to Veracode’s State of Software Security (SoSS) 2023 Report. As a result, frequent and regular scanning should continue when applications are in production to reduce the need for patching and remediation later on.
Early efforts didn’t impact the mainstream
Security by design has been discussed and promoted for years now. In 2004, for example, Microsoft introduced its Secure by Design, Secure by Default, Secure by Deployment and Communication (SD3+C) strategy, which has evolved into the Security Development Lifecycle. Also, in the early 2000s, The Department of Homeland Security and Carnegie Mellon Software Engineering Institute launched a “Build Security In” web-based software assurance portal, offering best practices, tools, and other resources to help software developers and security practitioners create more secure and reliable software.
These early efforts were picked up by many large and well-funded organizations, but never made it into the mainstream of thousands of software vendors. CISA’s Security by Design principles aim to shift the responsibility to these vendors to deliver a secure product: it’s the only way for the small- and medium-sized companies and organizations to stay secure. They simply don't have the money, time, and expertise to invest in bolting on security protection, as well as detection and response solutions.
The push seeks to ensure that everyone stays secure--cities, towns, police departments, school districts, small dentist offices and businesses-- not just the well-funded organizations. The recent National Cybersecurity Strategy issued by the Biden administration articulates this goal.
More complexity ensues as attack surfaces expand
The industry needs security by design even more now because the stakes are much higher than at the beginning of the millennium. Open-source software consumption has increased, the API attack surface continuously expands, and continuous deployment requirements add another layer to the complexity.
Applications include many commercial components, as well. Developers today need to know about application security. They need to know about APIs and secure communication protocols. They need to know how to secure the cloud infrastructure in the back end and all the services with which it's communicating. Put simply, applications are more complex, with pieces and parts coming from different sources. Vendors are creating this complexity to deliver better products faster, but that doesn’t absolve them from securing these products – and that’s the big challenge.
Customers will move vendors forward
CISA has issued excellent guidance, but we need customer, legal, or regulatory incentives to make this a reality. Customers always offer the most incentive to change. If customers demand something and it’s available from some suppliers, then we can look at it as an option to become mainstream.
Federal agencies are now well-educated customers on this topic. The White House Executive Order on Improving the Nation’s Cybersecurity said that vendors must build secure software, or the federal government will not buy their products. Vendors must produce a Software Bill of Materials (SBOM), an inventory list of all the components in their software and fill out an attestation form describing how the software was built. This will compel vendors who sell to the government and commercial sector to improve their processes.
But what about vendors that do not sell to the government, those that develop software for elementary schools or dentist offices? They might need other incentives to develop secure software. The marketplace solves a lot of these problems when large, well-funded entities that care about security, like banks, pressure vendors to develop secure software.
It’s going to cost vendors a little bit more to secure software. Ultimately, end users should absorb some of those costs. The same way consumers may pay extra for cars with better security, if we develop secure software that costs slightly more, it’s often cheaper in the long run because it can save organizations from potentially serious data breaches. It’s more economical for a vendor to invest in finding and fixing another vulnerability than to have all their customers race to install a patch, while some customers spend time and money on incident response because attackers got there first.
For security by design to become mainstream, the market must understand these requirements, and this should start with software suppliers. Rather than reactively spending money and effort on security technology, let’s proactively collaborate to shift responsibility for software security left – to the start of the development process. As society depends on software more and more, including for health and safety, the status quo won’t cut it anymore.
Chris Wysopal, founder and chief technology officer, Veracode
