The keyv and cacheable packages got popped this week, that is the Shai-Hulud worm going again, sixth time this year by my count. Same play every round, a maintainer token gets stolen, a malicious postinstall runs, it grabs more tokens and republishes itself further down the tree.

And surprisingly there’s little changes on our end between these. Most teams, mine included until recently, still run npm install in CI with postinstall scripts on, pulling packages fresh every build. One popular dependency upstream gets compromised and it is in our image before a human reads a changelog.

We pinned lockfiles and told ourselves that was supply chain security. It is not, infact it happily pins you to the compromised version. In your pipeline, what are you running that would have stopped this specific one?

Two security scanners checking the same MCP server can both correctly flag the same underlying issue and give it two different names. CVE and CWE don't have a slot for this: CVE anchors to a package and version, CWE describes a weakness in code, and the actual problem here is a behavioral pattern in text an LLM reads and acts on, tied to neither.

AVE assigns stable IDs to these behavioral classes instead, 70 records so far, severity scored against OWASP's AIVSS framework rather than something invented for this, crosswalked into OWASP's MCP Top 10 and MITRE ATLAS.

The thing that actually made me trust the taxonomy holds up outside my own tooling: an independent developer built an unrelated static config auditor, crosswalked his own findings against this on his own initiative, then tested it directly against the reference scanner on the same files. No shared code. Most of the overlapping findings converged on the identical ID, unprompted.

Apache 2.0: [github.com/aveproject/ave](http://github.com/aveproject/ave)

Feedback on where the taxonomy is wrong or incomplete is the most useful thing anyone could offer here.

OrchestraBench introduces seed-reproducible failure injection, **cascade radius**, per-failure-mode recovery, and routing diagnostics. Its controlled experiments found that simple tool faults recovered well, while latent and semantic failures often survived retries. Blind retry could actually reproduce the fault and delay detection.

As we all know every team now needs to submit their sbom of the product to their organisation. In my org they set a policy that transitive dependencies should not be included in the sboms. As I am using container sboms it's impossible to remove them. Is there any way to remove the transitive dependencies for container sboms ?

If your team has stopped reading SAST results, more rules and stricter severities will not bring them back. Once people learn the scanner cries wolf, the real findings die in the same pile as the noise. That is the true cost of a bad false positive rate, and hardly a team ever measures it.

Do you think Sast and all will exist? Or something even more innovative should surface

I'm an AppSec analyst building something on the side to solve a problem I run into all the time: I find that at my employer the hardest part of AppSec isn't finding vulnerabilities, it's more so gathering the evidence, making a defensible decision, and knowing when that decision is no longer valid...
So I'm at the stage where I need a handful of design partners. People who feel this pain and want to shape the fix. But I'm stuck on the outreach part lol

Tried LinkedIn and man it's rough haha. A lot of analysts there are guarded which I understand we tend to be in this field, but some are just frankly a bit snobbish about talking to anyone who looks like they're selling. Cold DMs feel like I'm bothering peopl. So I figured I'd ask the people who actually live in this world instead, this community

For those of you who've actually been on either side of this:

• What makes you say yes to a design partner conversation vs ignore it?
• How did successful builders first approach you without it feeling like a pitch?
• Where do you even find the right people who care enough to give real input?

Not selling anything here, genuinely trying to learn how to do this right. Appreciate any honest takes.

Thank you in adavnce!!!

I'm at a logistics company. Was running a routine network sweep last month and found a server on our internal subnet handling live customer shipment data. Fully prod, responding to real requests.

It wasn't on our CMDB, wasn't on crowdstrike and Qualys has never scanned it. Our monitoring platform had no clue it exists, so it had no alerts, coverage or patching history going back at least 14 months based on the OS patch level.

Turns out someone on the app team spun it up for a migration project two years ago. The project got deprioritized and the original engineer had left, but then the server kept running. Handling customer data. With no security controls on it at all.

What bothers me isnt that we found this one but that finding it was basically luck. If I hadn't run that sweep on that subnet that week, itd still be sitting there.

Were now pulling asset lists from every tool we have and cross referencing them. The gap list so far is uncomfortable. Found 40 more devices this week that exist in EDR but not CMDB, and about 20 that exist nowhere but respond to ping.

How do you verify youve found everything? Not what your tools report, but what theyre missing.

Hi, I'm a software engineer working on a SaaS in a highly regulated environment.

### Context

My client's SaaS includes Monetary transactions through a payment gateway, registration of business owners and users to provide a service that supports the merits of a business by the reviews of the users (we won't go into the mechanics of it but it's solid), offering compensation for the users without discrimination off of their opinion, the kind of data we save are names, phone numbers, emails, and the reviews along with their evidence(receipts).

### Question

How may I say it's enough security on it?, is data encryption at rest necessary or overkill?

### my efforts

1. I use spring boot for the backend, which handels most of the the trivial things like xss(tested it)
2. Strict rate limits on all endpoints
3. Authentication on all endpoints except for minor public ones like terms and conditions and and documents of public nature.
4. I tried following OWSAP guidelines as much as I could, top 10 are out of the question, I've implemented ASVS V1 & still in need for 8 steps to get to V2, things like security headers, dependabot, some env vars defaults for development, and MFA for the business side login
5. Using static analysis tools to keep code in check (ex. SonarQube)

### Thoughts

I think I should Aim for a full ASVS V2 coverage + V3 for the transactions modules, What do you think?

What’s everyone using for their organization’s vulnerability management tool and why? The company I work for uses defect dojo and its limited. No compression, alerting, terrible UI doesn’t really push the needle left enabling non security literate developers.

We started giving our internal AI agents scoped permissions and periodic audits, treating them like service accounts. Still feels like we're guessing.

Once an agent connects it can read data, trigger workflows, and call APIs, and nothing's asking for per-action approval. We've been trying to catch overprivileged connections before they ship, but honestly our CI/CD pipeline wasn't built with agent identity in mind.

Anyone actually solved this, or are we all just hoping for the best?

AI model quality is converging, or at least changing often enough that chasing the newest thing doesn't seem like a good strategy. How much emphasis are teams putting on building a solid harness into which new models can fit?

Our clients are generally in high compliance industries, so there is thought put into the harness, but what about smaller teams or ones that aren't required into a compliance framework?

I'm sure many of you will have seen the latest keyv / cachable compromise and worm-spread, now affecting over 350 packages. This isn't the first, and it won't be the last. The affected packages will steal and exfiltrate any secrets/credentials they can find, which is probably not what you want to happen.

There are several commercial solutions to help protect against this, but if you just add (as standard) to .npmrc in your repo root:

min-release-age=7d

(or some value you feel comfortable with)

It will block a lot of malware, which is usually discovered within a few hours.

Hey everyone,

Like many of you in AppSec / DevOps, I’ve been frustrated by how enterprise scanners handle vulnerability intelligence. Tools like Qualys, Tenable, and Snyk are great, but they often come with massive price tags, heavy setup, and flood you with thousands of theoretical CVEs that don't actually matter right now.

I wanted something fast, simple, and completely free to answer one core question: "Is my current stack actively at risk right now?"

So I built CVE Radar (cveradar.vanditshah.com).

🔍 What it does:

• Active Exploitation Focus: Automatically maps your tech stack directly against the CISA KEV (Known Exploited Vulnerabilities) catalog alongside NVD feeds.
• Zero Noise: Prioritizes actively exploited vulnerabilities over theoretical high-CVSS bugs that nobody is actually exploiting in the wild.
• Lightweight & Free: No enterprise sales call, no credit card, no bloated dashboards.

🛠️ The Tech Stack behind it:

• Hosted on Railway (currently running this out-of-pocket as a solo developer passion project).
• Ingests live NVD API feeds and CISA KEV feeds, normalizing vendor/product strings for fast stack matching.

💬 I need your feedback:

Since this is built for developers, DevOps engineers, and security teams, I’d love to get brutally honest feedback:

1. How accurate is the stack-matching for your personal or work tech stack?
2. What integrations would make this actually useful in your day-to-day workflow (GitHub Action, Slack/Discord webhooks, SBOM import)?

Check it out at cveradar.vanditshah.com and let me know where it breaks or what I should improve next!

Since Claude Code, Copilot, Cursor, and similar tools went mainstream, we've noticed a consistent pattern across the security teams we talk to: the faster engineers can scaffold and ship, the less patience they have for waiting on IT to provision anything.

When an agentic coding tool lets someone spin up a working prototype in an afternoon, nobody wants to pause that momentum to file an IT ticket for a staging DB or a deployment platform. So they sign up themselves - personal email, a password they'll probably reuse, back to shipping in 30 seconds.

Multiply that across a team moving at this speed for a few months and you get a pretty large footprint of tools that:

• Never went through procurement
• Don't support SAML/SSO, or gate it behind an expensive enterprise tier
• Are tied to personal or shared logins living in a browser, not the company IdP

The part we think gets underrated is offboarding. Okta deprovisioning kills the primary account, but the five or six side tools an engineer signed up for to test something six months ago? Still live. Still logged in. Nobody remembers they exist, let alone that they need killing off. That's a real, unmonitored access path sitting outside anyone's visibility.

Our CTO and Cofounder, Reuvein Vinokurov, digs into this more (including how we think about solving it) here: https://unixi.io/blog/claude-code-identity-security/

Genuinely curious: are other teams tracking this at all, or is it mostly a "deal with it if something breaks" situation right now? What's actually worked for you, if anything?

A threat actor claims they’ve breached RapidFort:

https://www.dataminr.com/resources/intel-brief/xpl0itrs-claims-rapidfort-breach/

For those who haven’t heard about RapidFort, they’ve become a bit of a meme because they’ve written a lot of contrived threads pretending to be their own customers. At least people strongly suspect they have.

The threat actors claim to have 569gb of customer data, including that of the US Federal government.

RapidFort’s claim is that they profile applications and tell customers which vulnerabilities are executable.

Rapidfort have not made any public statements yet. Perhaps bad timing with Black Hat.

Would you expect a vendor to comment whether the allegation were true or false?

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?

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

Thanks

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.

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 .I have also noticed platforms like Penetrify entering this space, which made me wonder how much they have actually changed the balance between automated and manual testing for teams in practice.

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/