Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Most vulnerability programs are built to act when risk looks obvious, such as when a vulnerability lands in CISA KEV, a public exploit emerges, or EPSS rises. This approach is rational because it provides a clear, defensible trigger for action. But it often comes with delay: by the time signals are strong enough to drive consensus, the window to get ahead of risk may already be closing.

It is 11:47 p.m. and the on-call security engineer is staring at two dashboards. On the left, LangSmith — the ML team’s debugging stack — showing the agent’s prompts, model responses, tool calls, and tokens consumed. On the right, the runtime detection console showing eBPF-captured syscalls, network connections, and process trees from the same Pod. Both are populated.

The external auditor’s evidence request lands Tuesday morning. A security architect at a Tier 1 bank pulls up her AI-SPM dashboard for the SOC2 Type 2 review. Eighty-three AI agents running across the bank’s clusters. For each one, the dashboard shows the current configuration and the current behavioral baseline. The data is accurate, comprehensive, and point-in-time.

On April 29, 2026, security researchers detailed a campaign known as ‘mini Shai-Hulud’ that involves compromised versions of npm packages used in SAP’s Cloud Application Programming Model (CAP). The malicious packages reportedly contain functionality to steal sensitive data such as credentials. The stolen data is encrypted and exfiltrated via public GitHub repositories. The maintainers of known-compromised packages have released updated versions.

As autonomous and semi-autonomous AI systems take on more responsibility within the enterprise, they shift from being “features” of software to becoming true internal actors. They make decisions, take actions, call tools, orchestrate workflows, and influence other AI agents. With this evolution, we must confront an uncomfortable truth: the metrics and response patterns we built for deterministic software no longer work.

In the fast-moving world of software supply chains, the discovery of a malicious version of a popular library often triggers a state of emergency. Traditional security tools take a reactive approach: they scan, they find a match, and they fail the build. But what happens if the malicious version was merged before it was flagged? What if it’s already running in your production containers? Or what if it’s being pulled dynamically across hundreds of different pipelines?

7 stolen GitHub tokens. 971 repositories. A self-replicating supply chain attack targeting SAP's Node.js packages — and it's still active. Here's what GitGuardian found.