[0:08] Shinobi: Hey everyone, I’m Shinobi and welcome back to Sushi Bites, the podcast where we breakdown software risk without breaking your development flow. And as always, I’m joined by my Co-host, Gen.
[0:19] Gen: Hey everyone, great to be here.
[0:22] Shinobi: And great to be recording our second episode of Season 2. Well, for a long time, software composition analysis had one job find open source packages in our application and call out unfriendly licenses and known vulnerabilities. And it did that job really well. But software didn’t stand still. AI started writing code, developers started contributing upstream, and regulators started paying attention. So today we’re asking a bigger question.
[0:50] Shinobi: Is your SCA investment still pulling its weight? To help us answer that, we’re joined by Aaron Branson, author of the 2026 Outlook for Software Composition Analysis. Think bigger and expect more from your investment.
[1:06] Shinobi: Aaron, welcome to the show.
[1:07] Aaron: Thanks, shinobi. Congrats to you and Gen on kicking off the new season. I listened to that last episode about the CRA deadlines. Really helpful in breaking through the clutter on that topic.
[1:19] Gen: Yeah, from CRA to SCA, we just love our three letter acronyms.
[1:24] Aaron: Well, I know you 2 like to move fast for your audience, so let me start with this. SCA didn’t fail, it succeeded, but now we needed to do more.
[1:35] Gen: That’s an important framing.
[1:36] Aaron: Yeah, teams focused SCA on open source license compliance and vulnerabilities because, that’s what mattered at the time and things were a little simpler. You know, complete components, known suppliers, known vulnerabilities, no regulations with teeth.
[1:53] Shinobi: But those assumptions don’t hold anymore.
[1:55] Aaron: Exactly. The software risk surface expanded quite a bit, but many teams are still using SCA like it hasn’t. Look, we’ve got at least three major changes. You could probably name more but consider this: number one.
- Source code is much more fragmented, with snippets of AI generated code being so easy to insert on the fly with no clear provenance or idea of how much of it is a copy of the open source it was trained on. So right away we have a gap in that code isn’t cleanly divided between proprietary source code and managed third party dependencies.
- Think about the economy of open source and how it’s changed. Teams used to grab an open source library to use it and keep it as is, so it was easy to patch later. But then teams began forking these packages to customize them to their liking, which was great for a time, but then that started causing patchability nightmares. So recently, the pendulum has swung toward corporate dev teams opting to contribute changes upstream to the open source community rather than make their own fork to have to manage. And that’s great, but that introduces the risk that corporate intellectual property might accidentally get contributed into that open source software and then be publicly exposed.
- And the third one, regulation is now real. You, you had strong regulation in place for industries like automotive, aerospace, medical devices. But now the scope is widening with things like the CRA software teams are trying to figure out how to wrangle SBOMs from all of their suppliers and consolidate that with their own SBOMs so that their product has a cohesive and coherent bill of materials for regulatory obligations.
[3:52] Gen: Wow, a lot has changed. So let’s start with the impact of AI generated code.
[3:59] Shinobi: Because now we’re not importing libraries. We’re pasting snippets with no metadata on provenance.
[4:04] Aaron: That’s right, AI tools generate code fragments that may reuse open source, source available, or something in between. You know who knows?
[4:14] Gen: Which breaks the idea of neat component-level scanning.
[4:17] Aaron: Completely. AI introduces fragment level risks. Sometimes just a few lines, but those lines still carry legal or security implications. Unfortunately, there’s no simple universal rule like X lines of code is a copyright infringement. That’s just it’s just up to the legal teams to figure out on a case-by-case basis.
[4:39] Shinobi: And sometimes the temptation is to crank sensitivity to 11.
[4:42] Aaron: Which backfires because too much noise kills development productivity. The real value is accurately detecting meaningful OSS fragments introduced by AI without having to flag half the code base.
[4:57] Shinobi: Alright, let’s flip the risk direction. Developers contributing back to open source.
[5:02] Gen: Which leadership usually wants.
[5:04] Aaron: Yep. It improves maintainability. It gives developers the chance to be part of a community also. But it also creates outbound risk.
[5:14] Shinobi: Internal company owned code accidentally pushed to public repos.
[5:17] Aaron: Exactly. Most teams use SCA to scan what comes into their code base, but almost nobody scans what goes out.
[5:26] Gen: And once it’s public, there’s no undo.
[5:28] Aaron: Yeah, once it’s out, there’s no telling where it’ll end up. Scanning developer contributions before submissions let’s teams contribute safely without putting legal into damage control mode.
[5:40] Gen: OK, now let’s talk regulation, specifically the EU CRA.
[5:46] Shinobi: Because this isn’t a checkbox exercise anymore. We learned in the last episode there are real milestones for enforcement coming up.
[5:52] Aaron: Yep, the CRA mandates SBOMs explicitly vulnerability handling and supplier accountability. But you still have to read the fine print first to see how your company and your product are affected. There’s unfortunately no replacing that legwork.
[6:08] Gen: And most software, especially physical products with embedded software rely on a long chain of suppliers. Think automotive, how many suppliers and suppliers suppliers are involved.
[6:19] Aaron: Exactly. You know you’re asking for and hopefully getting SBOMS from all of your suppliers and contractors but trusting them blindly is really risky.
[6:29] Shinobi: But how can you even begin to review these? Manual validation doesn’t scale.
[6:34] Aaron: Not at all. SCA should ingest, consolidate, and validate SBOMs automatically. Cross checking supplier claims against real intelligence about software components, and I’d say there are actually two levels:
- What I’ll intentionally call “validation” meaning is this SBOM a properly formatted SPDX or Cyclone DX file with all the metadata fields expected for my industry requirements.
- Second, that’s what I would call “verification” meaning that’s great that it’s valid but is it correct. Does it have the most accurate and up to date provenance, license, copyright, and vulnerability info related to the components it claims to have? That’s another layer to expect from your SCA tooling.
[7:24] Gen: So it seems in the past compliance was allowed to be reactive if needed. The team would cobble together an SBOM when requested. But now supply chains are so deep and regulators are asking so compliance has to figure out how to be continuous.
[7:39] Aaron: That’s right. Yep, from reactive to proactive. And it is just not practical without automation from your SCA tooling.
[7:47] Shinobi: Nice, so let’s land this. If companies think bigger like you suggest in your article, what should they expect from SCA?
[7:55] Aaron: You know, I’d point to three things.
First: Accurate detection of OSS fragments introduced by AI without an explosion of noise. That’s the way software development is going.
Second: Scan developer contributions before they go upstream to prevent IP leakage. Teams want to get away from managing their own forks and that’s smart but put the guardrails in place for your engineers to contribute upstream safely.
Third: Ingesting, consolidating and validating SBOMSs across suppliers to automate this regulation ready evidence that you’re going to need. The big manufacturers already know this, but just like PCI DSS gave teeth to proper credit card data handling and GDPR made data privacy enforceable, the CRA is going to step up application security and software supply chain integrity. And that’s great because things are moving really fast with AI and it’s smart to have a seat belt.
[8:57] Gen: Then let’s buckle up! That’s clearly a much bigger value story than only using SCA for making sure your engineers are using allowed open source packages.
[9:06] Aaron: It is that that made sense then. But now we need to use SCA for how software is actually built today.
[9:13] Shinobi: The takeaway for me is simple, Aaron, SCA didn’t get less important – It got more strategic.
[9:19] Gen: But only if you expect more from it and put it to work.
[9:21] Aaron: Nailed it.
[9:22] Shinobi: Aaron Branson, thanks for joining us.
[9:24] Aaron: Thank you, guys. It was fun.
[9:26] Shinobi: And to our listeners, check out the 2026 Outlook for software composition analysis. Until next time, build fast, govern smart, and make your tools earn their keep.
