The Move to Modernize Ops Will Increase the Need for Software Supply Chain Security

It is no surprise when security aspects of the software supply chain are threatened these days. First log4j hit the news and sent everyone scrambling to mitigate the very pervasive and problematic vulnerability in the software supply chain.

More recently, Spring4Shell popped up on our radar; yet another framework-introduced vulnerability causing chaos for enterprises needing to address the threat.

So, it was somewhat pleasant to see GitHub introduce new functionality targeting the security of the software supply chain. It was especially pleasant after having digested Sonatype’s latest State of the Software Supply Chain report, in which they provided statistics that should scare any security-minded technologist, no matter their role. Of note:

• There are 37 million OSS component versions now available
• 29% of popular projects contain at least one known security vulnerability
• 650% YoY increase in cyberattacks aimed at open source suppliers

These findings are particularly troubling because the report determined that “the average modern application contains 128 open source dependencies.”

Now, you know I’m not a fan of doing math, but let’s do some.

In the 2022 State of Application Strategy, we find several statistics worth note:

• Modern applications (container-native and mobile) comprise an average of 33% of the enterprise app portfolio
• Enterprises across all industries maintain an average app portfolio of about 200 applications

So, 33% of 200 means the typical enterprise has an average of 66 modern applications in its portfolio. Using Sonatype’s open source dependency average, which means the average enterprise could be carrying the burden of securing 8448 different open source dependencies. Now, there’s almost certainly overlap across applications. Container-native apps almost always share the same container orchestration environment (Kubernetes is the king of COE right now), and thus the burden is actually lower in terms of specific dependencies but not in the sense that every one of those instances needs to be updated in the event of a vulnerability.

Without doing more math, let’s just all agree that securing the software supply chain today is a significant undertaking given the size of app portfolios and inclusion of open source dependencies.

GitHub’s new functionality helps address that by “finding and blocking vulnerabilities that are currently only displayed in the rich diff of a pull request.” In other words, it integrates into the CI/CD pipeline and scans, in real time, for known vulnerabilities.

Cool. That’s not an unusual capability. DevSecOps has been driving this type of “shift left” security motion for years now. Most CI/CD pipelines, regardless of tooling, are capable of performing security scans on code. Not all, however, integrate the ability to scan for known vulnerabilities that may be deeply hidden in dependencies or the result of a logic error that is not as easy to detect.

Now, of course you should be including as much security in the CI/CD pipeline as possible to root out vulnerabilities and errors that can bite you in the derriere later. But that’s not why we went through this exercise.

SRE, Software, and Supply Chain Security

The reason I call out the issue with the existing software supply chain is that it’s only going to get worse as organizations modernize ops with SRE approaches. That’s because at its core, SRE practices depend on automation which, as I’m sure you know, depends on software and scripts, many of which are—wait for it—open source.

In fact, it shouldn’t be surprising to learn that many of those open source tools used by DevOps will be used by SREs. If you wanted to simplify the roles and relationship, SREs are DevOps for production. While DevOps practitioners typically focus on the software build and release pipeline, SREs focus on the software operations pipeline. That means not only the apps but the app security and delivery services as well as platforms and environments (like core, cloud, and edge). The scope of SRE personnel spans the IT stack, making their task significantly more difficult when it comes to securing the software supply chain.

Suffice to say, the security of the software supply chain should be a concern for all organizations because it impacts the entire application lifecycle—from development to build to release to deployment to operation.

And it should be a concern for organizations hoping to survive their digital transformation journey. There’s a significant shift coming to enterprises everywhere, and it impacts the very heart of the organization: the enterprise architecture.

Most enterprise architectures were established decades ago, based on frameworks developed under the premise that resources were fixed and inflexible and that the data center was the focus of the business universe.

None of that is true anymore, and even if it was, the business has changed, too. That business is now increasingly digital, and a digital business with data-driven processes cannot be adequately represented by an architecture designed to represent a physical business with human-driven processes. The enterprise architecture must be modernized, and in doing so, new domains must be incorporated—like that of SRE operations.

And they are. Our research this year found 37% of organizations have already embraced SRE operations to modernize apps and ops, and another 40% are planning to in the next 12 months. That means tooling and scripts, software and data, and an entire stack of technologies that will support this new role within the organization.

And with software and scripts and stacks comes supply chains and security. And the one thing we’ve learned from DevOps that you cannot ignore as you modernize ops is that SRE practices will incur much of the same technical debt and security challenges.

The good news is that, unlike DevOps and build processes, SRE operations will be a new practice for organizations. And establishing new practices means establishing new ways of operating—including building security in at the very beginning.