Can Regulatory Mandates Secure Software Development?

Software companies have a long history of delivering incomplete and insecure products. This happens for a couple of reasons. Fast time-to-market has always been a business priority, taking precedence over security, especially as DevOps has become the norm in software development methodologies. And software, by nature, is easy to update and change, so some defects or oversights could be allowed to slide through with the thought that “We can always fix it later.”

Unlike car manufacturers that put a premium on including safety features upfront (or face the heavy hand of regulators), software makers have typically emphasized speed to market as a way to stay competitive.

But the other shoe often drops on that approach in the form of costly recalls, extensive patch programs, cybersecurity breaches, and other issues. The fix-it-later mentality in software has become increasingly challenging in recent years with the emergence of connected/IoT devices that are harder to keep current and have a greater impact. Connected closed-circuit surveillance cameras, for example, are frequently hunted and exploited on the internet to spy on people. Internet of things (IoT) devices operating at dams or nuclear power plants can now be hacked (as seen at the Bowman Avenue Dam in New York, or three utility companies in Ukraine hit by BlackEnergy malware). And, across the board, the cost of data breaches continues to rise.

A White House executive order (EO) from 2021 is also putting pressure on software manufacturers, DevOps and DevSecOps professionals to improve quality, with a mandate for U.S. federal agencies to enforce secure software development through their contracts and acquisitions as part of efforts to secure the software supply chain. The core difference between this effort versus previous attempts such as FISMA, is the visibility into the software development process.

The attention being paid to secure software development is a step in the right direction, but ultimately it’s still up to the industry rather than regulatory bodies, to change the mindset toward building secure software from the ground up.

Technology is Faster Than Mandates

The EO represents a shift in the landscape, mandating not just secure products, but secure development practices. Although it applies officially to federal civilian agencies and their contractors, federal regulations and other government mandates often become global standards, as has happened with the General Data Protection Regulation (GDPR), the EU’s privacy and security law.

But regulatory mandates aren’t enough. They often move too slowly to be a real solution, especially in a software development environment that is moving steadily towards more agile, fast-paced environments where continuous integration and continuous delivery (CI/CD) is the norm. The timelines for new regulations typically require a two-year window for implementation; if a company already has an applicable product in use, it could be up to five years before they’re required to be in full compliance, such as in the payment industry. By that time, the key elements of the industry best practices have already changed. Simply put, technology moves too fast for regulatory bodies to keep up.

What’s more, the regulations themselves could ultimately fall short if they are perceived to have a high cost burden of compliance. This is specifically true if the technology used in the software development life cycle can’t keep pace with the needs of compliance. In support of the EO, the National Institute of Standards and Technology (NIST) has released Draft Special Publication (SP) 800-218, and, as is routine, accepted open public comments. The feedback from industry consortiums in these situations often includes considerations about the costs of implementing new regulations and can sometimes lead to softening of some aspects, arguing, for example, that the new regulations put an unfair burden on small and mid-sized companies. The final set of regulations can sometimes leave the door open for ways to address compliance without addressing the issues that led to the regulation in the first place.

For example, the California Consumer Privacy Act (CCPA) is widely hailed as the nation’s strictest set of privacy protections, yet it still has its weaknesses. The most commonly cited weakness is that the law makes it extremely difficult for consumers to take advantage of the new regulations when they feel they have been wronged.

Industry Must Make it Happen

Ultimately, it is up to software manufacturers and the industry to improve the security of their software. They should adopt best practices to build secure procedures into the design, development, testing and validation of new software, as well as its deployment and use. NIST’s Secure Software Development Framework is one example of guidance, being drawn from recommendations from groups like BSA, OWASP, and SAFECode. Industry groups, such as the International Organization for Standardization (ISO), could adopt standards for development and certification similar to the universally accepted UL standards for electrical products.

The rising demand for secure development requires a substantial shift in attitudes toward how software is made. A lot of these things can be more easily implemented if organizations invest in the adaptation of new technologies faster.

The threat landscape has become too sophisticated and pernicious for the problem of insecure software to be ignored. Fix-it-later is no longer a valid option if organizations want to protect their networks and, especially, their data, which has become the lifeblood of operations in every sector. While regulatory mandates help, the job ultimately falls to the software industry itself and its consortium of like-minded people bridging the gap between developers and DevOps teams of competing companies to ultimately deliver what’s best for the consumers.