Why the SBOM is just the beginning of software supply chain cybersecurity

The more daily life becomes software dependent, the more urgent the need for organizations deploying software – including federal agencies – to ensure security in the software supply chain.

That supply chain has several main channels, principally open source components, custom coded and commercial applications.

“There’s not necessarily clean delineation. Those can all kind of come together in one unit,” said Kelly White, the co-founder and CEO of RiskRecon, a Mastercard company.

The software supply chain security question has developed in stages, White said on Federal Monthly Insights – Software Supply Chain. His own cybersecurity experience dates to when the principal concern was safe code for custom applications. The Open Web Application Security Project (OWASP), established in the late 1990s, still guides people coding and deploying online applications. The widespread adoption of open source components somewhat later.

“We really started thinking critically about the implications of open source,” White said. “Even more recently, we’re thinking about the whole software supply chain from starting to write code and the code repositories, the release management and the testing, and all of those steps in deployment that make up that whole cycle.”

White noted, “Even commercial software uses open source libraries,” which means a risk management program would need visibility into the parts that make up a commercial application.

That’s why, White added, “the software bill of materials (SBOM) is absolutely rising in importance, and what is the anatomy of the software that you have, down to each layer.” Beyond the SBOM, though, White said you need visibility into each supply chain member’s processes and the provenance of each component.

A zero trust architecture, White said, provides a good backstop for unforeseen attack vectors the SBOM and other analytic techniques might have missed. The Log4J attack, for example, exposed a vulnerability few organizations even knew they had.

“Log4J was very much a back end utility component that wasn’t even directly visible from the internet,” White said. “A lot of people didn’t even know they were operating it; they didn’t know where it existed to their environment.”

He added, “We have to operate with some humility, and an expectation that we’re going to have to respond quickly to these types of events as the threat landscape changes, based on new vulnerabilities being discovered.”

RiskRecon helps organizations, White said, by maintaining cybersecurity assessments and ratings on software suppliers across the industry. For example, he said, “Through our system, and our analytics, the data that we collect from the outside in, we were able to identify indicators of systems that were running Log4J,” and could alert customers.

With such analysis of everything an agency might be running, the security staff will be able to make more informed vendor selections and fine tune its risk management approaches to all the software elements in the agency’s environment.

“It starts with having a really good foundational understanding of yourself and of your suppliers,” White said. “What is my risk surface? What is my attack surface? What is my software bill of materials? What that awareness you’re positioned to not only take proactive measures, but when incidents arise, you’re able to respond more rapidly and more effectively.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.