Supply Chain Risk Became Everyone's Problem

The attack surface that matters most in 2026 is not the one trying to breach your perimeter. It is the one already running inside your stack — in the open-source libraries your team pulled in last quarter, the CI/CD tooling in your deployment pipeline, and the routers sitting on your network.

In this episode, host James Winegar is joined by Jamil Bou Khair, founder and CEO of Firezone, and Brian Manifold, senior full-stack engineer at Firezone, to discuss what software supply chain security looks like when AI is collapsing the cost of finding and exploiting vulnerabilities. The conversation is grounded in the March 2026 Trivy incident, where attackers exploited a misconfiguration in Aqua Security’s GitHub Actions environment to publish a malicious binary that was live in distribution channels for nearly three hours. Jamil returns to Eventual Consistency after discussing Zero Trust network access in Episode 2.

The discussion covers hardware supply chain risk — including the US government’s ban on foreign-made routers and the chip provenance problem it does not solve — alongside practical defensive architecture: dependency cooldown periods, SHA pinning, IP allow-listing across SaaS platforms via Firezone, and why writing your own small dependencies rather than pulling in shared libraries may become a legitimate security strategy when AI drops the cost of generating exploits to near zero.

Key Takeaways

Supply chain attacks exploit what is already trusted, not what is trying to get in.

The Trivy vulnerability followed a pattern that is becoming the norm: attackers compromised a GitHub Actions workflow, extracted a privileged access token, and published a malicious binary through legitimate distribution channels. The attack did not break through a perimeter. It exploited trust already built into the pipeline. When CI/CD tooling, dependencies, and hardware are all potential vectors, perimeter security stops being the primary line of defense.

AI collapses the economics of vulnerability discovery, and defenders have not caught up.

The cost of generating a proof-of-concept exploit is approaching zero. An attacker can point an LLM at a widely-used library, find a vulnerability, and produce a working exploit faster than most security teams can triage a ticket. Jamil and Brian argue that automated red-teaming and continuous vulnerability scanning will need to become standard engineering practice, not a periodic audit. The open question: who pays for this compute, and does it remain economically viable outside of large enterprises and banks?

Blast radius reduction matters more than perimeter strength.

When breaches become a matter of when rather than if, the question shifts to how bad it gets. Zero Trust segmentation, principle of least privilege, and component-level firewalls limit what an attacker can reach after initial compromise. Firezone routes traffic to specific applications through identity-aware tunnels rather than granting broad network access — keeping a single compromised credential from becoming an organization-wide incident.

Dependency management needs active hygiene, not passive monitoring.

Firezone implements cooldown periods before adopting new dependencies, SHA-pins all GitHub Actions and Cargo packages, IP allow-lists SaaS platforms like GitHub, Slack, and HubSpot, and reviews existing dependencies for removal or vendoring. The episode suggests that as AI makes it cheaper to write small libraries, the calculus shifts: pulling in a shared dependency creates a shared attack surface, while generating your own version increases the entropy an attacker must overcome.

Related: Technology Strategy & Assessment | Infrastructure Modernization | Data Engineering | Episode 2: Zero Trust Security with Firezone

Full Transcript

Jason: Welcome to Eventual Consistency, the show that cuts through the AI hype to talk about what’s actually happening in data and technology. In this episode, which is a special one, we’ve got the CEO of Firezone, Jamil Bou Khair, being joined by two guests from Firezone, a Zero Trust network access company. We’ve got Jamil Bou Khair, the founder and CEO, and Brian Manifold, who is a senior full-stack engineer. Between them, they spend their days understanding how trusted infrastructure becomes an attack vector, which makes them exactly the right kind of people for today’s conversation. This episode is all about software supply chain security. The uncomfortable reality is that security posture isn’t just about what’s trying to get in from the outside, it’s about what’s already inside, embedded into your open source dependencies, the tooling, and the hardware that run your systems every day. James, Jamil, and Brian get into how the pressure to move fast creates the conditions for operational security to slip, how AI is fundamentally changing the calculus of both attack and defense, and what a genuinely defendable architecture looks like in that environment, from dependency management and credential hygiene through to Zero Trust segmentation and blast radius reduction. The question at the center of it all: in a world where you are going to get breached, what determines how bad it gets? Here we go.

James Winegar: Security is inherently a compromise to the point I just said. I can make a system as burdensome as possible for engineers to do their work — it will be extremely secure. So you’re making the tradeoff based off of what you really need to do. As teams get bigger it gets harder and harder to manage these things. Probably one of the problems they had is static credentials existed somewhere. I’m not a hundred percent sure, but I’m guessing there was a long-lived security token somewhere instead of OIDC for everything, ensuring that only the repo itself could publish. They had access to GitHub — probably an admin account — so they could do whatever they wanted. Those types of things could help. Things that slow you down.

Brian Manifold: Yeah, things that slow you down. Jamil and I were talking about this yesterday too. There’s always going to be some level of access that someone can gain that is just game over. Because if they did have enough privilege in GitHub, even if they were using more dynamic credentials —

James Winegar: Yeah, they can just change the settings.

Brian Manifold: Yeah, it’s just like I’m going to rotate this, or I’m going to add a user, or I’m going to lower this privilege level. At some level everybody’s vulnerable, and you’re trying to find where those levels are that you need to protect. At this level we have to do everything we can to protect it. Below here, maybe we don’t have to be quite as intense, because it slows down the actual operations of whatever system you’re in.

James Winegar: One of the things I was thinking, because I mentioned air-gapped stuff earlier — even air-gapped environments have some risk. You could transfer data over sound if you’re really trying to. It’s a lot of work.

Brian Manifold: Or a USB key.

James Winegar: USB keys — they don’t allow mounts, or I guess we’re talking Stuxnet. Even in an air-gapped environment where you don’t allow mounting USBs, they probably still need install media, so there’s a CD somewhere. If I just get that physical asset in there with malware on it — somehow I’ve got to get stuff in there, otherwise we’ve got sticks and rocks. Pick your spectrum.

Brian Manifold: Yeah.

James Winegar: This ties in with a little geopolitics — supply chain attacks at the hardware level. The foreign router ban in the US, TP-Link and Netgear and all these other router manufacturers. All this stuff gets made in China, so there’s this argument about supply chain attacks and hardware. Go ahead, Jamil.

Jamil Bou Khair: Yeah, the FCC banned new foreign-made routers. There are a couple of interesting things about this. If you’re making a router in the US you probably have foreign nationals working for you anyway. Setting the borders to be within the US doesn’t suddenly make it all safe — firmware can get in just as easily. Prices are obviously going to go up for consumer routers, but I commend the spirit of it, because insecure routers are a prime target for exploits. They become part of botnets, and there are millions — billions perhaps — of them on the open internet.

Brian Manifold: We were talking about this yesterday too, Jamil — even if you were building one on US soil, where are you getting your chips from? Almost certainly not the US.

James Winegar: Yeah well I don’t think there’s a fab in the US.

Brian Manifold: Exactly. There might be a couple of fabs, but they’re not supplying to you. They’re supplying to the government or huge industry — not the home consumer router business. So what part of the pipeline is required to be in the US? Is it…

Jamil Bou Khair: The chip is at the heart of everything. If they alter the dies they’re making to make these chips — what are you going to do? It goes back to that idea that at some level everything is vulnerable. I don’t even know how you begin to guarantee that your chips aren’t compromised. There are probably some ways, but if you got sophisticated enough you could hide functionality in a chip that wouldn’t be exposed to normal testing.

James Winegar: I’ll bring up something — I’m not an expert in this category, there’s my legal attestation — but there was the thing with Super Micro and the China manufacturer.

Jamil Bou Khair: I remember that, yeah. The big scare.

James Winegar: Yeah, the chip in the manufacturer.

Brian Manifold: Wasn’t that a Bloomberg article? There was a lot of question around whether it was legitimate or not and I don’t know if they ever reached a conclusion. I remember that happening — I was at Cisco at the time — and we were trying to work on a system where we could have photographs of every single board that came off the line, so once it got to a customer you could go back and say, ‘Wait a minute, something’s different about this board than at the point of manufacture.’ Now if they’re putting stuff in at the time of manufacture a photograph wouldn’t help, because obviously it would just look like whatever came off the line, but.

Jamil Bou Khair: Go back to the design spec.

Brian Manifold: Yeah.

Jamil Bou Khair: When I was at Cisco there was a lot of security around sealing boxes that get delivered to customers and putting all kinds of tamper-proof seals. It’s not going to stop the CIA or the NSA — they’re going to intercept it, tamper with it, and the customer will never know. I’m sure there’s stuff going on, I was just never privy to any of that.

James Winegar: This is where we sound like conspiracy theorists.

Jamil Bou Khair: It’s happened. It happens all over the world — somebody somewhere is interested in getting in somewhere else.

James Winegar: As a dragnet, the consumer router thing is on a whole other scale. Consumer routers are almost insecure by design — they never get patched. The CVE happens two months after it gets released and your average consumer is not patching the firmware on their router.

Jamil Bou Khair: In a lot of cases you can’t — my ISP requires you to use their device. Whether that hurts or helps consumers, you could make an argument either way.

James Winegar: If the ISP owns it then they’re also responsible for patching and maintenance, and if it’s open then the liability is on them for issues. The big telcos are basically government entities, so what’s the actual implication for them? Who knows. Another thing with these consumer routers — I think all the big players are going to get an exception besides maybe one or two, and then it’s a forced monopoly situation. We’ll see what actually ends up happening.

Jamil Bou Khair: Interesting take. Very cynical — just use it as a political tool.

James Winegar: Supply chain stuff is also important — software supply chain, hardware supply chain, both big considerations. The AI tooling just gets better, faster, stronger in exchange for more resources, more power, more energy, more memory. The way this goes, we can always add more and it’ll be faster and we can do more. As long as the capability exists to use more, they’re going to be using more to train bigger, better, faster models.

Brian Manifold: Agreed.

James Winegar: I’d be blown away to hear that you’re not daily driving eight hours of your days using Anthropic or OpenAI or one of these providers to help you.

Jamil Bou Khair: The way I use AI overall — is it saving time? It’s not saving as much time as it could, for the following reason. Anything that AI generates you have to go and manually verify. To the extent that what you’re working on is critical and needs to be accurate, the verification time goes up. If you’re writing a very critical piece of code you’ve got to still step through it line by line. Now you’re doing code reading instead of code writing, which is a different part of your brain and almost more draining — you’re not thinking through it at the same level of detail. It’s just one constant code review after another.

Brian Manifold: Very taxing mentally.

Jamil Bou Khair: And I do wonder if we’re getting hit from both sides of the security spectrum — we’re generating more code that we’re not reviewing, and now the attackers have automated tools that can look at other people’s code and come up with a proof of concept. It might not work perfectly, but if it spits out 90% of the proof of concept and all they have to do is fill in 10% of how this thing actually could be exploited, that’s a big win for the bad guys.

James Winegar: Yeah, that’s also how I write code right now.

Brian Manifold: We’ve been working with some customers on product development and there have been bugs within their environment. The people who were not doing appropriate levels of validation — you can find the source of the bug and go back and say here’s what you did. But there’s another thing here about best practices in general and how you enforce those practices across the board. A lot of pre-AI best practices were things like type systems — type systems get rid of a whole set of bugs that can happen. Static analysis tools, linting. Writing tests.

Jamil Bou Khair: Writing test cases, yeah. QAing your software.

James Winegar: Which is just another higher level of testing. At what level should the test cases be? Is it a unit test? An integration test? UI tests — does my frontend hold state correctly when I do this type of change? There’s a whole class of exploits just because people can do something on the client side and exfiltrate on accident, because software just gets more and more complicated. One of the things about software that’s interesting to me is that for the most part we’re not bounded by physical reality. When you need to build a house you need a foundation. A lot of software engineers would argue yes, to build software you need a strong foundation — but do you have to have one? Is it fundamentally required for it to exist, or does it look like a bunch of Lego blocks thrown together with a cylinder holding up the Pantheon? With the rise of LLMs, software has become very cheap to write. That’s really the only thing that’s changing — cheap to write, cheaper to potentially validate. Now that it’s so cheap to write there’s going to be a lot more of it, and hopefully software engineering will inch towards other engineering disciplines where there’s a higher level of rigor. If you’re a civil engineer you’ve got to be a certified professional engineer, at least in the US in your state. Your bridges could kill people. The software industry has lagged behind that — even in many cases where software is still critical there’s not an accreditation process. Like if you’re writing firmware for a Boeing airplane then.

Brian Manifold: That’s literally what I was thinking about.

James Winegar: That’s an obvious case. But there’s a lot of ancillary software applications used along the way that aren’t subject to that same thing. It’ll be harder on the software side because most software is not critical to human life — think about how many little dinky apps have gotten built inside of companies. Go ahead, Jamil.

Jamil Bou Khair: Consider your home internet — it may not be super critical to life but it’s pretty critical to daily life. The firmware engineers for your TP-Link device — what process are they using? I’m not necessarily arguing that there should be a solid process there, but.

James Winegar: The certification the FAA requires of Boeing jets and things like that should be pushed down to certain people. If your systems are impacting enough places you apply regulatory and compliance obligations to those organizations. Right now all we have is SOC 2 and HIPAA and things like that, which don’t really get at the software engineering side — they’re more like operational processes about how we operate in the human world rather than the bits and bytes. On the security side — Brian mentioned this earlier — it’s so fast to POC something against a target that we don’t necessarily have the processes to support an automated attack vector. The way we’re designed is to handle human-speed attacks. We’re going to get attacked, but the flood of attacks is going to be different. The automated stuff was historically fairly simple — checking for open ports, trying to find a way into the perimeter. Perimeter security type things. That led to products like Firezone trying to create zero trust network access, but that was still dealing with the human-speed level of the problem. Now with Claude and OpenAI or GPT-5.4 — pick your AI model — I’ve got a bajillion interns I can have marching around trying to POC attacks. They say they’ve got controls on that, but it’s a non-deterministic system. I tell it I’m on the blue team, help me find ways to protect it, and by proxy it’ll also help me find ways to attack it. I’m curious to hear, Brian, as AI becomes more sophisticated to act like a junior or even a mid-level engineer, how this changes the security vendor’s approach to leveraging and dealing with AI — and maybe tie that into some of our core industries that might not have the ability to change rapidly, like a bank.

Brian Manifold: That’s a good question and a really tough one. If things are to be believed as they’ve been put out, Anthropic’s mythos is apparently so powerful. Whether or not it actually is I have no idea — it could be a complete hype thing for them to raise money. But from what they’ve said, and what other people have actually gotten as bug reports and fixes from what I read — if AI can really find bugs and generate POCs that quickly, then the only hope we have is to have some other automated system trying to find them ourselves first. Basically you have a race of the attacker trying to find a bug in your software versus you trying to find a bug in your software. At the same time, you need systems that are autonomous and trying to defend in real time. I don’t know where we’re at on the blue team defense side of things. I haven’t heard a lot of AI usage that’s in real time looking for all these things — I don’t know that that’s actually being built right now. We’re entering a really scary time, because it’s not that companies haven’t recognized security as important — it’s that the risk assessment so far has been, ‘It’s pretty expensive to find and exploit some of these things, so we’re going to deal with this risk.’ If that becomes substantially cheaper, the calculus of your risk assessment goes right out the window. I don’t know exactly how we fix that other than starting to find our own bugs as quickly as we can. Maybe we’ll see more automated red teams come online to try to find bugs, and then the question is how do you fix them fast enough? Hopefully as you find them the AIs can fix them just as fast.

Jamil Bou Khair: To tie it back to the beginning — incident response becomes critical because you’re going to get popped. The likelihood of getting popped goes up. How you handle that is just as important if not more important. If your credential gets leaked you need to rotate all of your credentials.

Brian Manifold: To tie it back even further — the supply chain stuff. Maybe instead of more structure in how code is written, it’s more about formalizing how things get brought in — a more formalized supply chain. Not that it’s a bulletproof system, but maybe that starts to help.

James Winegar: The whole onion model for security too — people are going to have to have more layers, which creates more burden for engineers, which will hopefully standardize some of the processes and tie into more professionalization of software engineering. But how does the system respond to step changes happening every few months? I think we might look back in five or ten years and go, it’s crazy that we just installed 100 dependencies from random people in our software and checked these boxes — no CVEs out for it, we follow these lists. That’s not a perfect system. Maybe with LLMs the industry will move to writing more of that software from scratch, or vendoring some of it, reinventing the wheel a little bit because it’s cheaper to do so. We’re already seeing a bunch of vendoring in the frontend ecosystem — shadcn, vendoring components, instantiating your product and evolving them how you need, so you really only need to do that security review at one point in time rather than constantly for the external dependency. Human laziness is real, but less and less code is being written by humans, so you can prompt at least for smaller dependencies, ‘just build it yourself and write appropriate test cases.’ But I’m still going to need to bring in NumPy as a dependency because it’s got very advanced algorithms for doing math as computationally efficiently as possible — raw Python matrix multiplication is just not going to do it.

Brian Manifold: Jamil and I were talking about that yesterday — being able to produce your own version of a given library helps up the entropy of all software. If everybody is pulling in this one library, an attacker with AI just takes that library, points the AI at it, and if they found a bug there they found it in a bunch of different products. But if you’ve got more code that’s specific to your product, they could still point an AI at your product — but you’ve got to be worth it. It’s not as easy to grab a library, point the AI at it, find the bug there, and then go boom boom boom across all these other products. That might be one way we can mitigate some of what’s coming — having it generate more of the code rather than just pulling in dependencies.

James Winegar: Whenever I talk about the AI stuff and what’s going to happen in years from now it’s like getting the crystal ball out — I’m guessing instead of giving a real opinion. But I feel pretty confident about three months.

Brian Manifold: For sure.

Jamil Bou Khair: If it’s a matter of dollars spent, they’re going to spend the money to run these things to find vulnerabilities before an attacker does. For all we know there are a bunch of 0-days out there being exploited. And mythos — it goes back to the hype. If you put the hype aside and you actually believe what they’re saying, that they found vulnerabilities or 0-days in critical software and then took the responsible approach — working with the vendor directly, almost like a responsible disclosure on a massive scale — that’s a plausible narrative. That could have actually happened. The question I have is how does that play out over time? You can’t just every time you have a step function run a billion or 10 billion dollar compute run, find all of these vendors with critical software, notify them. At some level this needs to be a continuous thing. If it’s really providing that much value, how do you shrink that time frame down? Is this going to be a tool that an engineer can run and go, great, the software I wrote is secure? If not, is it ever going to be more secure? Maybe I’m just being too cynical, but I don’t think we’re going to consistently see more secure software as a result of this.

Brian Manifold: Not for a while. Let me know when it becomes a GitHub Action I can just include in my workflow.

James Winegar: You run Glasswing or whatever it is, run Mythos.

Brian Manifold: The problem is it’s going to cost you a thousand dollars to run that PR review.

Jamil Bou Khair: That’ll start there and then I’ll use my startup credits to subsidize it.

Brian Manifold: That brings in a whole other thing — how much this is all being subsidized right now. What’s the true cost of all this at the end of the day? Is this even going to be economically feasible in the long term?

James Winegar: Looking into my crystal ball — it’s only going to be for the big tech companies or the banks. Super critical governments, big tech companies, banks.

Jamil Bou Khair: If you have a service and you don’t need to expose it on the public internet, obviously you should shield it — and that includes your VPN endpoint. What I’ve learned is that you can only defend so much. You are going to get hacked, so it comes down to detection and response, and that’s where I would advise people to focus. Reducing the blast radius — keeping firewalls between components — plays into Zero Trust as well. You want to segment and use principle of least privilege as much as possible. Having a VPC in your cloud where everything can talk to everything is probably not a great idea. Have firewalls down to the individual component level.

Brian Manifold: I would agree, and I would add to that — companies previously could get away with maybe not doing defense in depth because of the risk calculation: it’s expensive to find this vulnerability and this vulnerability and this vulnerability. If the ability to compromise a multitude of things becomes a lot cheaper, defense in depth is much more important for any company. And to tie back to our product — that’s what Zero Trust helps with. You don’t just get in through the front gate and then get access to everything; you now have access to this one specific thing or these two specific things. That’s going to become more and more important as we go forward.

James Winegar: People need to take more time to think about their systems and how they need to interact with each other, versus just hoping it all works out at the end of the day. Perimeter security is basically what that is.

Brian Manifold: I get the allure of just letting it connect up and going hey, we got something working, it’s great. But it goes back to security versus usability — whichever way you lean you’re going to affect the other. If you go too far on the usability side your security’s probably too lax. If you go too far on the security side your usability is going to suffer. Companies are going to have to take a harder look at that and say where do we set that dial now, because it used to be we didn’t have to worry about it too much — now we really need to.

James Winegar: You’ve done a lot of pinning of versions for your cargo dependencies for Rust, your GitHub Actions etc. because it’s built into the way you’re able to do things. But you’ve also vendored some dependencies to reduce blast radius and give you the ability to resolve various issues. Do you feel there will be a lot more vendoring that y’all will have to do as time goes on, related to the same ideas we talked about today?

Jamil Bou Khair: For every new dependency we bring in we give it a higher level of scrutiny — go read the code, understand who’s maintaining it, make sure the SHA pinning is happening. We also recently implemented a cool down period, so we’ll let something sit for a while. Every organization is going to be different, but depending on how you’ve configured Dependabot, you may not want to pull in a dependency right when it’s cut and released — not just for security reasons but also for stability and reliability. Those are some basic things. I would also add that a lot of people don’t know this, but a lot of the SaaS apps you use have an IP allow list feature — not just GitHub but Slack and even HubSpot. You can configure that to allow connections only from a certain range of IPs. A lot of our customers are doing this: they’ll set up their Firezone gateway, route those apps through Firezone, assign that gateway a static IP, and now you can only use those apps if you’ve got Firezone installed and you’re signed in. An external attacker wouldn’t even be able to get to your application — your tenant.

James Winegar: That’s literally how we use Firezone — to force exactly that.

Brian Manifold: We’ve also gone back and taken a look at some of our existing dependencies and asked can we get rid of some of these and can we rewrite them. That one’s harder because, as you said, Jamil, that means changing functionality that already exists, so we’ve got to be careful about regressing in some way. But it is conversations we’re having that we wouldn’t have had before — it just would have been, yeah, dependency, use it.

James Winegar: How many leftpads you got versus core infrastructure dependencies?

Jamil Bou Khair: That’s one of the core things. If I’m bringing in a dependency to use one or two functions, I look at it and go, I could just write this — Claude could write this in 30 seconds.

Jason: That’s it for this episode of Eventual Consistency. If you want to talk about your data or security challenges or you think we got something wrong and want to tell us how, you can find us at corrdyn.com. We’re back in two weeks and we’ll try as always to be a touch more consistent. Thank you for listening.