We've had many people ask us why we urge software manufacturers to eliminate entire classes of defect like cross-site scripting, SQL injection, directory traversal, and memory unsafety, as called for in our Secure by Design Pledge.
While it might seem like a novel concept to making software more secure, root cause analysis and mitigation of repeated classes of defect is the norm in industries that have significantly higher levels of quality and safety.
To improve product quality and security at scale, we need to spot patterns of recurring defect so that we can move from addressing each defect one at a time to eliminating them from the start.
Until we learn how widespread various classes of defect are, we won't be able to distinguish between classes of defect that companies should eliminate on their own, and those that require a coordinated effort by the larger software ecosystem.
If you truly align your product security program to prevent defects as early in the development cycle as possible, meaning that you are shifting security left on a timeline, you must contemplate ways to eliminate entire classes of coding error.
The idea is that repeated types of software defects are not the fault of the individual software developer.
See the prevalence of memory safety defects in languages like C/C++ compared to others like Swift, C#, Java, Rust, Python, JavaScript, Go, and Ruby.
Pulling software developers off other tasks to address software defects can be expensive and disruptive to project schedules.
If product teams eliminate enough of the classic defects, they may price some threat actors out of the market.
Many top software products fail to protect their customers from exploitation of the most common classes of defect.
We read in the news about these common defects causing significant damage to companies and government agencies.
We would hope that the software industry would eliminate top classes of defect every few years because doing so would increase the cost to threat actors.
We are still plagued by classes of defect like memory unsafety, XSS, SQL injection, directory traversal, and improper input sanitization.
What's especially noteworthy is that for most of these classes of defect, we have known of ways to prevent them at scale for years, and even decades.
Over the past 17+ years, many software companies have prioritized fixing software defects found in customer deployments over fixing them in their product designs, thereby putting customers at risk and leading to significant real-world harms.
The CWE explains the type of coding error that created the defect.
Ask those software companies what they are doing to eliminate that entire class of defect.
The bottom line is that a secure by design software development program necessitates formal efforts to eliminate entire classes of defect before the product ships rather than playing whack-a-mole with defects that appear on customer systems in production.
For the software manufacturer, a secure by design program that works to eliminate entire classes of defect is likely to be cheaper in the long run and will create a higher quality product that requires fewer emergency fixes.
It is the norm in other industries to perform root cause analysis and to work towards eliminating classes of defect and it is long past time for it to be the norm in the software industry.
This Cyber News was published on www.cisa.gov. Publication date: Mon, 13 May 2024 17:13:06 +0000