Turn software bills of material into something more than a compliance checkoff

More organizations worried about cybersecurity are turning to software bills of material (SBOMS). Getting them from software suppliers as a matter of compliance is one thing. Gaining cybersecurity intelligence from them is another. For advice,  the Federal Drive with Tom Temin talked with the General Manager of the Open Source Security Foundation, Omkhar Arasaratnam.

Interview Transcript: 

Tom Temin And just briefly, tell us about the Open Source Security Foundation itself. There are so many, like sounding cybersecurity, nonprofit groups, all doing great work, but they all have a little slightly different flavor.

Omkhar Arasaratnam The Open Source Security Foundation or the Open SSF, as we call it colloquially, been about three years now. And we believe that the security of open source software is a joint collaboration between the public sector, private sector and the community. And we act as agents to help coordinate those entities. So it started off, as I mentioned, about three years ago, just before. Log4J or Log4Shell if you want to go by the exploit name. And really spun into action after that. We focused on a variety of areas to do with supply chain security, building better security into open source. My background, I worked in the corporate landscape for about 25 years before coming over here, although I frequently used open source. And unlike a corporate environment where when you’re developing software, you may have a single point of change in which you can say, Hey, we need to do better. And this by using a better secure software development lifecycle in open source, you really don’t have that opportunity. It’s inherently bottoms up. It’s distributed. Everyone has their own way of doing things. So it’s quite an interesting challenge to try and determine how best to affect better security in open source. But the other side of it is also incredibly rewarding in that if you positively effect an open source project that’s broadly used, you have literally improved the security attributes for billions of people. Open source software is used everywhere, from cell phones to satellites to your personal computer. So it’s equally a challenging as well as rewarding environment to work in.

        We want to hear from federal technology leaders about how you are addressing current cyber demands and how your agency is making the most of its resources to improve its cyber posture. | Take our quick survey

Tom Temin And for federal agencies in particular that have always been huge consumers of software. It seems like the trend has shifted to the point where most of what they buy, software as a service, acquired software that they operate, whatever the case might be, or even have programed by systems integrators and so forth. Nevertheless is mostly open source in content. It’s almost like when you build a house. The carpenters don’t cut door frames anymore, you buy the whole frame and door and hinges and locks. It is one piece. So every house has the same doors. Are we to that point now where most software is open source?

Omkhar Arasaratnam That’s right. We believe about 90% of shipping software today is open source software. And that’s been through the development environment that the developer has linked to a common library such as Open SSL or Log4J or what you may have. Or it could be that it’s running on an open source stack like Kubernetes. But you’re 100% correct. And the advantage of this is software engineers don’t need to reinvent the wheel. Software engineers can focus on adding value by leveraging these existing packages with some phenomenal attributes and really focus on what’s unique about the software they’re developing. The other side of this coin, however, is when there are pervasive issues with the security of particular open source packages, as we saw with Log4J. The blast radius is quite big. And being mindful as to how to manage the risks associated with consumption of these packages has been an area of focus for us. We’ve also worked, as I mentioned earlier, in conjunction with public sector here domestically, so with the Office of the National Cyber Director, ONCD, with [Cybersecurity and Infrastructure Security Agency (CISA)], with [Defense Advanced Research Projects Agency (DARPA)], with many of our colleagues in the federal government. In fact, we are strong proponents of the recent CISA open source software security roadmap that they put out, which reasons over not only how our agencies and critical infrastructure should be consuming open source, but also how they can contribute back. One of the key characteristics of open source is that it is free for everyone to consume, but there’s also a community aspect or expectation that improvements are committed back to the community. So it’s really encouraging to see the way that this administration has gone forward in terms of embracing open source and making it more secure.

Tom Temin We are speaking with Omkhar Arasaratnam. He is general manager of the Open Source Security Foundation. And that gets us to the software bill of materials question. Then when you obtain one and under presidential executive orders, agencies are required to do this. And as you have pointed out publicly, more and more private organizations are demanding SBOMS from their suppliers. Basically, you’re getting a library of Legos, you might say, to make an analogy. And so how can you operationalize that SBOM in a way to enhance cyber security and not just make it something, well, we promised we would get one and here it is. A big digital document that nobody reads.

Omkhar Arasaratnam That’s a great question. I’ll reflect back on a couple of things. One, back in September, we had a great meeting under the request of Ms. Neuberger from the National Security Council to assemble a group of public sector and private sector leaders in order to establish a bit of a beachhead as to how we were going to continue to improve the security of open source software. One of the topics that came up as an outcome of that meeting was a strong focus on how to operationalize SBOMS. Now I’m going to say something controversial. SBOMS on their own do not afford any security attribute. They don’t make security better on their own. They only make security better once you use them in ways that are beneficial to operational security or the security engineering of the products you build. Now, the precondition to that is establishing a standard format. So if you’re going to be writing down all these things in a software building material, ideally you want them to be machine readable, you want to be able to draw references to this data in order to let the computers do what they do well, which is process data. So you may choose a format like SPDX, which is a SBOM format hosted within the Linux Foundation. The next aspect to poorly quote Shakespeare is, what is in the name. And CISA recently completed their request for comment on software naming standardization. Why is this important? Well, unfortunately today we name our software packages in a litany of different ways. So it could be Open SSL, it could be open SSL 3.2, it could be RedHat/Open SSL 3.2. And while these kind of considerations may be trivial, coming up with a canonical naming standard allows us to make better programmatic decisions. Now, how can SBOMS be used in production? Well, the next time there’s a vulnerability, and I believe there was recently last week, an Apache struts vulnerability that came out. And if Apache struts sounds familiar, it was the package whose vulnerability led to the exploit of Equifax a few years ago. So another big bad vulnerability with Apache struts came out last week. In an ideal state, once you have all these SBOMS in a native format like SPDX, and once you’re using a consistent naming format, you should be able to go through and very quickly identify all the instances of Apache struts within your organization and then use that information, combined with other asset inventory information like is this an Internet facing server or is this a development server behind a firewall in order to reason over how quickly you need to address the vulnerability and what the most effective way of addressing it is? You may find that the Apache Struts instance that you’re for a particular entry in your inventory may belong to a vendor system where you have to go wait for the vendor to update their build, and that will fork down a different road than if this is in-house develop software running on an Apache Strut server that you have the opportunity to upgrade yourself.

Tom Temin Or you could lean on that vendor, I suppose, and say, Hey, fix this. We found something you may not have known about. And that naming convention, that’s kind of one of the oldest challenges in information technology in some sense. I remember many years ago when the Pentagon was trying to come up with common language for software that had data elements, I think it was. So my question then is I’m getting a sense of aroma coming from the kitchen here, and that is artificial intelligence as applied to the bomb and to the cyber question in general. Can you comment on that one?

Omkhar Arasaratnam Absolutely. Let me add one more plug for some of the work we’re doing around SBOMS. We have three big annual events at the Linux Foundation Open Source Summit North America, Open Source Summit Europe and Open Source Summit Japan. We just got back from Japan. North America’s next, it’ll be in Seattle. In Seattle. We intend on doing a tabletop exercise where we pretend that a new vulnerability has come out and then using tools like SBOMS, we identify the optimal path for people to take in order to respond to the incident. Things like tabletop exercises aren’t novel. We’ve been doing them for years, whether it be in the military or in financial sector. But it’s about democratizing access to these kind of run books. So smaller organizations may benefit from that as well. Look for that coming out in the spring. Now, as it comes to AI, two ways that I’m thinking about I and the foundation’s thinking about AI. On one hand, I believe it was, I forget who it was now. There was recently a publication on the security of AI, I believe it was actually from [Government Communications Headquarters (GCHQ)] in the UK. It was in conjunction with NSA and some of our federal friends as well. It’s cited that using things like SBOMS to identify the composition of these different machine learning models would be critical. As an engineer, there’s two things that we like. Consistency and determinism. Consistency, meaning the same input should give the same output. Determinism, meaning that the algorithm will only provide one path out rather than it varying ensuring that we understand how these very complex large language models work and then we can correct them when they go awry. I think it’s going to be critical to the maturation of large language models in generative artificial intelligence going forward.

Tom Temin It sounds like then that the cybersecurity ultimate activity in any organization, including a federal agency, is becoming much more of a team exercise because of the different disciplines you need to impinge on the SBOM and just general analysis of what you’ve got running in your systems.

Omkhar Arasaratnam Absolutely. I think the other area that I’m really excited about, applying artificial intelligence, large language models, generative AI, is in how to tackle this vexing problem of open source software security. As I mentioned earlier, unlike normal enterprise software development, there isn’t a single software development lifecycle that you can turn to insert a security check and make everything better. Instead, open source maintainers have to comb over thousands of pull requests, which are contributions from the community prior to incorporating them into their code base. And there just isn’t an efficient way of doing that. One of the areas that we’d like to see further work and application of technologies like artificial intelligence is in making this easier. So we’re extremely excited to partner with DARPA on the AI Cyber Challenge or AIXCC. My friend and colleague Perri Adams just did a livestream about this yesterday. It’s a two year DARPA challenge, and the challenge is to address large classes of open source software security issues using large language models. The idea being to turn the computer and the artificial intelligence loose on all this open source software and get the large language model to automatically generate secure code where there may be insecure code.

        Read more: Cybersecurity

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