How AI could bolster software supply chain security

SAN FRANCISCO -- While supply chain risks remain prevalent across enterprises of all sizes, Synopsys' Tim Mackey said AI tools will enable developers more than attackers -- at least for now.

Supply chain security was a significant topic that speakers and vendors addressed during RSA Conference 2024 earlier this month. The secure-by-design concept, which pushes for security first when developing software, was highlighted throughout the conference, particularly for AI projects. In addition, many speakers and cybersecurity vendors touted the benefits of AI for security, including in software development.

TechTarget Editorial spoke with Tim Mackey, head of software supply chain risk strategy at Synopsys, about his primary concerns with open source software, how supply chain risks can be addressed and what role AI could play moving forward.

Editor's note: This interview was edited for clarity and length.

What are you seeing across the supply chain currently? Are threats growing worse?

Tim Mackey

Tim Mackey: It's complicated. If you look at the world of how software is being built, one of the things that we're starting to see -- and you can go and pick any regulator in the world, any industry in the world -- they're starting to get into this mindset of what does it mean to deliver the proverbial high-quality, secure software at the speed of DevOps? Who has control?

If I'm a developer and I have whatever features I'm supposed to be working on, I might go and pick a bunch of open source stuff, and I don't care because it works. That's a different kind of relationship than if those things came from a commercial vendor. If it's a commercial vendor, I can exert some sort of influence over doing it the right way. In open source, they don't care.

Do open source developers verify whether there are bugs or vulnerabilities in their code?

Mackey: They do and they don't. I segment the open source space into the enthusiast role that might have, say, half a dozen or fewer core developers, and typically one. At which point, [they think,] 'It works for me, use it at your own discretion.' GitHub will tell you they have a hundred million repositories out there -- a lot of them are the same code, a lot of them are homework assignments, a lot of them are someone's passion projects.

When you get down to the ones that are actually mainstream, you're typically in the 2 to 3 million range [of repositories]. The rest of them are something else. If I'm a random developer, one of those [other projects] may be close enough for me. And if it's sample-ish code, well, I don't know what it is, so I may cut and paste it indirectly. You start to have all these different vectors by which unknown, suspect code comes in, and then if you want to overlay today's hotness of AI, it just makes it much worse.

Is AI making it easier for attackers?

Mackey: It kind of isn't because they don't necessarily know anything more about the [software] community they're attacking than they did before. Where AI is showing itself to be advantageous is helping developers do more. It provides some sort of assistance capability.

The more we can use AI on the good side for security, quality and stability purposes, the better the chance that we're going to have at the attackers being defeated.

People are saying, 'I want to do better, but I don't know how.' Historically, I might have this technology that says 'bad thing here,' but I still need to figure it out. AI is starting to give me the ability to figure it out a little bit. The real sweet spot right now is, can I code better? Someone who's been coding for three or four years, they're going to code at a different level and quality compared to someone who's been coding for a dozen years.

To an extent, it's almost like they have a mentor over their shoulders. AI doesn't know all the context, so the human still needs to do all the work, but as far as the 'code is code' part, that's where AI can really help out. At this point, it's enabling developers more than attackers. The more we can use AI on the good side for security, quality and stability purposes, the better the chance that we're going to have at the attackers being defeated.

What problems are top of mind for you regarding supply chain security? How can they be addressed?

Mackey: If you look at the supply chain, the people who are creating the foundational components don't know what the end product is, so they're testing something to their quality. How does the end person know? One of the big things I'm working on in supply chain right now is asking, 'How do we communicate from the developers to the people who are actually consuming this [code]?' If we take it to a greater level of transparency, of trust in the relationship, then we're in a much better position.

All of these artifacts are attached to the software to document proof that the right testing was done. I can now go validate all that and build intake protocols around that. For example, should the software be used in this environment versus that environment? Now, that's collaboration. Risk management in the supply chain is all about measuring the decisions that were made somewhere else in the chain.

How can the industry build that communication?

Mackey: It's going to be slow, and the reality is most legal teams don't want to provide that kind of information because it's going to reveal some secret sauce somehow. If you look at what CISA's put out about guidance, they have a theme of secure by design. But if you hear the talking points, it's actually secure by demand. If we don't ask them to be secure, why should we expect the security to be provided for free? Let's ask for things to be secure upfront and communicate our security needs upfront. That whole 'worrying about security later' thing? That's got to go.

There have been recent supply chain attacks on GitHub. Is the platform a growing target?

Mackey: The problem with GitHub or any of the software repositories is at some point someone's going to have to take that code. We haven't done a great job at training developers that 'this is good, that's bad' when choosing something to include. It's about functionality, and that puts the onus on the consumer of the software to do the right thing.

If you take the average GitHub project, I challenge you to tell me how it was tested. Tell me what unit tests were actually there. Tell me if they passed, or when they passed. It's the not-fun part for developers, and developers want to have fun.

Do you think the influx of vulnerabilities will continue to increase?

Mackey: Last year, the number was close to 80 [new] vulnerabilities a day. This year will have an artificial bump for two reasons. First, the Linux kernel people have decided to put every single Linux defect in as a CVE because they don't always know at the point when the defect is disclosed or reported whether or not it's a vulnerability or just a bug. They decided we'll treat everything as a CVE. Hopefully they don't end up running around like the boy who cried wolf. Second, there's also an initiative to have hardware issues also have CVEs. We have less of that today, but if you think about, Intel had some processor issues a few years ago -- that would be an example. They're trying to make [CVEs] more consumable.

What do you recommend for enterprises when it comes to supply chain security?

Mackey: Something I've been saying for years: You need to know all the software you have. The thing is that different teams view what software is differently. The people who own servers don't realize there's a pile of firmware inside the server, therefore [they're] an owner of software, and a bunch of software at that.

Arielle Waldman is a news writer for TechTarget Editorial covering enterprise security.