DEV Community: Maria

The npm install your AI agent ran while you weren't looking

Maria — Thu, 03 Sep 2026 09:53:28 +0000

For fifteen years, npm package security rested on one assumption so obvious nobody wrote it down: a human sat between the decision to add a dependency and the moment it landed on disk.

Agentic coding assistants quietly removed that checkpoint. They decide a package is needed, pick one, and run the install — mid-task, without review. The pause that was doing security work without anyone noticing is no longer in the workflow.

That matters more than it sounds, because npm was already the most attacked package ecosystem in software development before agents showed up.

What's actually happening at the registry level

Research across 16 LLMs generated two million code samples and found nearly 1 in 5 recommended packages didn't exist. The same hallucinated names recurred predictably across models and prompts. Predictable enough to register in advance. Predictable enough to weaponize before your agent asks for them. That attack has a name: slopsquatting.

On top of that, a critical RCE vulnerability in a widely used MCP bridge fired the moment a client connected to an untrusted server. An agent makes that connection autonomously. No user interaction. No existing tool in a standard AppSec stack intercepts it before it happens.

Why your current tools don't see it
SAST parses code. SCA checks what's already in your dependency tree. Neither has visibility into what an AI agent just decided to install two minutes ago, or what an MCP server is doing mid-task.

This isn't a configuration gap. It's a category gap that opened quietly as autonomous agents became standard in how software gets built.

The full breakdown — what changed in the npm threat model, what the MCP attack surface looks like, and what actually closes the gap at the registry and install layer — is here:

👉 npm Package Security: What Changes When Your AI Agent Runs the Install

If you're running any agentic tooling or care about supply chain threats, it's worth the read.

Your AI Assistant Just Recommended a Package That Doesn't Exist

Maria — Wed, 26 Aug 2026 07:39:16 +0000

Go ahead, ask your favorite AI coding assistant for a package recommendation. There's a ~1 in 5 chance it just made one up.

That's not a joke stat. Researchers at USENIX Security 2025 ran 2 million code generations across 16 LLMs and found a 19.7% hallucination rate for recommended packages. And here's the part that should actually worry you: the same fake names came back again and again across repeated prompts.

That's not random noise. That's farmable.

Enter: slopsquatting 🎭

Attackers have caught on. The playbook is simple:

Ask popular LLMs for package recommendations on common tasks, repeatedly
Note which hallucinated names keep showing up
Register those names on npm / PyPI / Maven, with malicious code inside
Wait for a developer (or an agent) to pip install / npm i the name their AI just "recommended"

One test package planted as a proof-of-concept picked up 30,000+ downloads in three months. This isn't theoretical anymore, it's a live attack surface.

*The bigger problem: nobody's reviewing the install anymore
*
Here's the shift that actually changes the threat model: agentic coding tools don't just suggest packages, they install them. Mid-task. No pause. No human glancing at the name before it hits disk.

The entire "a developer reads the package name before installing" checkpoint, the thing supply chain security has quietly relied on for 15 years, just... isn't in the loop anymore.

Add to that:

npm has had 3 major supply chain incidents in 8 months (Shai-Hulud, the axios compromise with nation-state malware, a near-identical worm via SAP packages)
Roughly 40% of AI-generated code ships with a vulnerability
Traditional SAST/SCA tools understand code, not whether a model, agent, or MCP server has been compromised

*So what actually catches this?
*
Two things need to happen, and they need to happen automatically, regardless of whether a human or an agent triggered the install:

Registry-level detection
** — scanning newly published packages for malicious behavior, not waiting for a CVE/signature to exist. (This is what MEW does, and it's free in Xygeni's Developer tier if you want to poke at it.)
**
Install-time enforcement
** — checking policy at the OS level the moment an install is requested, before the package touches disk and before any install script runs. Attribution down to the exact PID/process, so it doesn't matter if it came from your terminal or an agent running in the background.

*Real talk: how are you handling this?
*
Genuinely curious what the dev.to community is doing here. Are you:

Pinning/vetting every dependency an agent suggests before it merges?
Running any kind of pre-signature malware detection?
Just... trusting it and hoping for the best? (No judgment, most teams are here.)

We're talking through this in person at OWASP AppSec Days Portugal and German OWASP Day (both Sept 23-24). If you're around either event, would love to compare notes!

Your Coding Agent Just Installed a Package. Did Anyone Check the Name?

Maria — Thu, 23 Jul 2026 09:19:36 +0000

Real talk: how many of you have actually looked at every package name your AI coding assistant pulled in this week?

Not "did you review the code it wrote." Did you check the dependency it decided to install.

If the honest answer is "no," you're not alone, and that's exactly the gap this SafeDev Talk is about.

𝐓𝐡𝐞 𝐩𝐚𝐫𝐭 𝐧𝐨𝐛𝐨𝐝𝐲'𝐬 𝐭𝐚𝐥𝐤𝐢𝐧𝐠 𝐚𝐛𝐨𝐮𝐭

Copilots used to draft. You'd read the suggestion, hit tab, move on. That was the trust model: AI proposes, human disposes.

Agentic tools don't work that way anymore. They install dependencies. They touch Dockerfiles. They trigger CI/CD steps. Sometimes all without a human in the loop at the exact moment it happens.

Code review, commit history, that little pause where someone glances at a diff, all of that was built assuming a person made the call. What happens when the thing making the call is an agent?

Why your SBOM might not have the answer

𝐘𝐨𝐮'𝐯𝐞 𝐩𝐫𝐨𝐛𝐚𝐛𝐥𝐲 𝐠𝐨𝐭 𝐭𝐡𝐞 𝐭𝐨𝐨𝐥𝐢𝐧𝐠 𝐚𝐥𝐫𝐞𝐚𝐝𝐲:

SBOMs
Dependency scanners
CI/CD security gates
Code review on every PR

Good tooling. Built on an assumption that's getting shakier: that a human decided what went into the build, and left a trail you can audit.

𝐓𝐫𝐲 𝐚𝐧𝐬𝐰𝐞𝐫𝐢𝐧𝐠 𝐭𝐡𝐞𝐬𝐞 𝐰𝐢𝐭𝐡 𝐰𝐡𝐚𝐭 𝐲𝐨𝐮 𝐡𝐚𝐯𝐞 𝐭𝐨𝐝𝐚𝐲:

Can you tell whether a developer or an agent installed a given dependency?
Does your SBOM capture that distinction at all?
If an agent commits and merges, does "code review" still mean what you think it means?
What does shift-left even mean when the fastest-moving thing in your pipeline isn't a person?

If those questions make you pause, that's the point of this session.

𝐖𝐡𝐚𝐭 𝐰𝐞'𝐫𝐞 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐜𝐨𝐯𝐞𝐫𝐢𝐧𝐠

This is a live, practitioner-led SafeDev Talk organized by Xygeni, not a slide deck about AI risk in the abstract. We're getting into:

How "AI suggests" quietly became "AI acts" in real engineering teams
What changes at the install moment when nobody checks the package name first
Whether SBOMs and provenance hold up when an agent decided what goes into the build
What's left of code review and shift-left when agents commit on their own
What a secure agentic pipeline actually needs: tooling, process, and team culture
Who should show up

If you're in AppSec, DevSecOps, platform engineering, or you're just the person on your team who already knows agents are touching dependencies and containers whether it's "officially allowed" or not, this one's for you.

📅 August 6th
⏰ 11:30 CEST
➡️ Register here: https://www.linkedin.com/events/7485971126628675584/

Bring your worst "wait, did the agent actually do that?" story. We'll get into it live.

When Does the CRA's 24-Hour Reporting Clock Actually Start?

Maria — Thu, 16 Jul 2026 09:33:52 +0000

The Cyber Resilience Act (CRA) introduces a requirement that many engineering teams are still trying to operationalize: report actively exploited vulnerabilities and incidents within 24 hours.

At first glance, that sounds straightforward. Until you ask one simple question:

When does that 24-hour clock actually start? -Is it when a vulnerability appears in your Software Bill of Materials (SBOM)?
When your Software Composition Analysis (SCA) tool raises an alert?
When an exploit becomes public?
Or only after you've confirmed that your product is actually affected?

For many organizations, those are very different moments.

𝐅𝐢𝐧𝐝𝐢𝐧𝐠 𝐚 𝐯𝐮𝐥𝐧𝐞𝐫𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐢𝐬𝐧'𝐭 𝐭𝐡𝐞 𝐬𝐚𝐦𝐞 𝐚𝐬 𝐡𝐚𝐯𝐢𝐧𝐠 𝐚𝐧 𝐢𝐧𝐜𝐢𝐝𝐞𝐧𝐭

Modern development teams receive thousands of security findings every week.

Most come from:

Software Composition Analysis (SCA)
SBOM scanning
Dependency monitoring
Container image scanning
Secret detection

The challenge isn't finding vulnerabilities anymore.

The challenge is determining which findings actually require action.

Without a structured workflow, teams either:

waste valuable time investigating non-issues,
or worse, miss the moment when a vulnerability becomes a reportable incident.

𝐓𝐡𝐞 𝐦𝐢𝐬𝐬𝐢𝐧𝐠 𝐩𝐢𝐞𝐜𝐞: 𝐜𝐨𝐧𝐭𝐞𝐱𝐭

An SBOM tells you what components you use.

SCA tells you which components are vulnerable.

But neither automatically tells you:

Is the vulnerable code actually reachable?
Is it exploitable in your environment?
Which product versions are affected?
Who should be notified?
Has the CRA notification clock started?

Answering those questions requires more than vulnerability scanning—it requires a repeatable incident response workflow.

A practical session for engineering and security teams

If you're working in:AppSec, DevSecOps, Platform Engineering, Product Security, Vulnerability Management

Xygeni & SecureHabits are hosting a free live webinar where we'll walk through a practical approach to CRA notification readiness.

We'll cover:

Generating and using SBOMs
Prioritizing SCA findings
Reachability and exploitability analysis
Notification workflows
What actually triggers the CRA's 24-hour ENISA reporting requirement

📅𝐉𝐮𝐥𝐲 𝟑𝟎
🕟𝟏𝟔:𝟑𝟎 𝐂𝐄𝐒𝐓

Whether your organization is already preparing for the CRA or just beginning to understand its impact, the goal is to leave with a workflow you can apply—not just another compliance checklist.

The npm package your AI just suggested doesn't exist. Someone already registered it. published: false

Maria — Wed, 08 Jul 2026 08:31:02 +0000

Nearly 1 in 5 packages, an AI coding assistant suggests, are pure invention. Attackers know this, and they're registering those hallucinated names with malware, waiting for the next pip install or npm install.

We're running a live webinar on July 22nd @ 10:30 CEST to show how this works and how to catch it before a signature even exists. Details at the bottom 👇

The problem: slopsquatting

Ask an AI assistant for code, and there's a ~19.7% chance it recommends a package that doesn't exist (source: USENIX Security 2025). That alone isn't the scary part; LLMs hallucinate; that's known.

What's scary is that the same fake name keeps coming back across prompts and models. Attackers noticed this pattern, and now they register those exact names on npm, PyPI, and other registries, ship malware inside, and wait.

This now has a name: slopsquatting. It's not theoretical:

A single hallucinated package, planted as a benign test, pulled in 30,000+ downloads in three months
Confirmed malicious packages exploiting this pattern are already live in public registries
With tools like GitHub Copilot generating ~46% of a developer's code on average, this attack surface grows every single day

Why signature-based scanning isn't enough

Over 450,000 new malicious packages were published in 2025 alone (~75% YoY growth). Traditional scanners wait for a known signature before flagging something as malicious. Against a threat this fast-moving, "wait for the signature" is already too late.

What we're showing live

We're doing a working session (not a slide deck) with two parts:

See everything — using AI Inventory + AI BOM to surface every AI component in a real codebase: models, agents, MCP connections, AI-introduced dependencies. You can't defend what you can't see.
Block the malware — showing Xygeni Shield (powered by MEW — Malware Early Warning) detecting and blocking malicious packages before a signature exists for them.

Bring your toughest question — this is a demo, not a pitch.

Details

📅 July 22nd
⏰ 10:30 CEST
Save your seat here

Curious if others have run into hallucinated-package suggestions from Copilot/ChatGPT/etc. in the wild — drop your experience in the comments 👇

🚨 AI Is Already Inside Your SDLC. Can Security Keep Up?

Maria — Wed, 13 May 2026 08:05:54 +0000

AI is rapidly transforming software development, from copilots and AI-generated code to autonomous agents and AI-driven workflows. But as adoption accelerates, AppSec teams are struggling to maintain visibility and governance across the SDLC.

Join our upcoming SafeDev Talk with OWASP leaders and Xygeni experts to discuss:

🔹 Shadow AI in engineering teams
🔹 Risks around AI-generated code and dependencies
🔹 Practical AI governance for modern AppSec
🔹 The rise of agentic SDLCs

📅 May 27th | 16:30 CEST

appsec #ai #devsecops #cybersecurity #owasp

Join Our Webinar: SAST Isn’t Enough! Why Runtime Is Where Risk Lives

Maria — Tue, 24 Mar 2026 10:12:03 +0000

Most teams rely on static analysis to catch vulnerabilities. But here’s the problem: many issues don’t exist until your app actually runs.

Code looks safe. Dependencies look clean. Pipelines pass… and still, vulnerabilities show up in production.

Because real risk = behavior, not just code. So what’s missing?

You need both perspectives:

SAST → what’s in your code
DAST → how it behaves at runtime

Only together do they show what’s actually exploitable.

We’re breaking this down live

Why static analysis alone leaves blind spots
What vulnerabilities only appear at runtime
How to prioritize real risk (not just alerts)

📅 April 7 — 17:00 (CEST)
👉 https://www.linkedin.com/events/7442142589463519232/

Modern AppSec isn’t about more scans. It’s about a better context.

Fix smarter, not more

Maria — Tue, 24 Mar 2026 10:05:39 +0000

Most teams today don’t struggle to detect vulnerabilities—they struggle to prioritize them effectively. With signals coming from SAST, SCA, secrets, and CI/CD tools, the real challenge is understanding what actually matters: what’s exploitable, what’s reachable, and what can be fixed safely without breaking workflows. Instead of relying only on severity, teams are moving toward risk-based remediation, combining context, exploitability, and stability while reducing noise and automating fixes through PRs. If you’re dealing with alert fatigue or slow remediation cycles, this checklist is a good starting point → https://go.xygeni.io/ai-driven-remediation-risk-prioritization-checklist

Fixing vulnerabilities isn’t the hard part. Choosing the right ones is.

Maria — Mon, 23 Mar 2026 12:21:45 +0000

AI Is Writing Your Code. Who’s Reviewing the Security?

Maria — Thu, 26 Feb 2026 15:16:48 +0000

AI copilots like GitHub Copilot and Cursor can generate production-ready code in seconds, and autonomous agents can refactor entire modules without human review. Development velocity has never been higher—but neither has the risk surface.

Most teams still rely on CI-only security scanning, which detects vulnerabilities after code is merged, when fixing issues is slower, riskier, and more expensive.

In this live session 𝐕𝐢𝐛𝐞 𝐂𝐨𝐝𝐢𝐧𝐠 𝐖𝐢𝐭𝐡𝐨𝐮𝐭 𝐑𝐞𝐠𝐫𝐞𝐭: 𝐒𝐞𝐜𝐮𝐫𝐢𝐧𝐠 𝐂𝐨𝐩𝐢𝐥𝐨𝐭𝐬 𝐚𝐧𝐝 𝐀𝐈 𝐀𝐠𝐞𝐧𝐭𝐬 𝐟𝐫𝐨𝐦 𝐭𝐡𝐞 𝐈𝐃𝐄, we’ll show how security can move into the IDE, where AI-generated code is actually created. You’ll see how to detect vulnerabilities in real time as you code, validate reachability before merge, apply guardrails to Copilot and AI-generated changes, and safely remediate issues with AI-assisted fixes.

We’ll also run a live demo securing Copilot and agent-based workflows end-to-end.

If you’re using Copilot, Cursor, or any AI coding tools—and pushing code to production—this session will help you avoid shipping vulnerabilities at AI speed.

📅 March 11, 2026
🎥 Live demo included
👉 Register here: https://www.linkedin.com/events/7432784645383110656/

EU Cyber Resilience Act in Practice Webinar

Maria — Wed, 04 Feb 2026 10:29:33 +0000

𝐄𝐔 𝐂𝐲𝐛𝐞𝐫 𝐑𝐞𝐬𝐢𝐥𝐢𝐞𝐧𝐜𝐞 𝐀𝐜𝐭 (𝐂𝐑𝐀): 𝐰𝐡𝐚𝐭 𝐢𝐭 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐦𝐞𝐚𝐧𝐬 𝐟𝐨𝐫 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬?

If you’re building software products in the EU, the Cyber Resilience Act is no longer just a compliance topic; it directly impacts how you design, build, and maintain software.

In this practical Webinar 𝐄𝐔 𝐂𝐲𝐛𝐞𝐫 𝐑𝐞𝐬𝐢𝐥𝐢𝐞𝐧𝐜𝐞 𝐀𝐜𝐭 𝐢𝐧 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞, we’ll break down:

What the CRA really requires from development teams
How those requirements translate into concrete AppSec activities
How OWASP SAMM can be used as a practical framework to structure secure development without reinventing your SDLC

This is not a legal overview. It’s a technical, execution-focused session for developers, AppSec, and DevSecOps teams who need to turn regulation into real engineering work.

🎙️ Led by Nariman Aga-Tagiyev, Cybersecurity Architect & OWASP SAMM Core Team member.

Join if you want a clear, developer-friendly path from CRA requirements to actionable security practices https://www.linkedin.com/events/7424751762282143744/

AI Didn’t Just Change Development,It Changed How AppSec Breaks

Maria — Tue, 20 Jan 2026 12:39:14 +0000

AI is now deeply embedded in how software is written, tested, and shipped.
But most application security models are still designed for a world where humans wrote the code and pipelines moved slowly.

That gap is now being actively exploited. In 2025, attackers didn’t need zero-days. They abused:

Automation and trusted CI/CD pipelines
AI-generated code that “looks fine” in review
Inherited trust across dependencies, builds, and artifacts

Once malicious logic entered a trusted workflow, systems did the rest, at machine speed. We just released a new research report, New Application Security Attack Trends for 2026, that breaks down what actually changed and why many traditional AppSec signals failed.

What’s inside:

💠How AI changed the economics of software supply chain attacks
💠Why CVEs and static analysis missed trust-based, workflow-driven attacks
💠How persistence shifted from access to build artifacts and outputs
💠What attackers optimized in 2025 — and will keep optimizing in 2026
💠Why AppSec must move from issue lists to system-level control of execution and trust

This isn’t about running more scans. It’s about understanding how risk propagates when AI and automation are part of the execution path.

📘 Read the full report!