Open source is now the standard for the software industry. Proprietary software is no longer the Goliath it once was.

As the demand for more transparency yet better security increases, the challenges that arise from that put into question who is liable for that?

“I know that there’s a lot of people in the industry, and open-source communities that are talking about this doing some lobbying to try to be like, ‘Hey, can we dial this back a little bit?'” says Vincent Danen (pictured), vice president of product security at Red Hat Inc. “I am concerned they they’re going to make decisions before the full ramifications are realized.”

Red Hat’s focus is aligned with transparency. If you want to see the vulnerabilities in the code as you are building it, you want to be able to do that before you release it to a customer, not after you release it, according to Danen.

Danen spoke with theCUBE industry analysts John Furrier and Rob Strechay at Open Source Summit NA, during an exclusive broadcast on theCUBE, SiliconANGLE Media’s livestreaming studio. They discussed the significant and disruptive influence of artificial intelligence and how to engage the next generation of contributors in the open-source community.

The good, the bad and the ugly

Does AI generate good code? Does it generate bad code? Can we trust it? These are the questions industry leaders are asking themselves. The marriage between software bill of materials, or SBOMs, and vulnerabilities adds to the dilemma of global regulation, according to Danen.

An SBOM is a list of programs that constitute the software a company is using, but that doesn’t include a list of programs with user-reported challenges.

“You go to a grocery store, and there’s some bad food sitting on the shelf,” Danen said. “I can see the list of ingredients, but I don’t know from that list that it’s bad. I have to look at a different source, a recall list, to know I either shouldn’t buy that or I should throw it away if I already did. Other vendors provide other sources of vulnerability information. You marry that with your bill of materials, and now you have a better picture of what it is that you’re actually looking at in terms of software that you have installed.”

Red Hat’s Component Registry, or Corgi, aggregates component data across Red Hat’s supported products, managed services and internal product pipeline services. If you scan your data post-attack, bad information could be pulled back, affecting that data as a real source of truth, according to Danen.

“The right way to do it is to collect all that information as you’re putting things into your container or your build or whatever,” Danen said. “We know what it looks like because we built it this way at this time. And then once that gets released, we already have that corpus of data that says this is what the SBOM will be.”

Here’s the complete video interview, part of SiliconANGLE’s and theCUBE’s coverage of Open Source Summit NA:

(* Disclosure: Red Hat Inc. sponsored this segment of theCUBE. Neither Red Hat nor other sponsors have editorial control over content on theCUBE or SiliconANGLE.)

Photo: SiliconANGLE