Wielding Federal Buying Power to Improve Software Assurance

May 20, 2021by Pat Muoio

By Patricia Muoio

The recent Executive Order on Improving the Nation’s Cybersecurity (EO) offers the promise of delivering on two important ideas: the substantial buying-power of the federal government is strong enough to influence the products in the marketplace; and we can and should improve the quality of our software. By using its place in the market as a driver for improved software, the government is taking an important step away from the previously unsuccessful (and in my mind mis-guided) strategies that attempt to improve cybersecurity using warlike or anti-crime thinking toward the strategy of treating cybersecurity as an integral aspect of how we do business. By insisting on high quality code from its suppliers, the government is moving away from the notion that bugs cannot be stopped, and we can only stop the people trying to exploit them and toward the notion that the best way to stop exploitation is to limit the opportunities to be exploited. Both of these movements are extremely positive steps in the right direction. Both of these notions are also central to the SineWave investment thesis and have shaped our selection of cybersecurity companies like SentinelOne and ShiftLeft.

The government spends billions on software products. Surely it is entitled to insist that those products cannot be used to cause them harm. And surely product developers will not take the potential loss of this big spending customer lightly and will adjust their development processes to meet this new requirement. But, some will worry, won’t this make government software more expensive or slow to deliver? Won’t this force us down the path of government-specific development and make the government unable to take advantage of innovations in the private sector? Fortunately, these undesirable consequences need not be the case. Code analysis and software development technology has evolved to the point at which low-latency code analysis can be integrated into the DevOps process to isolate, and even suggest remediation for, software vulnerabilities with little cost in dollars or time. Just as code is scrutinized to check for performance and fulfillment of functional requirements as part of the code check-in process, it can now be checked for vulnerabilities. Developers can quickly fix security bugs much the same way they fix other software bugs. The cost of adding this security functionality is offset by the cost of code redo when vulnerabilities are found later in the process. Products exist that can do this analysis with low latency so including it need not delay delivery of functionality. And this relatively painless modification to the DevOps process to satisfy the government requirement will benefit commercial customers as well, so it is pointless not to simply make it the process for all products. The new mandate for high assurance code need not be a reason for Beltway Bandits to rub their hands in glee at the prospect of additional revenue or market share. Rather, it is a call for commercial software developers to recognize that cybersecurity is an ancillary requirement of all code, just like performance and other “-ilities,” and to address it in their normal development process. Developers need to own their role in improving the nation’s cybersecurity and SineWave is committed to investing in companies that enable them to do so.