PODCASTS

BTS #81 - Infratrust Pulse, AI's Role in Security

In this episode of Below the Surface, host Paul Asadoorian is joined by Eclypsium’s Vlad Babkin for a wide-ranging discussion on the latest infrastructure security risks, beginning with the August InfraTrust Pulse and expanding into management plane exploitation, BMC persistence, Fortinet symlink abuse, Ubiquiti patching, AI-assisted vulnerability discovery, and insecure surveillance devices.

The central theme is visibility: defenders are being asked to secure appliances, firmware-based systems, BMCs, cameras, firewalls, and orchestrators that often run Linux under the hood but expose only a narrow, vendor-controlled window into what is happening. Paul and Vlad return repeatedly to the same practical problem: patching matters, but patching alone does not prove a device was not already compromised.

The episode also explores how AI is changing both sides of the equation. Attackers can increasingly automate vulnerability discovery, exploitation, and post-compromise work. Defenders and developers can use the same tools to build, review, and test software more effectively, but only when paired with clear standards, human review, strong test harnesses, and architecture choices that reduce entire classes of mistakes.

Key Topics Covered

  • InfraTrust Pulse and infrastructure advisory volume: Paul introduces the latest InfraTrust Pulse, noting a 30-day snapshot covering 118 new advisories across 12 vendors and 1,051 CVEs. The discussion frames infrastructure risk as a growing data problem: defenders need a way to track advisories across hardware, software, firmware, and management systems without manually piecing together vendor notices.
  • Management planes as attacker targets: The episode highlights a recurring pattern in which attackers go after centralized management layers such as Cisco Firewall Management Center, Arista VeloCloud Orchestrator, Aruba SD-WAN Orchestrator, Check Point SmartConsole, and Fortinet management tooling. These systems exist to manage large fleets of network devices, which makes them especially valuable when compromised.
  • Network edge devices and their management platforms: Paul emphasizes that network edge devices remain a major target, but defenders also need to account for the orchestrators and appliances used to manage them. The risk is not limited to firewalls, routers, VPNs, and switches; it includes the software and virtual appliances that coordinate those devices.
  • BMCs as hidden persistence points: Vlad explains why BMCs are attractive to advanced attackers: many are exposed internally, are difficult to observe, and can persist below the host operating system. Paul connects this to the risk of attackers moving from a compromised host into the BMC, where they may be able to remain unnoticed for long periods.
  • Closed appliances and forensic difficulty: The hosts discuss the challenge of investigating compromised appliances when vendors expose only limited commands or restricted diagnostic interfaces. Vlad argues that defenders need real shell access and complete visibility, because attackers who gain remote code execution are not limited by the same interface constraints.
  • Fortinet symlink persistence and patch limitations: Paul discusses a Fortinet persistence issue in which attackers used symlinks to survive firmware updates, including a variation that evaded an earlier fix. The broader lesson is that firmware updates do not automatically remove implants or prove a device is clean; teams need incident response and forensic validation after patching.
  • Why “was this already owned?” is hard to answer: Vlad pushes on the practical difficulty of answering that question on closed platforms. If defenders cannot enumerate files, inspect the full system, or run standard forensic tools, then determining whether an appliance was compromised before a patch becomes slow, incomplete, and sometimes impossible.
  • Root access, observability, and vendor cooperation: Vlad argues that vendors should provide unrestricted root shell access for enterprise appliances, pointing to examples such as F5, some Cisco devices, and Arista EOS. His point is not that openness eliminates vulnerabilities, but that it allows customers and researchers to inspect, validate, and secure the systems they depend on.
  • Ubiquiti patching as a remediation experience: Paul uses his own UniFi update experience as an example of a vendor making patching relatively painless. He notes that Ubiquiti’s advisories did not expose much detail, but the update process itself was straightforward, which matters because remediation has to be practical for customers.
  • API and CLI design for safer appliances: Vlad recommends safer development approaches for management APIs and CLIs, including stronger validation, clearer API architecture, and memory-safe languages for outward-facing components. The discussion connects secure design choices to the long-term maintainability of embedded and appliance software.
  • AI-assisted exploitation and old Linux vulnerabilities: Paul and Vlad discuss a Cisco Talos report about threat actors using AI to coordinate tools and exploit old Linux privilege escalation bugs. The point is blunt: if systems remain unpatched, AI makes exploitation cheaper and faster, even when the vulnerabilities are years old.
  • AI, VM escapes, and zero-day discovery: Vlad describes research in which AI systems moved from exploiting known vulnerabilities to finding zero-days when the attack surface was reduced. The hosts treat this as a warning for infrastructure operators: once an attacker gets code execution, privilege escalation and sandbox escape may become much faster than defenders expect.
  • LLMs, reverse engineering, and obfuscation: Paul summarizes Quarkslab’s work testing LLM-assisted reverse engineering against obfuscated binaries. The models did not always behave as intended, sometimes finding answers through documentation rather than true binary analysis, but the experiment still shows where AI-assisted security research is moving.
  • Using AI to build better software: The conversation shifts from attacker use of AI to developer use of AI. Paul and Vlad discuss test harnesses, code review by multiple models, standards such as agents.md, CI pipelines, linters, unit tests, coverage reports, and manual QA as ways to reduce the risk of AI-generated bugs.
  • Backdoored cameras and exposed public-sector systems: The episode closes with speed cameras, surveillance devices, PLCs, and other systems exposed to the internet. Paul and Vlad argue that basic network controls, VPNs, WireGuard, OpenVPN, Cloudflare, Tailscale, and segmentation could dramatically reduce exposure for cities, utilities, factories, and other operators.

Timestamps

00:00 – Setup, livestream checks, and episode introduction
01:13 – Paul introduces Below the Surface episode 81 with Vlad Babkin
01:29 – Eclypsium resources and the new eclypsium.com/go listener page
02:20 – InfraTrust, InfraTrust Pulse, advisory tracking, and API questions
04:29 – August InfraTrust Pulse: 118 advisories, 12 vendors, and 1,051 CVEs
05:30 – AI-assisted vulnerability discovery and why advisory volume may stay high
06:30 – Management plane targeting: Cisco FMC, Arista VeloCloud Orchestrator, Fortinet, Aruba, and Check Point
08:16 – KEV-listed management tools and the difference between observed exploitation and emerging attack surfaces
09:08 – Rowhammer, speculative execution, GPU vulnerabilities, TPM research, and visibility gaps
09:36 – BMC exposure, private-network risk, and attacker persistence in data centers
10:32 – Moving from a compromised host OS into the BMC
11:09 – Hikvision cameras, embedded devices, and the lack of OS-level visibility
12:00 – Dormant implants, local triggers, and attacks that avoid network detection
13:03 – BMC implants and coordinated shutdown scenarios
13:52 – Fortinet symlink persistence and patch bypasses
14:50 – Why patching must be paired with incident response and forensic validation
15:14 – The difficulty of forensic investigation on closed platforms
16:21 – Linux-based appliances with restricted visibility
17:53 – AI models lowering the cost of exploit development
18:05 – Fettle, AppArmor, SELinux, and the need to verify security controls
19:49 – Vlad’s argument for root access and unrestricted inspection
20:19 – eBPF telemetry limits when attackers control the kernel
20:37 – Vendor examples that provide root shell access
21:44 – Ubiquiti vulnerabilities and Paul’s UniFi update experience
24:02 – HPE Comware, bash access, API design, FastAPI, gRPC, and safer development choices
25:39 – CLI design, Go, Rust, memory safety, and outward-facing appliance components
26:41 – Cisco Talos, AI-assisted attacker tooling, and old Linux privilege escalation bugs
27:35 – AI escaping VMs and exploiting known vulnerabilities
28:29 – Baron Samedit, Dirty Pipe, and long-lived patching failures
29:31 – Why sophisticated attackers will invest in appliance reverse engineering
30:19 – Poor OPSEC, exposed C2 directories, and leaked attacker tooling
31:19 – Agentic AI in post-compromise operations
32:15 – Open-weight models, Qwen, hardware constraints, and attacker compute access
33:18 – Threat actors using rented or compromised compute to run models
34:00 – AI harnesses, VM escapes, and zero-day discovery
34:43 – Why code execution can quickly become privilege escalation and sandbox escape
36:04 – Quarkslab’s LLM-assisted reverse engineering and obfuscation experiment
36:50 – LLM “cheating,” reasoning traces, and OPSEC failures
37:39 – What AI does and does not yet change about binary obfuscation
38:11 – The harder question: using AI to develop better software
39:06 – InfraTrust and Fettle as AI-assisted software projects
39:31 – Skills, context, and directing AI toward more secure development
40:07 – Test harnesses, cross-model review, and iterative bug fixing
41:13 – agents.md, CI pipelines, GitHub Actions, GitLab, Jenkins, and test visibility
42:18 – Automated and manual QA across multiple Linux distributions
42:58 – Linters, unit tests, coverage reports, and reducing AI-generated bugs
43:45 – Choosing safer technologies and using AI to evaluate architectural tradeoffs
44:42 – Slovakia’s warning about Nero R1 speed cameras
45:12 – Firmware backdoors, Endless Doors, routers, and supply chain uncertainty
46:00 – Surveillance systems, public-sector risk, Flock, and data misuse
47:20 – Why cameras and other devices should not be exposed to the internet
47:52 – PLCs, cameras, BMCs, and practical VPN-based exposure reduction
49:34 – OpenVPN, WireGuard, redundancy, and low-cost segmentation for small operators
51:31 – Closing reminders: previous episodes, InfraTrust, and infrastructure advisory tracking
52:14 – InfraTrust developed with AI and the possibility of a future API

Core References

  • Eclypsium – Mentioned throughout the episode as the company behind Below the Surface, InfraTrust, and infrastructure assurance work.
  • Eclypsium listener resources – Paul points listeners here for resources including AI data center security, network edge device risk, and Eclypsium demos.
  • InfraTrust – Free infrastructure advisory search and risk knowledgebase discussed at the top and end of the episode.
  • Announcing InfraTrust – Eclypsium background on InfraTrust and InfraTrust Pulse.
  • Below the Surface podcast archive – Paul references the archive for previous episodes and transcripts.

Eclypsium Resources

Vendors, Devices & Platforms Mentioned

  • Cisco Firewall Management Center
  • Arista VeloCloud Orchestrator
  • Fortinet / FortiGate / FortiOS / FortiManager
  • Aruba SD-WAN Orchestrator
  • Check Point SmartConsole
  • Ubiquiti / UniFi
  • HPE Comware
  • F5
  • Arista EOS
  • Hikvision cameras
  • Nero R1 speed cameras
  • BMCs
  • PLCs
  • TPMs
  • GPUs
  • Network edge devices
  • Surveillance cameras
  • AI data center infrastructure

Vulnerabilities, Attacks & Security Concepts

  • CISA Known Exploited Vulnerabilities catalog
  • Remote code execution
  • Return-oriented programming
  • Local privilege escalation
  • Symlink persistence
  • Firmware implants
  • Backdoors
  • Rowhammer
  • Speculative execution vulnerabilities
  • GPU vulnerabilities
  • TPM research
  • Dirty Pipe
  • Baron Samedit
  • Reliable Datagram Sockets Linux kernel vulnerability
  • VM escape
  • Sandbox escape
  • Obfuscation
  • Reverse engineering
  • Supply chain compromise
  • Internet-exposed management interfaces
  • Network segmentation
  • Incident response after patching
  • Forensic validation on closed appliances

Transcript

Paul Asadoorian (00:52.652): Right. This week we’ll cover the August InfraTrust Pulse, old Linux vulnerabilities that are new again, patching your UniFi devices, hacking speed cameras, and AI’s search for obfuscation. Stay tuned — Below the Surface, coming up next.

Paul Asadoorian (01:13.794): Welcome to this edition of Below the Surface. This is episode number eighty-one, being recorded on August twenty-seventh, twenty twenty-six. I’m Paul Asadoorian, joined by my coworker, Mr. Vlad Babkin. Vlad, welcome.

Vlad Babkin (01:27.131): Hello, and welcome.

Paul Asadoorian (01:29.004): Good to have you here. Quick announcement before we get started — a new, shiny little read here at the top of the show. Below the Surface listeners can learn more about Eclypsium, and how we help organizations assure and secure the infrastructure their operations depend on, by visiting eclypsium.com/go. You’ll find our guide to AI data center security, our white paper on eradicating hidden threats in network edge devices, and a case study showing how a major cloud provider used Eclypsium to protect its infrastructure hardware during a merger and IT consolidation. You can also request a demo and see how Eclypsium verifies device integrity, hardens against risk, and detects active exploits across enterprise infrastructure — from the AI data center to the network edge to user endpoints. All that and more at eclypsium.com/go.

Outstanding. Speaking of all things Eclypsium, we have the latest InfraTrust Pulse, as we call it. The InfraTrust website was a collaborative effort — Vlad is of course the developer behind the InfraTrust website, which lets you search through an expanding date range and expanded coverage of hardware, software, firmware, and infrastructure-related advisories. Make sure you check out that website — it’s completely free, no registration required. Vlad, if someone wanted to query that data via an API, I don’t think we limit or necessarily discourage that — it’s kind of there if you want to find it. I’ve had two listeners ask whether they can use the API that’s there, or whether there’s another API where they can consume the data.

Vlad Babkin (03:25.009): In reality, yes, it does have an API, but we’re not publishing it currently, so there’s no guarantee of stability. Obviously, if you go ahead and reverse-engineer what our website does, I cannot stop you. There isn’t enough data for me to build any reasonable anti-bot protection without requiring everybody to solve a CAPTCHA before they enter the site, which isn’t super useful. But besides that —

Paul Asadoorian (03:50.293): Mm. Mm-hmm.

Paul Asadoorian (03:54.509): My advice to the audience in these situations, Vlad, is always: just be nice. Give us a heads up — that’s always the right thing to do. And if you have any questions, reach out to us. I don’t want to discourage people from using the data, because it means people find it useful, and we do too. I think it’s good.

Vlad Babkin (04:02.907): Mm-hmm. Yeah.

Vlad Babkin (04:16.507): Yep. And in this case, Paul, we probably have to raise internally the question of making an API available at some point, so it’s not some kind of hacky thing. But yeah.

Paul Asadoorian (04:24.002): Yes. Yes.

Paul Asadoorian (04:29.034): Right, right, right. Yeah, so stay tuned — maybe there will be more on that front. This month’s Pulse — we did a thirty-day snapshot, which makes it difficult, because when I write about it I can’t say “this month” or “in August,” since our date range ran from about July eighteenth through August twenty-fourth. And it’s interesting — there were a hundred and eighteen new advisories across twelve different vendors, covering one thousand and fifty-one CVEs for that four-week period, which I think is interesting. I want to do a bit more of a data study — just as an FYI, are we seeing more advisories per month, fewer advisories per month, or is it completely random? I think it would be interesting if we can show some trends. I’m thinking more toward the end of the year is when we might want to do some trending and analysis — I don’t think even looking at six months gives us enough data to pull those kinds of trends.

And I think the trend is obvious, right? Like we were talking about before we started recording, Vlad — organizations, enterprises, vendors, threat actors, and security researchers are all using AI to help find new vulnerabilities, and that’s resulting in more patches. That could be Mythos, that could be vendors’ own models — Cisco has Antares, Microsoft has their own model. I think we’re at the point where it’s not anything truly exciting or new anymore — we just know this trend will continue, and AI will keep getting used to find vulnerabilities. I think that’s going to keep these counts in the InfraTrust Pulse pretty high.

This month’s highlight was going after the management plane. We’ve seen a trend — numerous vulnerabilities, exploits, and threat actors actually using this tradecraft to compromise the management layer. Cisco’s Firewall Management Center, or FMC —

Paul Asadoorian (06:53.536): — this month we had Arista’s VeloCloud Orchestrator. We’ve certainly seen in the past FortiManager — whatever Fortinet’s equivalent of FMC is. We’ve talked about this on the show before, right — if you’ve got hundreds or thousands of these devices deployed in your enterprise, you need some way to manage all of them, and vendors make this management software, typically bundled as an appliance. You can buy a physical appliance, put it on a virtual one — some may even be software you install on an OS you control — but for the big ones, Cisco and Fortinet, it’s delivered as an appliance. And that appliance, of course, has vulnerabilities. You can’t harden the OS underneath them — that’s the vendor’s job. So they end up being exploited by attackers.

Which is interesting, I think — we say network edge appliances are a target today, and a large part of the challenge we’re dealing with in cybersecurity, and while that’s true, don’t forget your management platforms or your orchestrators — the other software and platforms you deploy to manage your network edge devices. Those are certainly in scope for attackers this month.

Vlad Babkin (08:07.801): Mm-hmm.

Paul Asadoorian (08:16.128): We also talked about Aruba’s SD-WAN Orchestrator and Check Point’s SmartConsole, all of which landed on the KEV — actively exploited. I like to ground us in truth oftentimes — stuff that’s being actively exploited deserves our attention. I also appreciate our focus here at Eclypsium on what might be coming next — what’s a ripe attack surface. We’ve got some AI infrastructure vulnerabilities we talked about this month, and that’s certainly a ripe attack surface as well — academic, theoretical; we can prove these vulnerabilities and exposures exist, but we haven’t quite observed them being used in the wild. Now, one can say, well, attackers just don’t need to go there, right?

Paul Asadoorian (09:08.992): Yeah. And I think some of it could also be, Vlad, that we’re just not looking in some of these places — we don’t have the visibility to observe attacks. I was looking at Rowhammer and speculative execution vulnerabilities, and GPU vulnerabilities — there’s lots of research on TPM too. I can’t find any hard evidence of threat actors abusing it, but it’s still something we’d have to pay attention to.

Vlad Babkin (09:36.552): There is a very big question about threat actors abusing some of this. For example, think about the vulnerabilities I found in BMCs — there are a lot of exposed BMCs live on the internet, but if you think about what BMCs are exposed on private networks, it’s literally millions. And let’s say you’re an APT group —

Paul Asadoorian (09:47.585): Mm-hmm.

Paul Asadoorian (09:52.236): Yeah, just over eighty thousand — eighty thousand is the number today, via different protocols, right?

Vlad Babkin (10:05.723): — you really want to persist in the data centers you just broke into. You’re going to go for them, and nobody’s going to see that you’re exploiting them besides that data center. And because of how vendors handle observability of these devices, the data center itself probably doesn’t know much about them being exploited. So it’s like making a hidden spot — a beachhead for the attacker in there. You get my point.

Paul Asadoorian (10:18.777): Mm-hmm.

Paul Asadoorian (10:32.483): Yeah, and it’s interesting to think about — we were doing a little bit of investigation on BMCs this week, and it’s interesting to think about from a threat perspective. If an attacker gains a foothold on your host operating system, there are facilities where they can interface via a BMC. In fact, our own product uses some of those facilities to help enumerate that for our customers. My fear is: what if attackers figure out that a BMC is a great place to hide, and they jump from the host into the BMC?

Vlad Babkin (11:09.191): And they can sit there for a long time. Second point: your network hardware — to give an example, Hikvision cameras. They’re very popular in a lot of parts of the world, and the important point about them is that they don’t expose you any OS-level interface. So —

Paul Asadoorian (11:23.651): Yeah, yeah.

Paul Asadoorian (11:28.623): Mm-hmm.

Vlad Babkin (11:36.538): If an attacker gets code execution on those — a zero-day, for example, or another known vulnerability — and sits on one of those cameras, he can sit there for a long time and you will not know. You will not observe him. You will not have any tools to get visibility into the device. You have some diagnostic dump, but a clever attacker can see what’s in the diagnostic dump and hide from it. Good luck detecting the attacker now. There’s absolutely nothing anyone can do about it, besides forensic analysis and very tight monitoring of network traffic — and even that isn’t enough, because some of these implants can sit for years untouched, not beaconing anywhere, and an attacker can trigger them later, locally. They break in, ping the implant on the local network, and suddenly — surprise.

So there can be trigger conditions that prevent your network monitoring from detecting those. For example, there’s an implant variant for BMC that we built, because one of our customers came to us saying, “We have very tight network monitoring, you can’t do anything about it.” So we said, “Hold our beer,” and made an implant that puts the BMC into permanent shutdown mode. You infect the BMC from the local network — say you compromise an admin laptop —

Paul Asadoorian (12:47.607): Mm-hmm.

Vlad Babkin (13:03.729): — and you have automated malware that moves into local networks. Not hard to imagine, right? Suddenly all of your BMCs are infected, and on the implant level you coordinate a specific date on which the entire data center just goes down — no network traffic involved. So some of these attacks, depending on what the attacker wants, can be very deadly without ever touching the attacker’s own infrastructure. Time and time again, I’m going to keep repeating —

Paul Asadoorian (13:17.380): Yes.

Vlad Babkin (13:32.345): — unless vendors start cooperating, especially vendors for critical hardware like BMCs and network appliances, this issue is not going to go away. It’s only going to get worse and worse. And one of our next topics, by the way, links to this exact point.

Paul Asadoorian (13:52.452): Yeah, a hundred percent. We also saw a Fortinet fix for attacker persistence — the classic symlink vulnerability. What’s interesting here is that it’s something the vendor fixed but didn’t catch all of the variations. Putting a double slash into your symlink evades the vendor’s patch and still lets attackers create a symlink to persist malicious software across firmware updates on Fortinet devices. This one is on the KEV, and it’s a classic persistence mechanism on Fortinet — we now have some detections for that as well. It’s something I highlight in a lot of the Pulses: you can do your due diligence and patch everything, but if an attacker already has something implanted on the device with that persistence mechanism —

Vlad Babkin (14:37.147): Yeah.

Paul Asadoorian (14:50.039): — a vulnerability that now has to be fixed twice — your job isn’t done. That’s stated right in the Pulse: you need to patch your stuff, but you also need to do incident response and forensic investigation to make sure your device is still clean, that it wasn’t previously compromised. It’s harder now because you’re on the latest version, sure, but you’ve got to do a retrospective and ask, “Was this already owned?”

Vlad Babkin (15:07.217): Yup.

Vlad Babkin (15:14.727): But the whole point is that question — was this already owned — is really hard. Making a forensic investigation on one of these closed platforms is insanely hard. Fortinet gives you some custom interface for listing files, and that’s about it — there’s fnsysctl, or something like that, which gives you some commands, but because of how that interface is structured, you can’t just ask it for a tree of all files —

Paul Asadoorian (15:20.705): Mm. Yeah.

Paul Asadoorian (15:31.309): What is it — fnsysctl?

Vlad Babkin (15:44.259): — or “give me all of the siblings,” or use some advanced find commands. No, no, no — you have to do it through ls, folder by folder, manually.

Paul Asadoorian (15:48.003): Yeah.

Paul Asadoorian (15:51.867): Folder by folder. Yep. And that’s what we’re doing — and that’s why we’ve kind of struggled with some of these detections, because it’s not really Linux, so we can’t use tried-and-true Linux, or even Unix, tradecraft. Forensics on these systems isn’t anything really new — we’ve been using Linux for twenty-plus years. What I’d look for twenty-plus years ago is a lot of what I look for today; a lot of that stuff is still the same.

Vlad Babkin (16:21.295): Yep, and the stupid part is, it is Linux, but you get only a stupidly small window into it — it almost feels like it’s designed to prevent you from having visibility into attacks against the device.

Paul Asadoorian (16:35.128): Right. ‘Cause attackers are exploiting it and getting RCE. In fact, we saw someone build a ROP chain with a remote exploit for an older Fortinet vulnerability and publish it to GitHub this week as well — that didn’t necessarily make it into the report, but it’s something we observed, and it was interesting.

Vlad Babkin (16:48.215): Mm-hmm. Yeah.

Vlad Babkin (16:56.347): It’ll only get worse from here — it’s not going to get any better anytime soon. It’ll probably get worse for years to come. Message for you all: it’s not just — as I love to say — FortiGate being today’s unlucky guy of the day. It’s all of you. Stop doing this stuff with locked-down platforms. Start cooperating. Eventually there will be an initial influx of vulnerabilities, but at the very least, that influx will eventually stop, because most of the stupid stuff — and less stupid stuff — will get fixed. But with how stingy you are — and I’m not just talking about FortiOS — it’s only going to get worse, because dedicated attackers will disassemble your system, get access to a full shell whether you like it or not, investigate the system in depth, and find surprising places. And your customers are the ones who are going to get hit.

Paul Asadoorian (17:34.084): Yeah, it’s pretty much all of them. Yeah.

Paul Asadoorian (17:52.037): Yeah.

Vlad Babkin (17:53.286): And it’s getting very dicey. AI models are getting really good at exploiting this stuff. It doesn’t cost tens of thousands of dollars anymore — it costs two hundred bucks and one day of running the model.

Paul Asadoorian (18:05.210): Yep. And it’s interesting too that not only do we not get a lot of visibility, we don’t get a way to verify and validate the way that we should. In my — air quotes — spare time, I work on an open source tool called Fettle that helps you apply patches to your systems and, overall, see if your system is in good working order. I’ve just been slowly adding features to it, to give me visibility into my own Linux systems. If other people want to use it, great — classic open source. I wrote this tool for me, to monitor my systems; if it helps you, great. It’s fully open source, MIT licensed, out there.

One of the things I’m looking into this week is AppArmor and SELinux. Even if those are configured and installed on the platforms that run Linux under the covers and represent our network edge, you need some kind of visibility into them. With AppArmor, you need to know there’s a profile for an application, what configuration state it’s in, and whether an application protected by AppArmor has tried to violate one of the rules — access files or other things it typically isn’t supposed to. So even if the vendors are configuring these security controls within Linux, or Linux primitives that let you enact control, we as users need a way to validate, verify, and observe those controls. And that’s often what’s missing from these platforms, Vlad — we get some logs maybe, but —

Vlad Babkin (19:49.576): It’s not even AppArmor. To get any kind of visibility, what you need — I’ll state this plainly — is root access, unrestricted, for every command that exists. Because, okay, you give visibility into AppArmor; suddenly a vulnerability appears that bypasses AppArmor, and your visibility means nothing. You get visibility into a log file —

Paul Asadoorian (20:02.458): Mm-hmm.

Paul Asadoorian (20:12.986): Sure.

Vlad Babkin (20:17.263): — great, the attacker will just clean it up, because the attacker has unrestricted RCE, and probably root.

Paul Asadoorian (20:19.994): Yep. eBPF has the same problem. You can look at eBPF and get telemetry back, but if an attacker already has root access and access to the kernel, they can just tell eBPF to lie to you — “look, there’s no one here, what are you talking about?” So it makes detection super, super hard.

Vlad Babkin (20:24.625): Yup.

Vlad Babkin (20:37.607): Yup. Yup. The only reasonable solution is to give root access to your shell. Again, it’s not destructive to your business — I’ll give you examples. F5 provides bash access with root to their devices. Quite a few of Cisco’s devices provide root with bash access. Arista — as far as I remember, Arista EOS — provides root with bash access.

None of these guys are out of business. We get visibility into them, we get to run our tools. And it’s not just helping us — it’s literally helping the whole community. We also have CrowdStrike folks who partnered with F5, I believe, to run their sensor on the devices as well. Even though it might sound scary — suddenly a lot of stuff gets exposed, especially with an influx of researchers who suddenly get access to this — sure, this initial potential reputation loss is still better than the long-term effects of AI on your systems.

Paul Asadoorian (21:44.978): Right. Ubiquiti is an interesting example there. I think it was yesterday they published about eleven or twelve — maybe twenty-two — pretty critical vulnerabilities. They don’t give you much in the way of insight into those vulnerabilities. To Ubiquiti’s credit — and I believe they’re trying to break into the enterprise, which is one reason I mention it here; I think there’s a huge push to get Ubiquiti into the enterprise — their platform is open. They have a shell. It’s Debian Linux — you can get a shell on it. They also have a really great updater. Yesterday I read these advisories, and they seemed pretty bad — one of them looked like, if you were inspecting traffic, an attacker could inject something into that inspection and get a root shell on your device. That’s bad. We didn’t get a lot of details, so it’s kind of hard to build something that detects this, or determines if your machine is compromised. But they just said, “Look, you need to patch.” So I went to my Ubiquiti device and upgraded it. There were no hiccups, no downtime. I clicked around in the interface longer than I probably should have, because it’s not the most user-friendly interface — no shade to Ubiquiti, though; building a truly usable interface is super hard.

Vlad Babkin (23:10.609): Classics.

Paul Asadoorian (23:11.557): But I figured it out, clicked the button, and I was updated. That’s awesome. And if I hadn’t done that overnight, it would have updated on its own. I don’t want to throw shade on this podcast necessarily, but I’ll give credit where credit is due — that process worked out well for me. I think it could be valuable to an enterprise. No one’s going to make a solution that doesn’t have vulnerabilities, but I think the key differentiator is how you handle them, how you address them, how you roll out fixes, and how easy you make it for customers to remediate those vulnerabilities. With Ubiquiti — at least in my case, one firewall, one user, not an enterprise — it was a good experience.

Vlad Babkin (23:52.987): Yup, and also —

Vlad Babkin (24:02.340): I’ll give two more examples. One is HPE Comware. If you look at v7 and v9, the key differentiator in v9 is that Comware enabled bash access for the device — you actually get a bash shell. So another vendor in the enterprise space managed to open their network switches to bash. This gives us visibility into them — who could have guessed.

Besides the differentiators you listed, Paul, I’ll add another one: how well is your API architected? If you have an HTTP API, make sure you use a safe technology. If you use Python — and I’ve seen devices use Python scripting languages, which isn’t a surprise anymore because devices have a lot of firepower — use FastAPI instead of Flask, because FastAPI gives you very strong validation. You won’t have a surprise method hidden somewhere; everything will be documented, it’ll be easier for you to review, and your developers will develop at higher velocity. It literally has no downsides. There are technologies like this already in use in the enterprise — gRPC, for instance, for internal APIs where services communicate with one another. It’s not new technology. It lets you build an HTTP API without vulnerabilities, or with a lot fewer, anyway, because —

Paul Asadoorian (25:25.487): Yeah, and that API can be powerful too — for inspecting the device, checking configuration, performing operations that let you pull back artifacts usable for detecting configuration issues or threats, whatever.

Vlad Babkin (25:39.099): Yup. Even if you don’t give us visibility through the API, if you build it for the customer, it’ll save you a lot of headache. My recommendation is to shift your development approach: don’t shape your CLI as a black-box C++ binary. At least make the CLI Go-based, or Rust-based — a language where you at least can’t get a memory safety bug.

It won’t prevent all of them, but it’ll reduce some. And I’m not proposing you rewrite your entire platform, but at the very least the attacker-facing, outward-facing stuff — sure, do it. It’s not that complicated, especially with modern AI. Bun rewrote itself from Zig to Rust, I believe — in one go. And that’s a lot more lines of code than your CLI binary most likely has.

Paul Asadoorian (26:41.765): Yeah, we were talking about AI being used by threat actors, and Cisco Talos had a post about a Windows and Linux campaign targeting both platforms. I keyed in on this because I don’t think “threat actors using AI” is the headline here — I think the headline is that they used AI to create an automated, basically a pen-testing framework, using a lot of off-the-shelf tools, even Metasploit, and just used AI to string them together. They were able to exploit sixteen-year-old local privilege escalation vulnerabilities — going back to, I don’t even remember the name, the Reliable Datagram Sockets kernel bug, because it’s from 2010. It’s literally a 2010 CVE —

Vlad Babkin (27:35.975): This is old news. And by the way, this is a small slide into our next topics. If you look at threat actors using AI, and also non-threat-actors using AI — there were people who got access to the latest GPT-5.6 Cyber and ran it: “Hey, here’s a VM, escape it.” First iteration, it found a bunch of known CVEs in a not-quite-latest Debian. Fine.

Paul Asadoorian (27:46.982): Yeah.

Vlad Babkin (28:06.378): Second iteration: okay, all packages are latest, but the channels they were using still had vulnerabilities — AI exploited them within an hour. Next iteration, they cut down the attack surface, disabled the extra packages, installed the latest upstream everything, and it found zero-days. Literally. It took AI about a day to find and exploit them.

Paul Asadoorian (28:29.862): Yeah, you’re just making the attacker’s job easier if you’re not patching your stuff. This system — I don’t know how well you recognize these — but Baron Samedit and Dirty Pipe. Baron Samedit — I don’t remember how to pronounce it exactly, but I do know it was a vulnerability found by Qualys researchers, and I interviewed the researchers years ago. It came out in 2021, and it was a local privilege escalation vulnerability — I want to say it might have been sudo, or one of those; they found a string of them. Dirty Pipe, right, was another one from 2022. These are old — they work — and it’s astonishing that this wasn’t even recent stuff that went unpatched. This is older stuff, more than ten-year-old vulnerabilities that haven’t been patched.

Vlad Babkin (29:31.313): Yup. This only emphasizes how important it is to actually give some openness to researchers. Because a Chinese attacker — or, okay, not to single out one country, pick whichever country you consider your adversary — they will have funds. They’re ready to pour millions into this, buy your device, dissect it, put an AI against it, and run it for weeks. It takes AI a day to find this stuff — that’s frontier AI in US labs, and Chinese labs are behind. Okay, it won’t take them a day, it’ll take them a week. Doesn’t really matter — a week for these guys isn’t a lot. They’re ready to run this attack for months.

Paul Asadoorian (30:19.782): And they can do all that — but the attackers lately seem to lack OPSEC. This is probably the third or fourth case I’ve seen recently where the way we discovered all this information about their toolkits is because they left their own C2 server hanging on the internet with open directory listing turned on. I’m not even kidding — the vector is exactly the same. We’ve seen stuff land in our own honeypot —

Vlad Babkin (30:42.222): Yup. This is —

Paul Asadoorian (30:49.156): — and traced it back to a directory listing on a C2 server with all their tradecraft on it, and it just keeps happening. The OPSEC is totally poor.

Vlad Babkin (30:51.366): Yep. Paul, I’ll stop you there a little — these are script-kiddie attackers. Large APT groups probably have much better OPSEC — they’re not making this mistake. What we know about are the worst groups; actual frontier groups doing this stuff. We got one of the first cases — I believe Cisco Talos claimed they found one of the —

Paul Asadoorian (31:01.734): Mm. They’re not making this mistake. Yeah.

Paul Asadoorian (31:11.780): Right.

Vlad Babkin (31:19.482): — Chinese-speaking adversaries integrating agentic AI into post-compromise operations. That was their headline. The important point is that we know one attacker did this, but I guarantee APT groups have been doing this for much longer than last week — probably since agentic AI became a thing. Developers develop their own tools. For example, at Eclypsium, we’ve been using AI for a year, since it became more or less usable for development. I guarantee APT groups are doing the same exact thing. Give or take — they can only use open-weight models, they can’t really use OpenAI — so it’s a matter of when open-weight models caught up with what the frontier models can do. But if you look at the latest Qwen, per reports I’ve seen, it’s Opus level.

Paul Asadoorian (32:15.815): Yeah. It is. It’s slower — I’m running Qwen3-8B on a slower system, so it’s much slower than it could be, mostly because I don’t have ten or twenty grand to spend on the hardware, which is what it costs now — which shouldn’t cost that much, but it does. And it is a fairly capable model. I did some limited testing this week.

Vlad Babkin (32:15.916): Opus models have been good enough since 4.6 to actually do development.

Vlad Babkin (32:40.870): Advanced groups have budget — buying a $40,000 card, even for Chinese buyers for whom that card is restricted, and considering they only want a few of them — say they have a few racks — buying a few racks through shady channels is probably doable, even with restrictions in place. When you’re not buying a massive amount for a whole data center, you can probably sneak a few in. And considering they have the latest Nvidia hardware, they can run these models at full speed, and for them it’s not a problem.

Paul Asadoorian (33:18.449): And I fully expect we’ll see cases where, if they don’t have the hardware themselves, they’ll either rent it legitimately or illegitimately — because they’re threat actors. If they break into a system capable of running the model, what stops them from just running the model on it? Eventually it gets detected, but we’ve seen that throughout cybersecurity history — attackers will take over infrastructure just to use it, not necessarily for extortion, ransomware, or whatever.

Vlad Babkin (33:48.583): Yep, yep, yep. And again — raise a hand — we have BMC vulnerabilities that allow exactly this type of takeover.

Paul Asadoorian (34:00.220): Right, right. You also had an article here, Vlad, about VM escapes — I believe an AI harness that discovered vulnerabilities in Linux KVMs and the like.

Vlad Babkin (34:14.394): Yup, I pretty much just told you about this — it found literal zero-days. It exploited known vulnerabilities, even exploited them twice, even though the researcher thought he’d patched completely — he hadn’t. And when it was cornered and had to find zero-days, whatever was left, it still managed to find them. So don’t expect your infrastructure to be secure. And I’ll underscore this for every single company running HTTP servers —

Paul Asadoorian (34:24.595): Mm.

Vlad Babkin (34:43.448): It’s not just hardware — it’s literally all of you. You have to write your software in a secure way. This is a topic we discuss at Eclypsium almost non-stop: how do we not make this mistake, how do we make sure our services don’t allow some very easy validation bypass? Because once an attacker bypasses you — before, it was, okay, attacker got code execution, and then the attacker has to escape containers, raise privileges — that would take hours or weeks of investment, and probably nobody would do that. Now it’s hours, tops, to go from zero to root to escaping the sandbox, because of initial research into the vulnerabilities. Statistics from CTFs — I can’t quote articles directly, I don’t have them top of mind — but once advanced AI capabilities started coming out —

Paul Asadoorian (35:12.292): Mm-hmm.

Vlad Babkin (35:36.443): — CTF players managed to automate a lot of local privilege escalation very quickly. The complexity of the task — okay, you got code execution, then you have to privilege escalate — the second part became almost trivially fast. The first part is still hard because AI doesn’t get a lot of data to work with against a black-box service. But once you achieve code execution, it’s literally hours before they escape the sandbox, one way or another.

Paul Asadoorian (35:55.485): Mm. Right.

Paul Asadoorian (36:04.901): Yeah, and Quarkslab did an investigation too, looking at LLM-assisted reverse engineering and obfuscation. I believe what they did was obfuscate some binaries, put in specific strings, and task LLMs with finding those strings. The hilarious thing about this story is that basically all the LLMs cheated — they found the strings in the documentation and said, “Hey, I found it.” Even the LLM self-admitted, “I kind of cheated — that really wasn’t what you were after, was it?” It kind of knew the intention and knew it had cheated, and disclosed that. Still an interesting experiment nonetheless.

Vlad Babkin (36:36.134): Yeah.

Vlad Babkin (36:43.184): Yup. Yeah.

Vlad Babkin (36:50.522): Yeah, LLMs are cheating. I love — what was the channel, I believe Low Level, the YouTube channel — I died laughing at his video reviewing the Hugging Face incident: “Hey, why the hell did nobody monitor this model?” The model — when you open Claude, it has this reasoning trace — and why didn’t anybody notice, “I’m very deep into Hugging Face’s infrastructure —”

Paul Asadoorian (36:58.459): Yeah, yeah, it’s a good one. Yep.

Vlad Babkin (37:18.916): “— I’m about to exfiltrate trade data from Hugging Face infrastructure.” How was this unknown for three days? Even frontier labs have OPSEC issues. Don’t think you’re above OPSEC issues — you need technical security steps in your products to prevent this.

Paul Asadoorian (37:25.287): Yeah, it’s — yeah.

Paul Asadoorian (37:39.763): So I wouldn’t say binary obfuscation is dead because of AI — I think AI will eventually catch up — but I did appreciate the experiment from Quarkslab and their description of their tests. There have been several good articles where AI didn’t give the perfect answer, but people are still writing it up and sharing what they found: “Hey, we used AI to accomplish this task — here’s what it did well, here’s where we need more work.”

Vlad Babkin (38:11.824): The bigger question isn’t how to run AI for discovery — we already see articles about that. The hard question the industry is asking, with no good answer yet, is: how do you use AI to develop better software? That’s the actual hard question. Companies all rushed to vibe-code and then rushed back, and it’s really visible in the market that the promise wasn’t fulfilled. So that’s the question we’re trying to answer as well —

Paul Asadoorian (38:26.844): Yes. Yes.

Paul Asadoorian (38:35.090): Mm-hmm.

Vlad Babkin (38:41.646): — how do you incorporate AI in a way that doesn’t reduce the quality of your software? And again, I’ll be one of the guys who — hey, somebody announces on Twitter that they built software with AI, and within a day it’s “why are you hacking me, why are you hacking me?” Well, I’m going to sit right in that seat: infra-trust.org was built fully using AI.

Paul Asadoorian (39:06.728): Yeah. So is Fettle — so is my open source tool, Fettle.

Vlad Babkin (39:10.362): Yeah, so if you guys really want a challenge, go ahead and poke InfraTrust. If you find a vulnerability, come back and tell us, because that would be interesting — it could lead to publishing something about this topic. Like, how do we incorporate AI? Right now I’m not —

Paul Asadoorian (39:31.230): But you’ve got some good skills — by “skills” I mean actual skills, for Claude, that help us develop better quality software more securely. So I think you need that if you’re relying on AI to do it. You have to tune it, tune the context, and direct it in a way that increases your chances of it creating reliable, more secure software. That’s one thing.

Vlad Babkin (39:59.076): Yeah, and at some point we probably need to write an article about this — I’m not going to dive too deep here, because if I do, we’d need a three-hour episode, at least, since we already have a lot stacked into this.

Paul Asadoorian (40:07.624): Yeah, yeah, yeah. That’s one thing. The second thing is you’ve got to have a good test harness, and you can’t necessarily trust AI to build your test harness a hundred percent — you have to do some testing on your own. The other thing I do with my codebases is get another model — say I’m using Opus to develop it, I’ll use another model and say, “Go review this code for security —”

Vlad Babkin (40:23.696): Mm-hmm, yep.

Vlad Babkin (40:34.874): — and get another model to criticize it.

Paul Asadoorian (40:40.796): — regular bugs, performance, whatever. Then I’ll take the result of that report and funnel it back through Opus, and it’ll validate and fix things. I did that with Fettle — I ran it through Antares, and through one of the models, whichever OpenAI model was best suited for that — and it found bugs, and then I used Opus to fix them. I think as long as you’re iterating like that, it increases your chances of —

Vlad Babkin (40:56.326): So —

Vlad Babkin (41:00.422): So —

Paul Asadoorian (41:09.626): — not introducing bugs, or especially security vulnerabilities.

Vlad Babkin (41:13.786): Yeah, and another interesting point — use standards. There’s the agents.md standard. At some point, Paul — notes are down, we probably have to discuss it with engineering and with Ariella — we probably want an article about this: how do you write agents.md in a way that’s actually useful? Maybe publish one of our internal examples. If you combine this with a GitLab pipeline, or GitHub Actions, or whatever floats your boat — Jenkins, doesn’t matter — the whole point is, in my case, AI has full visibility into every single test I run. I’m not hiding anything from it. AI sees the full pipeline configuration for testing — it sees everything. Yeah, it can cheat, but it knows I review the code, so if it cheats, I’ll go ahead and ask it to fix it. I’m not exactly worried about it cheating.

But the whole point is, because AI knows the exact tests, it can run them itself and find issues with the code on its own.

Paul Asadoorian (42:18.856): Yep, that’s what I do for Fettle. I’ve got about five virtual machines — four or five different Linux distributions — and when I tell it to do a full QA run, it’ll run my software on each of those VMs, observe the results, and identify and fix bugs through that QA run. I also run the tool myself to update my own systems, and I’ll discover bugs or features that aren’t quite the way they should be, and funnel that back in as well. So it’s a twofold process — automated QA testing and manual QA testing.

Vlad Babkin (42:58.447): Yup, there’s manual QA. If you have automated QA and a pipeline, sure as hell run tools — if you use Python, run Pylint; if you use Go, there’s a Go linter. Use a linter for your language. Use unit tests for your language. Do coverage reports. Get AI to achieve full coverage — specifically ask it to cover every single line, because then it has to exercise every line, and if it introduced a bug, it will get caught.

Paul Asadoorian (43:09.192): Yep, yep.

Paul Asadoorian (43:16.627): Yes.

Vlad Babkin (43:27.205): Yeah, it’s not perfect — we find bugs in a hundred-percent unit-test-covered code. It’s not a silver bullet by any means. But your chances of having a bug in AI-written code go progressively down with every single verification step.

Paul Asadoorian (43:33.202): Of course.

Paul Asadoorian (43:45.226): Yeah. And I think a last piece of advice would be to make sure you’re having the conversation and doing the research about which technologies to use — going back to the Flask-versus-FastAPI point — those are some of the most important architecture decisions. You can use AI to help make them, but as a human you need to do research on your own. I’ve told it which containers to use, which web technologies to use, and asked it for the pros and cons of each — how popular is this on GitHub? If I put forth some requirements and it comes back with some esoteric thing that hasn’t been battle-tested, no, I don’t want to use that. So that’s some of the other advice, if most of us are using AI in some capacity in our development.

Paul Asadoorian (44:42.161): Traffic cameras — this was Slovakia’s National Security Authority issuing a warning that Nero R1 units contained — their analysis found the hardware and software’s real origin was unclear, communication settings that didn’t match the documentation, and pre-configured remote access mechanisms the operator couldn’t fully control.

Paul Asadoorian (45:12.221): Now, that last one is a fancy way of saying it’s a backdoor built into them. And it’s not the first time we’ve seen backdoors in firmware-based devices — VulnCheck actually did an addendum to their Endless Doors campaign as well, finding similar issues, similar backdoors, and similar supply chain issues in a whole bunch of routers. Found the backdoor, exposed to the internet.

The VulnCheck research is talking about hundreds of devices that contain it — so not too widespread — although my question, based on their research, is what other devices, branded differently but from the same Chinese manufacturers, might also be affected. As we know, Chinese manufacturers create multiple brands off the same hardware and firmware stack, and there could be others. The speed cameras are especially troublesome for me, because it’s a camera that lives in the public sector and photographs every car, every person. Look at Flock as an example of what can go wrong when surveillance equipment falls into the wrong hands, or has backdoors, or has security or configuration issues that let people take control of those feeds and query the databases behind them.

These things are everywhere now, and we’ve already seen them being used in warfare, between nation-states — we’ve seen this kind of telemetry used that way. We’ve also seen abuses from law enforcement. That’s just one aspect of it — a legitimate user could become essentially a threat actor if they use the technology outside of policy, guidelines, and ethics. But this technology falling into the hands of a threat actor — there’s a lot of bad things that can result from that.

Vlad Babkin (47:20.781): Mm-hmm. Yeah, backdoors are bad. And — why are your cameras… okay, I’ll ask this question to everybody who has a surveillance network, legitimate or not, I’m not judging — but if you have it, why the hell are your cameras visible to the internet, with visibility into the internet on both ends? How can somebody reach your cameras, and why the hell can your camera reach anyone? Why? Firewalls have existed for a while.

Paul Asadoorian (47:45.972): Agreed.

Paul Asadoorian (47:52.787): Yeah. And there’s so many — when we talk about BMCs, there was an article about PLCs this week as well, and we find them on the internet too. Things like cameras all fall in this bucket. And it’s a great point, Vlad — why aren’t we applying technologies we already know work, that would increase security, decrease their visibility on the internet, decrease your attack surface, your exposure, I should say? These aren’t expensive technologies, and they’re not difficult to implement. Last night on the show I proposed: why isn’t the US government buying bulk licenses from Cloudflare, Tailscale, and other providers that offer these great VPN technologies — which I think provide a better level of security than maintaining a device on your own? Why aren’t they providing this to critical infrastructure? Why aren’t they providing it to water facilities, to cities, states, and towns that run this surveillance equipment — which does help. If a loved one is kidnapped, you want this surveillance technology used to help stop, prevent, and curtail crime. It just can’t fall into the wrong hands, and you need to protect it properly. We don’t need some new, innovative thing — that technology exists. You can just go buy it from Cloudflare or Tailscale.

Vlad Babkin (48:58.405): Again —

Vlad Babkin (49:09.167): — for a good cause.

Paul Asadoorian (49:29.128): I don’t know — that’s where I fall on it. Why is stuff exposed to the internet?

Vlad Babkin (49:34.790): So the problem is: why don’t you have a VPN? Without even Tailscale — make an OpenVPN box that has access to all of this stuff. Imagine, instead of exposing web UIs for different tools, you just put a VPN box in front and connect to that. Suddenly your entire network is much more secure, and it’s not that complicated to do for a water facility.

Say you have a whole factory — put in three VPN boxes for redundancy so you can access from the outside. Install OpenVPN or WireGuard on them. It won’t cost much. These boxes can be Raspberry Pis if you don’t have a lot of budget — you don’t need a mega server with a mega power supply. You get redundancy through quantity.

Paul Asadoorian (50:16.052): Mm-hmm.

Paul Asadoorian (50:22.292): Yeah, I’ve done that before.

Vlad Babkin (50:31.939): And suddenly your facility is no longer exposed to the internet. You don’t need a super specialist to do this safely — you just get an admin and give him three days.

Paul Asadoorian (50:42.582): Mm.

Vlad Babkin (50:48.707): Well, there are systems depending on this, so maybe not three days — give him a month. The admin will solve this task, and it won’t cost you a lot. Get a guy who’s ready to do a side gig for this — you don’t even need him full time. A lot of people will take this as a side gig, because some people are patriotic and want to help their communities. They’ll get paid for it, sure, it’s not pure altruism, but they’ll be ready to do a side gig without expecting a long-term contract. So you can totally do this — it’s not going to cost you much, but it will save you from a lot of problems later.

Paul Asadoorian (51:31.214): I think that’s all we had this week. Want to remind our listeners to check out all of our previous episodes — eclypsium.com/podcast has all of those, including all the transcripts. Make sure you check out InfraTrust — infra-trust.org is our website that helps you identify, search, and sort vendor advisories that relate to infrastructure in your environments. Make sure you go check that out. Again, completely free — no registration, no gates. We’re not asking anyone for any money. It’s a free service to the community to help you get a handle on your security advisories for infrastructure devices, software, and firmware. So thanks, everyone. Go ahead, Vlad.

Vlad Babkin (52:14.489): — and, they’d say, developed with AI, and maybe getting an API at some point — not sure yet.

Paul Asadoorian (52:18.836): Yes, developed with AI. Yes, we hope. Thanks, Vlad. Thanks everyone for listening and watching. We’ll see you next time.

Back to all Podcasts