Software Security: A Sounding Board for Needed Change

While funding software security research and development in the federal government from the summer of 2012 to the fall of 2017, I was interested in conducting a study around the Build Security in Maturity Model (BSIMM) to observe and identify commonalities in software security practices that mature organizations adopted and formalized as part of their software security program.

I wanted to better understand where the gaps existed in organizations that were performing at a high level versus those that are struggling to formalize software security practices. Many organizations are asked to do more with less, and having a baseline to develop a starting point that could ensure a sound foundation for building and developing secure software was a key priority for me. The questions I wanted to answer were:

1. What are organizations with mature software security practices doing that could be adopted and formalized in the federal government?

2. What are common software security practices that lead to better quality software?

3. What are key attributes and characteristics unique to organizations with mature software security practices?

Interesting Discoveries in Software Security Practices
I never got the chance to conduct the study but discovered something interesting during my podcast interview with former chief security officer (CSO) of Aetna, Jim Routh, who at the time was participating in BSIMM.

He said that certain BSIMM software security practices are common to each coast in the United States. He added that BSIMM data suggested that software is fundamentally built differently on the East Coast versus the West Coast, and it was evident when he talked to CISOs from the West Coast about software security. One example he gave was that organizations on the West Coast are more likely to build their own static analysis tools, while organizations on the East Coast are more inclined to purchase commercial static analysis tools.

The most interesting comment Routh made involved how those on each coast see their role in software security. He said that developers on the West Coast have more of a demonstrated responsibility for software security because they understand it's their job, whereas developers on the East Coast often think software security is someone else's job. Mature organizations get developers to understand it's their responsibility to write quality software. Bottom line, organizations on the West Coast understand software security is their responsibility, but there's a lot more awareness and education required on the East Coast.

As I read the Executive Order on Improving the Nation's Cybersecurity, I couldn't help but recall these data points from my interview with Routh. Clearly, there appear to be observed practices that mature software security programs implement and formalize that could be used to improve software security.

How can the industry as a whole adopt some of these key practices to improve software security?

Learning Your ABCs
It's no secret that a large part of the federal government relies heavily on supply chains for software solutions and is at the mercy of suppliers to adopt and implement mature software security practices commensurate to reduce risk in the software they deliver to the federal government. The Cybersecurity Executive Order (EO) in some ways proves there isn't any real substantive guidance, policies, or standards used by suppliers (that can be enforced, anyway) to deliver trustworthy software to the federal government. The ABCs of Section 4 of the Cybersecurity EO, Enhancing Software Supply Chain Security, strongly suggest that's the case.

The ABCs remind me of programs and initiatives I sponsored, attempted to sponsor, or supported while working in the federal government as early as 2013. As I read the ABCs, what comes to mind are the Underwriters Lab (UL) 2900 series standards for cybersecurity and the work Sarah Zatko is leading at Cyber ITL to evaluate software according to metrics and measurements that allow quantitative comparisons and evaluations of software.

Software Security Deja Vu
The UL has published at least five standards and guidance since 2016 for evaluating software security that in theory should be applicable across various domains like the Internet of Things, network-connectable products, enterprise software, and industrial control systems. Parasoft chief evangelist Arthur Hicken, myself, and many others in the software security community contributed to and participated in developing these standards and guidance.

But the ABCs from the Executive Order aren't new. There have been stakeholders from industry, government, and academia collaborating to improve software security practices for more than a decade. Unfortunately, not much progress or broad adoption has been made to improve the overall quality and security of software. While there is some optimism regarding the ABCs, the past teaches us not to expect anything impactful or anything that fundamentally changes behavior in the software supply chain ecosystem.

Build It Yourself
Maybe there is some truth to the BSIMM observations made by Routh, and possible key lessons and practices the federal government can learn from West Coast software development organizations about software security practices. For example, "build it yourself" — government should take full responsibility for developing and building software for mission-critical needs instead of relying on third-party integrators and commercial suppliers. For whatever reason, the federal government struggles and, in many cases, has failed to get third-party integrators and commercial suppliers to understand it's their responsibility to build quality and security in software they deliver to the federal government.

Perhaps the federal government needs to hire its own developers, as mature software development organizations do, where developers and the organizations are expected to produce secure software. It may be time for the federal government to consider a paradigm shift. Software is becoming such an essential thing that powers so many aspects of our daily lives, the sheer reliance and dependability on software requires and demands a philosophical shift from the norm.

Now or Never
If the federal government is going to have software that performs critical functions, it's imperative that it takes complete ownership, accountability, and oversight of software from concept to delivery and through maintenance. This will set the tone and demonstrate the seriousness of protecting this nation's critical infrastructure and services that are powered by software. This nation must seize this moment or fall victim to motivated and skillful nation-state actors working toward our downfall. It's now or never!