DEV Community: Maria

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!

Software Supply Chains Under Pressure: Lessons from 2025 on Malware and AI

Maria — Wed, 07 Jan 2026 11:27:36 +0000

2025 marked a turning point for software supply chain security. AI-assisted malware, self-propagating attacks, and large-scale trust abuse changed how compromises move through dependencies, registries, and CI/CD pipelines.

In this LinkedIn Live SafeDev Talk, practitioners break down what actually changed in 2025, why familiar assumptions no longer hold, and what development and security teams need to adapt in 2026.

Join us!

📅 𝐉𝐚𝐧𝐮𝐚𝐫𝐲 𝟐𝟎𝐭𝐡 | 🎥 𝐋𝐢𝐧𝐤𝐞𝐝𝐈𝐧 𝐋𝐢𝐯𝐞

We hope to see you there!

New Threats in Open Source

Maria — Mon, 15 Dec 2025 11:25:54 +0000

The open source ecosystem has just crossed a new red line: we’re no longer dealing with “simple” malicious packages, but with self-spreading worms, AI-orchestrated attacks, and large-scale abuse of OSS infrastructure happening simultaneously.
Luis Rodríguez (Co-Founder & CTO at Xygeni Security) examines how Shai-Hulud and Shai-Hulud 2.0 turned npm into a worm-friendly propagation network, jumping even into Maven Central, how GlassWorm hid executable JavaScript in invisible Unicode with a blockchain-backed C2 and full RAT capabilities, how a real-world espionage campaign used an LLM as the primary operator for reconnaissance, exploitation, and exfiltration, and how massive spam waves like IndonesianFoods exploited funding systems and polluted registries at unprecedented scale.
This isn’t theoretical anymore: every developer machine is now a potential worm propagation point, and every stolen token a lateral-movement catalyst. Dive into the full article “New Threats to the Open Source Ecosystems: Worms, AI-Cooked Malware, and Large-Scale Trust Abuse” to understand where supply chain threats are heading—and what must change in our defensive strategies.

𝐁𝐮𝐢𝐥𝐝 𝐒𝐚𝐟𝐞, 𝐒𝐡𝐢𝐩 𝐒𝐭𝐫𝐨𝐧𝐠.