A secure software supply chain has become essential to fulfilling government missions. Massive cyberattacks like SolarWinds highlight the serious risks to the enterprise that insecure software can create.
Some corners of the government, such as the intelligence community, have long understood that building software rapidly, efficiently, and securely requires an optimized – and secure – supply chain. Now, organizations across the public and private sectors are acutely aware of the need to ensure security throughout the software lifecycle. President Biden’s Executive Order on Improving the Nation’s Cybersecurity reinforces this notion.
MeriTalk recently connected with Matt Howard, executive vice president and chief marketing officer at Sonatype, which provides developer friendly tools for software supply chain management and security, to discuss the executive order (EO) and its potentially game-changing effect on the nation’s cybersecurity posture.
MeriTalk: We’ve talked about supply chain security for a long time in government – but software supply chain security is a newer concept in some corners. Is it finally having its moment in the sun in 2021?
Matt Howard: Supply chain security has been around for decades in the context of physical goods. Consider back in the 1950s, when Edwards Deming famously worked on his supply chain optimization theory with then-nascent Japanese automobile manufacturers. He taught them to optimize the physical supply chain by sourcing the best parts from the best suppliers, tracking those parts through the supply chain, never passing known defects downstream, and having a bill of materials in the event of a recall. Those concepts are directly relevant to the software supply chain.
For example, a brake supplier in context to Toyota is a Java, JavaScript, Ruby, or Python library supplied to a developer. If the government buys a car and the airbag goes bad, it should have an easy way to return the car to a dealer to get it fixed. If the government buys software from a vendor and an open-source library has a vulnerability, the government should have a way to turn the application back to the vendor to get it fixed quickly. It’s really quite simple.
Manufacturers want to manage and optimize the hygiene of a physical supply chain for the same reasons agencies want to manage and optimize the hygiene of the software supply chain. Conversations about building security into software instead of bolting it on have been percolating in the Defense Department and other parts of the Federal government for years. It’s good to see software supply chain security front and center in the EO. It has a long way to go before it is foundational and standard, but the EO is an important step in that journey.
MeriTalk: The new EO sets many requirements – from directing agencies to move to the cloud and zero trust architectures to standardizing the Federal government’s playbook for responding to cyber incidents. What is the low-hanging fruit in the EO that can be accomplished fairly quickly and without a lot of cost?
Howard: To better protect our national cyber assets, we need more information sharing. If you see a breach, say something. If you experience a breach, say something. If you’re a software vendor or an IT services provider and you’re breached, say something. It’s basic and should be encouraged. There are reasons why technology companies historically haven’t wanted to readily disclose a breach – it can be embarrassing. But it’s not hard to do, and I imagine the agencies designated in the EO could put something forward to that end without a lot of complexity or funding.
Industry can be transparent about software that is built and delivered to government customers. It’s doable today. The software bill of materials (SBOM) mandate in the EO will make customers more confident in the applications they are running, and ultimately, will reduce the government’s cybersecurity risk.
MeriTalk: What should Federal systems integrators, software firms, and agencies do now to prepare to meet the requirements of the EO?
Howard: It’s an opportunity to reflect on their cybersecurity journeys. Some will feel confident in their cyber hygiene and their ability to comply with upcoming requirements, and some will recognize that they have a lot of work to do.
Roughly $160 billion is spent per year on cybersecurity globally. It’s been that way for more than a decade. It’s sobering to reflect on how much money has been spent trying to solve this problem, when in reality, it’s akin to being on a treadmill. No one is winning the race to security on a treadmill, but we have to at least keep a sustainable pace. The EO presents the opportunity to assess the progress we have made over the years, adjust our pace as needed, and chart a path forward.
MeriTalk: Let’s talk a little bit more about SBOMs. The EO requires vendors to provide SBOMs to Federal agencies. How prevalent are SBOMs today?
Howard: They’re increasingly prevalent inside of organizations that are building software as a strategic differentiator in for-profit corporations in regulated industries – banks, for example. Banks generally will have an SBOM for the applications they build because it’s in their interest. They don’t want to be breached, and they don’t want regulators raining on their parade. The SBOM is used internally to manage and maintain their hygiene as it relates to software development.
It’s very different in the case of a customer purchasing software from a commercial vendor. Historically, if a customer asked for an SBOM, the vendor would say no. The vendor would refuse any liability – that’s the way the software industry works. But the EO takes a small step toward addressing the issue of software liability – and a much bigger step toward broader adoption of SBOMs – by requiring SBOMs for software sold to the Federal government. The Biden administration is using the power of Federal purchasing to influence the software industry, and that could have a trickle-down effect of making SBOMs broadly available in the commercial market as well.
MeriTalk: Do you believe the SBOM is going to be a game changer for software supply chain security? If so, for whom?
Howard: Let’s be practical. Software is the last path of differentiation in any industry, including the government, and it’s one piece of the larger digital transformation pie. I’m not sure anything really is “game-changing” when the game itself is so enormous, but small, basic steps can have an exponential impact on the evolution of massive systems. I think the SBOM has the potential to be that for government. It’s not pie-in-the-sky policy. It furthers hygiene; it creates transparency; it offers the ability to understand the software development workflow from the beginning to the middle to the end. It just makes sense.
Think of the SolarWinds breach, for example. That compromise was very different from any we’ve seen before because those adversaries didn’t breach an application in production. To use the auto manufacturing analogy, they went into the car factory, and they injected malware as the car was being manufactured. The point is that through small steps such as an SBOM, you can achieve fundamental change. The SBOM mandate in the EO is fundamentally good policy, and fundamentally achievable from an industry perspective. It will absolutely have a positive effect on improving our nation’s cybersecurity posture.
MeriTalk: To your point about SolarWinds – security issues can be introduced at any stage. How can agencies ensure the integrity of their code? And how can Sonatype help with that process?
Howard: For the code that agencies buy from third-party vendors, the SBOM will improve transparency. For the code that agencies are developing internally, they need an automated, scalable way to build guardrails into the developer workflow. Those guardrails allow developers to receive rapid feedback on the software that they’re building, whether they are using open-source libraries, writing custom code, or both. It’s similar to spellcheck when you’re typing in Word. You see the misspelling, and you fix it right then. When developers are aware that they made a mistake that will introduce a vulnerability if that mistake isn’t fixed, they will fix it. Automation that helps developers fix mistakes as they’re innovating in the developer workflow can dramatically limit vulnerabilities.
Sonatype provides automation to software development teams, application security teams, and IT operations teams that allows them to ensure the quality of the code they create from the very beginning. We respond to our customers’ needs, whether it is making sure they are sourcing the best parts from the best suppliers, tracking the location of those parts through the software supply chain process, or creating an SBOM. And our solutions can be implemented in a completely disconnected or air-gapped environment for customers that require it.
You wouldn’t buy a car and take it to an aftermarket dealer to ask for seatbelts to be put in. It’s the same with software. You should build the security into the software as you’re building the software. That’s what Sonatype offers.