Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

A quantification program with a dozen scenarios usually produces its annual figure by adding them together. Each scenario was modeled carefully, the arithmetic is simple, and the result is close to right for one of the two numbers the model produces. ‍ Summing scenarios treats them as independent, and cyber scenarios share dependencies. The consequence is specific rather than general, and it is worth being precise about because it determines which decisions the resulting figure can support. ‍

Guidance on agent governance concentrates almost entirely on what happens after deployment. Monitoring, sprawl, identity, attribution, retirement. The decision to put the agent into production in the first place gets treated as a software release, and software release processes ask none of the questions that matter for something which acts on its own. Agent governance generally assumes the agent is already running.

The standard method for sizing a cyber program from a loss curve has two halves. Set the retention where the balance sheet can absorb the loss, and set the limit at the one-in-hundred-year figure. The first half is sound. The second is a convention borrowed from property catastrophe practice, and the curve does not derive it. ‍ The distinction matters because organizations treat both numbers as outputs of the same model, then defend a limit the model never produced.

‍ An AI coding agent's own telemetry answers real questions well: which agents are running, what they invoked, the shape of a session, whether a run looks abnormal. It cannot, no matter how completely it is instrumented, stand alone as evidence. The agent under review is also the party writing the record. The record shows an attempt, not an outcome. And the vocabulary for describing any of it is still being written in public, one unstable commit at a time.

If you run a security team, a large part of the job is responding to change. Something in the environment moves, and you have to work out whether risk moved with it, and how quickly you need to act. Those changes arrive from two different directions, external and internal. Of course, we’re all familiar with the external ones. A new CVE drops, a proof of concept goes public, a ransomware group starts naming your sector. The internal ones start inside your own organization.

Originating in early 2023, Pikabot emerged as a significant malware loader. Over the past year, ThreatLabz has diligently monitored its development and operational methods. Notably, there was a surge in Pikabot’s usage in the latter part of 2023, attributed to a BlackBasta ransomware affiliate adopting Pikabot post the FBI-led Qakbot takedown. However, Pikabot’s activity ceased shortly after Christmas 2023, with version 1.1.19 marking its endpoint.

On August 28, 2026, ten malicious versions of @7nohe/openapi-react-query-codegen were published to npm between 20:00 and 20:21 UTC. The package generates React Query hooks from an OpenAPI schema and draws roughly 150,000 weekly downloads. The latest tag pointed at the malicious 3.0.4 for the duration of the window. Eight of the ten releases carry a multi-stage loader that reaches for cloud, registry, and developer credentials. The attacker needed no stolen npm token and no hijacked maintainer account.

A prompt injection test suite can only report on the payloads it contains. That sentence is the whole problem with the number most teams have. Somewhere in a ticket there is a scan result: a scanner threw several hundred probes at the endpoint and a percentage got through. The percentage is real.

Prompt injection has a CWE, and the two incidents everyone cites were not filed under it. That is not a clerical detail. A CWE ID is a claim about root cause, and every entry carries a mitigation table that follows from the root cause it names. When a record says CWE-1427, it is saying the product failed to neutralise input before building a prompt, and it is implying that neutralising the input is the fix.