Discussion on DevSecOps Live by Practical DevSecOps on software supply chain security in the AI era — how AI-generated code, LLM-assisted development, and expanding dependency trees reshape the way teams need to think about securing their build pipelines and software supply chain.
Key Topics
Software supply chain security challenges introduced by AI-assisted development
How AI-generated code changes dependency and trust considerations
Practical defenses for securing build pipelines in the AI era
AI Generated Summary
AI Generated Content Disclaimer
Note: This summary is AI-generated and may contain inaccuracies, errors, or omissions. If you spot any issues, please contact the site owner for corrections. Errors or omissions are unintended.
Anant Shrivastava, information security professional and founder of Cyfinoid Research, joined host Martin on DevSecOps Live — Practical DevSecOps’ monthly practitioner webinar — to talk about software supply chain security in the AI era. The discussion opens with the uncomfortable irony that the security tools we recommend to builders are themselves getting hacked (Trivy, and before it CCleaner), moves through why open source developers’ unguarded desktops have become the attackers’ preferred entry point, and then examines what AI systems like Mythos genuinely change about vulnerability discovery and exploitation. Anant’s recurring thread is that basics still win: least privilege, outbound firewalls, dependency gateways, reduced attack surface, and — above all — automated verification suites, which become the deciding capability once AI collapses the “attackers don’t have time to exploit everything” assumption that risk acceptance was built on.
Summary
The setting. DevSecOps Live is a monthly event by Practical DevSecOps bringing practitioners and industry experts together. Martin introduced Anant as “one of the most humblest professionals in the security industry,” a longtime Linux enthusiast known for the Android Tamer project, now running Cyfinoid Research.
Research focus. Anant’s last two years: software supply chain security on three fronts — protecting software, attacking software, and helping the developers who build open source secure themselves — plus AI from a usage-and-security angle, focused on local models, safe usage, and the pitfalls of AI already inside organizations.
The arc. The conversation moves from recent supply chain incidents (the Trivy hack, Shai-Hulud, CCleaner, SolarWinds) to practical developer defenses (PMG, vet, outbound firewalls, no-admin daily drivers), to a deep analysis of the Mythos AI vulnerability-finder and its Firefox case study, to a beginner’s tour of SBOM/SLSA/SSDF and their historical roots (the 1974 Multics evaluation, Ken Thompson’s 1984 “Reflections on Trusting Trust”), and closes with advice for vibe coders and an audience question on risk acceptance. Anant also pointed to his upcoming appearances: a conference in Bangalore in mid-June, then Black Hat USA and DEF CON USA.
Weakest Links: Trivy, CCleaner, and the Developer Desktop
Tools get hacked too. Martin opened with the recent Trivy hack (“who watches the watcher”) — the Aqua Security all-in-one scanner that “can scan everything” was itself compromised. Anant drew the line back to CCleaner: recommended for years, acquired by Avast, and then its build system was attacked around the acquisition and it started spreading malware. SolarWinds — itself a monitoring vendor — reached roughly 450 of the Fortune 500.
Attackers take the easiest path. Corporate environments have AV, IDS/IPS, and firewall mandates; open source developers have none of these and often don’t know they are a target:
The easiest target right now is the stuff which we don’t care for and that’s the developer’s desktop… If you see the origination point of it, a token gets leaked either at a developer’s machine or a token gets leaked inside a CI/CD system in a log.
— Anant Shrivastava
That is exactly what the Shai-Hulud npm worm and similar malware exploited: the weakest link, seeded by a leaked token that then enables lateral movement.
Trusting Dependencies: Philosophy and Practical Firewalls
AI as a junior developer. “Treat the AI systems as a very efficient code creator, as a junior developer who can write code. I am not saying good code… but code.” You must steer it — and understand what it writes before shipping it.
Three buckets of open source developers — a distinction invisible to the people pulling dependencies:
Paid to be open — employed by companies, hopefully with corporate protections.
Portfolio builders — doing open source in hopes of getting hired (a narrative the security community itself promoted); when they get hired, or the library gets bought, the library gets abandoned.
Old school — scratching their own itch, disclaiming responsibility, and refusing added friction: “Why should I add more resistance to my work? I’m not asking anyone to use my code.”
Because consumers can’t tell which bucket a maintainer is in, “what we need is some sort of a firewall in between.”
Dependency gateways. Abhishek Datta’s company SafeDep builds vet and PMG (both open source). PMG acts as an install-time proxy: it captures the package name, checks it against SafeDep’s server, and returns a clean/malicious verdict. Anant uses it on his own machines. Martin’s caveat: it helps only as long as SafeDep keeps scanning and maintaining it.
Delayed updates are a double-edged sword. Waiting 3–7 days before updating blunts fast-moving malware, but npm developers don’t separate security fixes from feature releases, and some npm packages ship daily — delay a week and you’re seven releases behind on security fixes.
Outbound firewalls. The desktop control that matters: a prompt like “your MS PowerPoint wants to talk to stealthesecret.com — allow?” — because, as Martin noted, “most exfiltrations are sending data and writing a channel somewhere else.” Tools: OpenSnitch (Linux), Little Snitch (macOS), plus Objective-See’s KnockKnock; the once-excellent Little Flocker is gone post-acquisition.
No admin on daily drivers. Anant doesn’t run as admin by default on his Mac, Linux, or Windows boxes — admin actions require a deliberate user switch, adding protective friction.
Least Privilege Beyond the Laptop
The debug-access trap. Martin shared a war story: on Windows, debugging .NET processes required admin, so at a 500-person company the whole .NET team held admin rights; privileged-access reviews were supposed to run every 3 months but “the default list goes on for about a year” — “compliance managers are happy, auditors are happy.”
Lateral movement mechanics. Anant: compromise spreads because users are admin on multiple boxes — run BloodHound, dump credentials, pivot. At null meetups his team demoed Mimikatz on a developer workstation where a domain admin had also logged in to troubleshoot: the dump yielded the domain admin’s password too.
What leaks when a developer is compromised. His supply chain course opens with this exact scenario: GitHub credential leaked, AWS credential leaked, production SSH key leaked — “your entire environment is compromised.” Justifiable for a two-person startup; in a 500-person company, the missing segregation of duties is what makes the spread fast.
Controls exist but go unused. Credential rotation and just-in-time tokens are well known — yet organizations end up pulling the AWS root account key and using it for everything.
The career angle. Holding all the keys as leverage (“the single point of failure who could never be fired”) versus being the lynchpin who does good work, hands it over, and gets pulled into newer projects — Anant recommends the latter posture.
Mythos and AI-Driven Vulnerability Discovery
Cut through the hype. “Take everything said about Mythos with a pinch of salt. It is said by a company that has built a product that they want to probably at some point sell” — fear is part of the marketing.
What it actually does. Mythos is a new iteration of LLM models with strong pattern retention. It surfaces what “no one actually looked hard enough” for — not new bug classes: “What I have not seen is AI finding a new class of vulnerabilities… they’re finding large number of instances” of already-documented, already-exploited classes. A human tires after ~20,000 lines of code; the model does higher-level pattern matching at enormous speed, including cross-file patterns that grep/regex could never express. Anant demonstrated pattern-based mass bug discovery years earlier with his Code Vigilant project.
The finding isn’t unique — the harness is. A week after Mythos’ headline report, the people behind Hugging Face reproduced the same findings using open-source models; almost all the models found the problems. Speed and the instruction harness made the difference, not the discovery itself.
Firefox case study. Firefox used Mythos in preview: 271 exploitable vulnerabilities found. The model kept pursuing an exploitation path that was structurally impossible under Firefox’s architecture; the Firefox team did what “hardly 0.1% of the people do” — read through the model’s chain-of-thought — and manually redirected it before it produced working PoCs.
Offense is easier than defense. Attacker success is trivially verifiable (uid 0, a root credential in /etc/passwd or /etc/shadow); defenders must weigh instance-fix vs architectural fix, regressions, and functionality loss — Rowhammer mitigations cost roughly 33% of CPU performance.
The quote of the session:
All offensive problems are technical in nature. All defensive problems are political in nature.
— Halvar Flake, Black Hat Asia 2017, quoted by Anant
His two-pronged defense: (1) a verification suite — automated tests that catch resurfaced bugs and regressions before they ship; (2) dependency reduction — npm packages that drag in 500–2,000 transitive dependencies when you use a single function; write that function yourself and own it. Test upgrades in an isolated CI run, audit frequently-updated packages, and let SBOMs inform the pruning.
“Every Bug Is Exploitable”: Attack Surface and the Open Source Trade-off
Flip the risk model. His advice to a friend exploring AI offensive work: take bugs older than a year marked “not exploitable / no PoC” and build PoCs for them — the diffs are public, so it’s a matter of effort. Once PoCs go public, EPSS scores rise, CISA pulls them into KEV, and patching follows. Hence: “Every bug should be considered exploitable even if the path is not reachable. Consider that a bug is a bug and try to mitigate around it.”
npm as the poster child. is-odd does the work; is-even calls is-odd and returns the inverse. Use AI to interrogate your dependency list: if you need one function out of a module, bake it into your code and own it.
“Dead on arrival” open source. A quote that stuck with him from SBOM community discussions: “In my company we consider open-source as dead on arrival” — either freeze the version or take ownership and maintain it from that point on. That demands a mature organization; the practical narrative shift for everyone else is to treat open source as a reference implementation of good architecture and write your own version.
Variation defeats exploits. A Windows bug hits every Windows box; a Linux webcam-driver bug hits one driver, one kernel version, one laptop model. More variation means each exploit needs costly tailoring — and with AI, exploit creation has real token, electricity, and time economics.
The centralization flip. Shared dependencies mean one exploit works everywhere — “the pinnacle of centralization.” Owning small, self-maintained pieces flips the economics against attackers (per-target tailoring becomes “an uphill battle”) at the price of being the only one defending your code. Any commercial product is built for generalization — you use 5–10% of it (a Google-ecosystem customer still ships and maintains a Microsoft-auth path it never uses) — so owning your slice also shields you from bugs in the unused 90% and from surprise feature removals.
A 70% case study. A friend’s company ran 100–200 internal projects feeding a central logging system through 10 different frameworks. Using SBOM analysis they standardized on 3 frameworks and measured a 70% reduction in framework maintenance — freeing developers for features and enabling close monitoring, freeze-and-backport, or rapid upgrades on a small, known surface. Martin connected this to Netflix’s “paved pathway” concept.
SBOM and SLSA: A Beginner’s Tour
SBOM = the ingredient list. Like a recipe listing cumin seeds, salt, and grated onion. Two depth models: one-level-deep (direct dependencies only — the norm until 2025) and the now-recommended full SBOM listing every transitive dependency, however deep: “If there is a package which goes 200 level deep, you need to have all 200 levels documented.”
An SBOM is not SLSA level 1. “SBOM does not secures anyone. SBOM does not creates vulnerabilities… it just tells you this package, this version, is what you’re using.” Value comes from augmentation on top: Dependency-Track, dependency-check, VEX/VDR feeds.
Formats. SPDX (the ISO standard; used wherever the US government is involved; GitHub’s Insights → Dependency graph export is SPDX) vs CycloneDX (OWASP-origin, European standard, where most tooling and the VEX/VDR effort live). SWID is obsolete.
SLSA. A corporate-level initiative led by Google and others, defining build-environment assurance levels 1–4. Martin’s joke: “They should have rather called it leniency one, leniency two” — levels as a cost/benefit dial: “I don’t want to spend 10,000 rupees to protect 100 rupees worth of an asset.”
The deep history. Vulnerable components have been in the OWASP Top 10 since 2004 (A10 insecure configuration management; A6 security misconfiguration in 2010; A9 in 2013 and 2017; A6 vulnerable and outdated components in 2021). The compiler-backdoor question dates to the 1974 US Air Force Multics security evaluation; Ken Thompson demonstrated it in his 1984 Turing Award lecture “Reflections on Trusting Trust” — prompting Martin’s quip that it should be called the “principle of complete attacker mediation.” Debian’s reproducible builds project declared 100% of main-repository packages reproducible in 2026.
Why SBOM exists: SolarWinds. After SolarWinds hit ~450 of the Fortune 500, the US government embedded one line into a presidential directive — every vendor must provide an SBOM — and directed NIST to create the SSDF (with SBOM requirements baked in). SLSA developed in parallel. SSDF is on a path to ISO standardization and uniquely maps every line item to equivalent requirements in other standards (e.g., PCI DSS) — a gift for compliance teams.
Would an SBOM have stopped SolarWinds? “Nope.” SBOMs don’t cover developer machines, Jenkins setups, VS Code/Notepad++/Sublime Text plugins, or Chrome extensions — the subject of Anant’s first supply chain talk, “Beyond the SBOM.”
Reproducible vs hermetic builds. Reproducible builds are bit-for-bit identical anywhere (hard to achieve); hermetic builds allow differences only at known places (compile timestamps, kernel version). Mature setups verify with parallel builds — like fault-tolerant server CPUs computing the same thing twice and comparing. Start at slsa.dev, but adopt SLSA and SSDF together so a future mandate doesn’t leave gaps.
AI degrades maturity. Teams switching IDEs (Copilot/Cursor-style tooling) lose protections that lived in old-tooling extensions — expect a fall from SLSA level 3 to 2 or 1 until equivalent extensions, MCP gateways, or gateway checks are restored.
Advice for Vibe Coders
Read the guide. His detailed “vibe coding survival guide” is on his blog, anantshri.info.
Gate your installs. Put PMG and vet into your workflow as part of the process.
Own architecture and verification. “The coding is done by the system, you are not writing code” — to be an equal participant, own what gets built and how it’s validated. Define edge cases and check them; even non-coders catch failures like asking for 2+5=7 and getting 8, because they test functionality.
Constrict the model. Instruct like you would a 5–6-year-old with a plain page and a sketch pen: “draw a face” gets you a circle, an oval, or an egg; specify the square face, rectangular eyes, triangular nose, vertical rectangular mouth. Anant’s browser-only projects start with: “Do not use any JavaScript framework — write plain old JavaScript, abstracted into meaningful, manageable functions” — and he re-prompts whenever the model drifts.
Talk to it like an agent, restart without guilt. It’s a next-word predictor, not a person — so steer it, or restart: “Don’t worry if you have spent 5 days and the result looks absurd. Go back 2 days, go back 3 days and then start from there wherever it was looking good.”
Q&A: Risk Acceptance After Mythos
KEV is contextual. CISA’s Known Exploited Vulnerabilities list covers exploitation pertaining to US government systems and vendors — a CVSS 10 bug exploited everywhere else may never appear on it.
Enrichment is thinning. NVD now prioritizes CVE enrichment for US government–linked products, deprioritizing everything else; EPSS signals (popularity, chatter, observed exploitation attempts) shift accordingly.
Exploit economics cut both ways. Obscure proprietary IoT remains expensive to exploit (decompilation, reverse engineering); popular, public, large-attack-surface software will attract funded exploits — which then work everywhere that shares the dependency.
The time excuse is dead. Risk acceptance was always a volume argument — “I don’t have enough time to patch every single bug.” With AI agents on both sides: “If you have verification capabilities, you would not have a patching problem… The speed is not a factor now. You just need to have more processors… more agents.”
Practical close: contextualize risk to your environment, PoC and fix existing bugs aggressively with current tooling, and sell attack-surface reduction as tech-debt reduction — “Do you want to maintain 2,000 projects or do you want to maintain 200 projects strongly?”
Key Takeaways
Assume every dependency — and every security tool — can be compromised; the attack usually starts with a leaked token on a developer machine or in CI/CD logs.
Treat AI-written code as a fast but untrusted junior developer: you own the architecture and the verification.
Install the cheap controls today: no admin on daily drivers, an outbound firewall (OpenSnitch/Little Snitch), and a package gateway like PMG.
Generate full (transitive) SBOMs — but remember an SBOM secures nothing by itself; value comes from the tooling and process around it (SLSA + SSDF, reproducible/hermetic builds).
Operate as if every bug is exploitable: PoC your backlog, shrink your dependency tree and attack surface, and frame that shrinkage as tech-debt reduction.
Build and maintain a verification suite — it is the single capability that turns AI-speed patching from fantasy into routine.
