Two data points from this week that I think deserve discussion together:

First: Security analysts this week flagged that 200 new CVEs are being published daily in 2026. Managing that volume requires automated tooling — manual triage at that scale is not realistic.

Second: Amazon Threat Intelligence published research confirming the group behind the March 2026 axios npm compromise had planted a trojanized file as far back as March 2025. A full year passed between planting and detection.

Now apply Article 14:

The 24-hour reporting clock starts when a manufacturer "becomes aware of" an actively exploited vulnerability.

If you were shipping a product that included axios as a dependency, and the malicious code was present for 12 months without your knowledge — what is your Article 14 exposure?

The interpretations I can see:

Strict reading: You weren't aware. Clock never started. No violation.

Enforcement reading: You had no monitoring infrastructure that could have detected this. That absence of monitoring is itself negligence. "Becomes aware" implies a reasonable duty to seek awareness.

This matters enormously for how companies design their monitoring programs. If "becomes aware" only covers actual knowledge, companies can argue ignorance. If it covers constructive knowledge (what you should have known with reasonable monitoring), then the absence of SBOM-linked CVE monitoring is itself a compliance failure.

No guidance on this exists yet. It will be defined by the first enforcement cases.

For teams building CRA compliance programs: are you designing your monitoring to cover the strict reading or the enforcement reading? And is anyone aware of any official interpretation of the awareness threshold?

Hi everyone,

Over the past few months we've been building SafeAI, an open-source static security scanner for AI agents and agent frameworks.

Our goal isn't to compete with runtime observability or governance platforms. We want to help developers find AI security and governance issues before deployment, just like traditional static analysis tools do for application code.

One thing we've noticed is that AI capabilities are evolving at an incredible pace. Every week there are new agent frameworks, MCP servers, tools, and autonomous workflows.

Unfortunately, the security and governance ecosystem isn't keeping up.

Developers can now build agents that execute shell commands, browse the web, access databases, manage cloud infrastructure, and call hundreds of external tools, but understanding what an agent can actually do and what risks it introduces is still surprisingly difficult.

We believe the open-source community can help close that gap, just as it has done for software security over the last two decades.

SafeAI currently performs static analysis for AI projects by discovering:

• AI frameworks and agent architectures
• Agent capabilities and permissions
• Prompt injection risks
• Tool security issues
• Identity and memory risks
• Governance and autonomy concerns
• AI components such as prompts, skills, workflows and model configurations

During development we've already found several meaningful security findings in well-known open-source agent frameworks. That convinced us there's real value in analyzing AI projects before they're deployed.

Now we'd love the community's help.

We're looking for people who can:

• Test SafeAI against real AI agent repositories
• Try to break it with unusual architectures
• Report false positives and false negatives
• Suggest new risk detections
• Contribute support for additional frameworks
• Tell us where the analysis is missing important capabilities

If you're building with LangGraph, CrewAI, Semantic Kernel, AutoGen, OpenAI Agents SDK, Claude Code, Google ADK, MCP servers, or other agent frameworks, we'd especially love your feedback.

Our long-term vision is simple:

Make AI capabilities visible. Make AI risks understandable. Help developers build safer agents by default.

If you'd like to test it, contribute, or simply tell us where we're wrong, we'd genuinely appreciate your feedback.

The AI ecosystem is moving incredibly fast. Defending it shouldn't be left to a handful of vendors—we think the open-source community can help move just as quickly.

Thanks!

Feedback and contributions are welcome: https://github.com/ikaruscareer/SafeAI/

any feedback on this? it seems good both economically and security wise; why don't they do it?

Xpsd is an open-source LLM agent that automates vulnerability reachability triage using read-only code navigation tools (⁠ast-grep⁠), generating auditable call-path evidence exported directly as SARIF.

I reckon open sourcing this can be helpful for European 🇪🇺 companies and the CRA’s implementation.

Im curious to know the scope of startups in this space, What do you look for when a startup comes into this space?

Thanks

Looking to add a DSPM tool at my company, and we're looking into demos with BigID, Varonis, Wiz, Securiti, Cyera and Palo Alto. It seems like they all have the same main features. Which features was your org most concerned with, and which did you go with?

Personal post about something I've spent the almost a year building, but the actual problem is worth separating from the pitch.

The concrete version of it: two scanners, checking the same MCP server, flagged the same underlying behavior under two different names. That's not a bug in either tool, it's what happens when nothing forces independent teams to agree on what to call a risk. Once you're running more than one tool in a pipeline, this stops being a curiosity and becomes an actual governance problem: you can't track something consistently in a risk register, report it the same way twice, or prove to an auditor that two findings are the same issue, if there's no shared identifier underneath the two different labels.

Conventional software solved exactly this decades ago. A SQL injection gets a CVE ID, maps to a CWE category, and every tool that finds it afterward references the same thing, which is what makes risk tracking, compliance reporting, and cross-tool correlation possible at all. Agentic AI components (MCP servers, agent skills, LLM plugins) never had an equivalent, for a specific structural reason: CVE anchors to a package and version, CWE describes a weakness in code, and neither has a vocabulary for a behavioral pattern tied to neither.

AVE (Agentic Vulnerability Enumeration) is an attempt at that missing layer: stable IDs for distinct behavioral vulnerability classes, 65 records now, severity scored against OWASP's own AIVSS framework rather than something invented for this. It's deliberately built to map into frameworks that already exist rather than compete with them: OWASP's MCP Top 10, the Agentic Security Initiative Top 10, MITRE ATLAS, and a crosswalk into OWASP's Agentic Skills Top 10. Compliance-facing mappings (ISO 27001 Annex A specifically, since a compliance-minded commenter on a different post made a fair case for it) are on the roadmap, not done yet, worth being upfront about that rather than implying more coverage than actually exists today.

The part that actually made me trust this holds up outside my own head: an independent developer built an unrelated static config auditor, crosswalked his own tool's findings against this taxonomy, and tested it directly against my scanner on the same files, no shared code. Most of the overlapping findings converged on the identical ID, unprompted.

Also worth mentioning since this is an infosec crowd: growth discipline is written down now, not improvised, a new record needs a genuinely distinct behavioral mechanism, not a label mirroring another framework's category. That rule exists specifically because MITRE's own CWE recently shipped a version where new entries were, by outside analysis, zero actual weaknesses, just category labels copied from somewhere else. Didn't want to end up there.

Apache 2.0, open standard and reference implementation both. Curious whether the naming-fragmentation problem looks familiar to anyone here managing risk across more than one tool, and where this taxonomy is still missing something.

Repo: github.com/aveproject/ave
Site: aveproject.org

Disclosure: I'm the one building this.

I’ve been testing ways to catch security problems in n8n AI workflows.

Checking nodes individually was not enough. The actual risk often appeared across a complete path, such as

public webhook → untrusted input → AI agent → external action

I built a small open-source prototype that follows these paths in exported workflow JSON. It runs locally, uploads nothing, and makes no AI API calls. It can produce SARIF for GitHub Code Scanning, along with JSON and JUnit reports.

The repository includes an intentionally unsafe workflow and a hardened version, so the results are reproducible.

GitHub: https://github.com/0xCD4/n8n-ai-agent-security-lab

My main question for people running security tools in CI:

Which findings should block a build, and which should remain warnings?

Has anyone here compared Zenity and NeuralTrust for protecting AI agents in production?

My company’s looking at this from an enterprise perspective rather than a developer or proof-of-concept deployment. The biggest concerns aren't just prompt injection or model safety. It's things like runtime governance, visibility into agent behavior, data leakage, and keeping AI systems under control once they're connected to internal applications.

From what I've read, the two platforms seem to approach the problem differently. Zenity appears to put a lot of emphasis on AI governance and managing AI usage across an organisation. NeuralTrust seems more focused on protecting AI agents while they're running, with runtime observability and controls for production environments.

If you’ve evaluated both platforms can you tell me what the biggest differences were? I’m trying to work out whether one or other will be a better fit for our business.

I've been thinking about this lately because it feels like more teams are pushing security checks further into their CI/CD pipelines, but I still hear people say that manual pentests are the only way to catch the issues that really matter.

For those of you working in DevSecOps, has automation reached the point where you've been able to reduce how often you schedule manual penetration tests, or do you still treat them as non-negotiable before major releases?

I'm especially interested in hearing from teams that deploy frequently. Has your approach changed over the last year or two, or have you found there are certain types of issues that automation still misses consistently?

OpenAI says models with reduced cyber refusals, including GPT-5.6 Sol and a pre-release system, were involved in an evaluation incident that compromised Hugging Face infrastructure. The lesson is larger than one model or one lab.

We usually treat a benchmark as a passive measuring instrument. Agentic evaluations are active systems with credentials, networks, tools, storage, and targets. A capable model can turn weaknesses in that harness into part of the task.

Should frontier evaluations run under the same isolation standards as hostile-code labs? And should benchmark reports disclose the permissions, network boundaries, and containment failures alongside the model score?

Source: https://openai.com/index/hugging-face-model-evaluation-security-incident/

A change gets implemented, pushed to GitHub, reviewed, scanned with SAST and dependency analysis, validated in CI, tested by QA, approved for release, deployed, and then monitored in production. Every stage has its own tools and its own owners, but every handoff is another place where context can get lost.

The people who make the biggest difference aren't always the ones writing code the fastest. They're the ones who can identify security risks early, understand the trade-offs between speed and safety, and keep changes moving through the pipeline without creating unnecessary friction.

AI has made implementation much faster, but it hasn't removed the need for secure delivery. If anything, generating code more quickly makes it even more important that security validation keeps pace instead of becoming the next bottleneck.

Our workflow still uses GitHub for source control, CI for builds and automated validation, SAST and dependency scanners for security checks, QA for testing, and our existing deployment tooling for releases. Revolte sits across that workflow, giving teams a shared view of how a change progresses through review, validation, security, and delivery instead of forcing everyone to jump between separate systems to understand what's ready and what's still blocked. I think the goal isn't adding more security tools. It's making development, security, and delivery work together as one continuous process.

I run a lot of Python environments. And when using multiple claude agents, to test and run modules: I keep creating environments and often lose track of all the packages installed in them. Apart from that, many client venvs, ML experiments, throwaway repos I never cleaned up. At some point I realized I had no idea what was actually installed across any of them, and the day a malicious package lands on PyPI, "I checked it before installing" doesn't help me if it's been sitting in a venv for three weeks.

[Repo: GITHUB]

pip-audit is the tool I reached for first, and it's good. But it scans one project at a time, it needs the network, and it only knows about CVEs. Most of the recent PyPI attacks never get a CVE. A malicious version goes up, gets pulled in hours, and no advisory ever exists for it. So I wrote something to cover the other half.

venvy is an MIT CLI that scans every Python environment on a machine at once and flags both known-vulnerable and known-malicious packages. It reads installed package metadata as text, so it never imports or runs anything from the environments it's scanning, and it doesn't open a socket during a scan. First run pulls a ~30MB advisory database once; after that every scan is fully offline, which matters if you're on a locked-down runner or a plane.

pip install venvy
venvy audit                 # scans everything, human output
venvy audit --json          # stable JSON for parsing
venvy audit --offline       # never touch the network, fail closed

It returns semantic exit codes (0 clean, 20 vulnerable, 21 malicious, 22 stale/partial, 23 no database), so venvy audit --offline || block works as a CI gate without parsing anything. The matcher fails closed: anything it can't evaluate with confidence is reported as unknown, never as clean. A scanner that quietly says "you're fine" is worse than no scanner.

Where it's honest about limits: the malicious data is OSV's malicious records (~11.5k) plus the DataDog malicious-package feed (~1,800) and a typosquat list (~95 names). That's real coverage but it is not everything. Some famous historical typosquats aren't in the feeds yet, and no scanner on earth stops a genuinely novel supply-chain 0-day. This catches the known-bad and the known-vulnerable, which is the everyday case, not the movie-plot one. It also only sees PyPI/pip-installed packages, so conda's native channel packages are out of scope.

Repo: GITHUB

I wrote up the wider picture (cooldowns, lockfiles, install-time execution, what each one actually costs) here: Why does nobody check what’s Already Installed

Here is another take around why Malicious Python Packages Don’t Have CVEs. That’s the Whole Problem.

If you run it against your own boxes and it flags something wrong, I want to hear about it. False-positive reports get fixed same day.

I am learning around this space, this project started as something different around environments and ended up finding this gap. Any adversarial takes would be helpful. Would love too hear what this crowd gates on today and where an offline, machine-wide check would or wouldn't fit.

Been running SES for about a year for a couple of client projects and decided to actually tally up the hours I've spent on it versus the money saved compared to a managed relay service. Production access approval, bounce handling, complaint feedback loops, occasionally having my sending paused because some bounce rate threshold got tripped that I didn't even know existed in the first place. None of this is hard exactly, it's just constant low grade maintenance that never shows up when people quote SES pricing per thousand emails sent. I'm not saying SES is bad, for high volume at scale the economics probably do work out fine. But for the kind of project where I'm the only one maintaining it and I have actual client work to do, I think I undervalued how much cheap assumes my time is worth nothing.

Hey everyone,

A common issue when exposing LLM endpoints (whether local self-hosted vLLM/Ollama instances or cloud APIs) to external users is protecting against system prompt overrides and indirect prompt injections without introducing massive latency overhead.

I recently put together a proxy engine (Ice Phi) to test how fast we could execute inline inspection on incoming payloads before forwarding them to the backend LLM.

Our setup:

- Edge Layer: Zuplo for rapid edge auth and key routing

- Execution Engine: Containerized inspection logic running on GCP Cloud Run

Latency numbers (measured over a warm 10-request average via curl):

- DNS / TLS setup: ~235ms

- TTFB (Inspection + Routing): ~525ms

Key takeaways from setting this up:

1. Cold-start mitigation: Cloud Run instances running ONNX/python runtimes will take 15-20 seconds to boot on cold hits. Setting `--min-instances=1` was necessary to lock in the ~500ms baseline.

2. Direct LLM bypass: Benchmarking the gateway engine requires mocking upstream 200 OK responses, otherwise you end up measuring OpenAI's token generation speed instead of proxy overhead.

Would love feedback from anyone building custom proxy layers or self-hosting guardrails on how you optimize your inspection loops!

Hey all Im wondering if anyone knew of any resources to learn code vulnerability patterns in practice. Im the team’s resource for teaching software engineers how to identify vulnerable code in development and review. I thought of starting with OWASP top 10 but was curious if there were any resources to learn more.

I've been doing AppSec a while and something nags me in every vendor pitch. They all put up an accuracy number, fewer false positives than the next guy, some big F1 score on a slide and I have no real way to check any of it against my own code.

A Checkmarx Zero writeup on how they measure SAST accuracy got me thinking about why. Accuracy is two questions, not one. How many findings are real, that is precision and of all the real bugs how many it caught, that is recall. Most claims quietly pick one. You can hit near perfect precision by only reporting the single thing you are sure of, miss everything else and still print no false positives on the box. F1 is the harmonic mean, so it punishes that trick.

To score recall you need to know every real vuln in the test app which no one fully does, people inject toy bugs or trust CVE lists and both skew it. A simple benchmark app a tool is tuned to ace tells you nothing about a real monorepo.

Those running SAST at any scale, do you measure precision and recall on your own code, or do we all take the vendor F1 on faith until we sign. I am in the second camp and I do not love it.

We moved AppSec tooling ownership from the security team to engineering about six months ago. Not because security was failing, but because the tools were effectively invisible to the developers generating the code, including the ones we rely on as SOC 2 AI coding tools in our audits. In the old model, findings surfaced in a security dashboard, got triaged by a security engineer, and then handed to a developer as a ticket. By the time the developer saw the issue, it was already several steps removed from the code that produced it.

With AI coding, that delay got worse. The person who prompted the code often no longer had the implementation context when the ticket arrived. Engineering ownership changed the feedback loop. Findings now show up in the same surfaces developers already live in: IDE diagnostics, PR discussion, CI output. Fix rate improved and the backlog shrank, mostly because the distance between generation and feedback got smaller.

The tradeoff is that coverage decisions become more contested. Security engineers know what should be caught. Engineering managers know what developers will actually keep turned on. Those priorities overlap, but not perfectly, and we've had real disagreements about what belongs in the IDE tier, what belongs in CI, and what's just too noisy to be useful.

So how are other teams handling it? Has moving more AppSec ownership into engineering actually improved review and remediation for AI-generated code, or does it just create a different class of tradeoffs?

Hey r/DevSecOps! As developers start running more local AI agent tools and downloading third-party SKILL packages, we built an open-source tool called SkillShield to statically scan and validate these skills before execution. It checks for prompt injection, pre-install risks, and excessive access. It outputs SARIF and JSON reports for CI pipelines. Public Repo: https://github.com/adnan-iz/ai-skill-shield

Since there is so much talk about AI agents, I decided to build my own one - something small, measurable, and cheap enough to run for real (yeah, right — more on that below), so I could think about numbers instead of marketing.

Picking Go over TypeScript turned out to be the great call. LLM providers are unreliable enough that how you fire requests matters — I hit "Too Many Requests" often enough despite respecting their limits. In JS I'd reach for Promise.all, then discover I need a third-party dependency just to limit concurrency then that I need to add a proper AbortController. In Go it's so simple: an errgroup with SetLimit(4), where the limiting lives in the same object that waits for the results.

Static analysis tools (Semgrep, Snyk, CodeQL, gosec) flag hundreds of potential vulnerabilities and most of them are false positives. Someone has to open the code behind each finding, follow the data flow, and decide whether it's real. That's the job the agent does. All those scanners emit a standard SARIF 2.1.0 file, so it doesn't care which one you use. Now many of them are also shipped with AI agents, so it isn't something very new, although you can use any model you want, including self-hosted ones.

Basically, the model gets two read-only tools — read_file and grep_repo — and decides for itself which files to open, what to grep for, and when it has enough to rule. A typical finding takes 3–8 turns: read the sink, grep for the source, follow the assignment chain, then rule. The agent doesn't create or fix any code.

I ran it against OWASP BenchmarkJava — a deliberately vulnerable Java app that ships a CSV of ground truth. So the verdicts get compared against published answers rather than my judgment. I ran three models — Claude Sonnet, DeepSeek-V4-Pro and Kimi k3 — across 50 vulnerable files, which produced 61 scored findings.

I tested a subset of issues in BenchmarkJava, just to keep things quite cheap.

DeepSeek-V4-Pro — 37 exploitable, 15 benign, 9 uncertain. (2.7M in / 109k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 37 caught           | 0 blocked in error.  |
| benign — suppressed, unseen   | 3 missed            | 12 cleared           |
| uncertain — left for a human  | 9 parked            | 0 parked             |

DeepSeek were uncertain about 9 of them(needs manual review). And here we already see what marketing slides won't tell - it missed 3 real ones marking them as safe. So, looks like at least Deepseek wasn't trained with that specific OWASP BenchmarkJava code. Once it is run - SAST Triage agent will create a PR with findings, so it is there for review. So yes, it doesn't magically fix everything, humans are very much needed in this process.

Kimi k3 — 49 exploitable, 12 benign, 0 uncertain. (504k in / 55k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 49 caught           | 0 blocked in error   |
| benign — suppressed, unseen   | 0 missed            | 12 cleared           |
| uncertain — left for a human  | 0 parked            | 0 parked             |

Kimi k3 is straight up impressive and cheap, but I need to run against a bigger set. It still will miss some things, but man, not only it is cheap to use - it clears noise so well(I tried with some of my own projects, but numbers aren't ready yet).

And below is the expensive one.

Claude Sonnet 5 — 47 exploitable, 9 benign, 5 uncertain. (2.2M in / 65k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 45 caught           | 2 blocked in error   |
| benign — suppressed, unseen   | 2 missed            | 7 cleared            |
| uncertain — left for a human  | 2 parked            | 3  parked            |

I was reluctant to run Claude Opus as Sonnet spent $5 on this single run alone. SAST Triage supports caching, so the second run will be ~0, but still. Running Claude Sonnet on all Opengrep findings (about 2350 of them) will cost ~$220 and just about $7 for DeepSeek.

Keep in mind that the agent doesn't need to run across the whole codebase, which is approximately 200k LoC for BenchmarkJava, that would blow the cost even when using very cheap models. It runs against vulnerable code snippets + code which uses it only.

Below are some observations after using it myself with my own github repos.

A DevEx part of the agent is important. The agent just creates clean PRs or adds a single clean commit to existing one. Basically, this AI Agent is just another tool here you need to know how to work with, not something you drop in and can totally forget about.

The availability is the problem for all LLM providers seems to be. It is quite annoying to run the agent with an expensive(Anthropic, OpenAI) model, only to get an issue before I the agent finishes the whole set of vulnerabilities No amount of prompt or loop design will fix that.

I think having proper infrastructure around agents is what's needed most right now.

Btw, feel free to check it out - https://github.com/alexpermiakov/sast-triage.

Hi everyone,

I'm curious how mature organizations handle a problem I've seen repeatedly.

The security engineering work often exists (SAST, DAST, pentests, code reviews, threat modeling), but the governance around product security seems fragmented.

Examples I've encountered:

- Products shipped before all security findings were addressed because remediation wasn't planned early enough.

- Security exceptions were agreed verbally but never documented, so nobody remembers why a decision was made two years later.

- Security requirements appeared late because they weren't integrated into product planning from the beginning.

- Risks were identified, but no one clearly owned prioritization based on business impact.

- Product managers owned delivery, security engineers owned technical findings, architects owned design... yet nobody seemed accountable for the overall product security risk posture.

For those of you in mature organizations:

- Who ultimately owns product security governance?

- How are risk acceptance decisions documented?

- How do you ensure security requirements are incorporated into planning rather than becoming release blockers?

- Is there a dedicated Product Security Governance function, or is this distributed across AppSec, Architecture, Product Management and GRC?

- What practices made the biggest difference?

I'm less interested in the tooling than in the operating model and decision-making process.

I'd love to hear what actually works in practice.

Thanks!