10 posts tagged with "Application security"

The most damaging bug in web software is also the least interesting to describe. A request asks for record 1041. The server checks that you are logged in, loads record 1041 and returns it. It never asks whether record 1041 is yours. Change the number and you get your neighbour's.

That is broken object-level authorization, also called an insecure direct object reference or IDOR. The OWASP Top 10:2025 keeps broken access control at number one, and says that "100% of the applications tested were found to have some form of broken access control." Among the weaknesses it maps there is CWE-639, authorization bypass through a user-controlled key: the changed number.

"Paste the repo into the model and ask it to find the security bugs" has become a common first attempt at AI-assisted security review. It is easy to try, and the first run is often impressive: the model names a plausible injection, explains it well, and suggests a fix.

The trouble starts on the second run. And the third. And when somebody asks what it did not look at.

An advisory lands for a library inside a product you sell. By lunchtime there are reports that it is being exploited. Until this autumn, the next question was a business one: how fast do we patch? Since 11 September 2026, if that product is sold in the EU, there is a legal one first. The Cyber Resilience Act gives the manufacturer 24 hours from becoming aware of an actively exploited vulnerability to send an early warning to its national CSIRT and to ENISA, 72 hours to send the full notification, and a fixed window for the final report.

The report itself is short. Answering it is not, unless you already know what is in every version you ship and whether the vulnerable code can be reached. This post covers what the regulation asks of software teams, which dates matter, and what evidence to have on disk before you need it.

This is a plain-language summary of EU law for software teams, not legal advice: check the official text and your counsel before you rely on it.

An MCP server is a program your AI assistant starts on your machine, with your environment, your files and whatever tokens you put in its config. It is installed by name, often re-downloaded on every launch, and its tool descriptions are read by a model that does what text tells it to. In most teams nobody reviewed any of that. It was one line in a JSON file, pasted from a README.

In 2025 attackers noticed. Each of the incidents below is public, each one is small, and together they describe the whole surface: the package, the transport, the tool and the agent's own reach.

A Salesforce org rarely stands alone. Around it there is usually a small fleet of services nobody thinks of as "the Salesforce project": a Node service that receives webhooks and writes them into the org, a Python job that copies records into a warehouse, a Go API behind the customer portal, a Java service that holds the integration credentials. They are written by different teams, deployed by different pipelines and reviewed, if at all, by different tools.

An attacker does not see that boundary. If the first hop of the path is a route in the Node service and the last hop is a field in the org, a review that looks at only one side sees half a path and calls it two unrelated medium findings.

An AI coding agent can write a new endpoint, its handler and its database query in the time it takes to read this paragraph. It will compile. It will probably pass the tests it wrote for it. Whether it checks that the caller owns the record it returns is a separate question, and nobody asked it.

That gap is the security problem with AI coding agents. Not that they write worse code than people, but that they write a lot of it, quickly, and the review that used to happen while a person typed it no longer happens at all.

Ask an AI coding agent to "check this repository for security issues" and watch what it does. It lists the tree. It opens the route files, then the middleware, then the database layer, then a few helpers it was not sure about. Each file goes into its context window. By the time it has an opinion about one endpoint, it has paid to read forty files that had nothing to say.

That is not a flaw in the agent. It is the only way a model can look for a vulnerability on its own: by reading. And reading a codebase is the most expensive thing you can ask a model to do.

Supply-chain security is usually sold as a list problem: keep an inventory of your packages, match it against a vulnerability feed, patch what turns up. That works for the bug a maintainer shipped by accident. It did very little for the attacks of 2025, because in almost every one the malicious version was installed and running before any feed knew it existed.

The 2025 compromises were not vulnerabilities. They were programs. Each one read a credential, called a network endpoint, ran a shell command or republished itself, and each of those is a shape you can read in code without waiting for anyone to publish an advisory.

Most of the attacks that made the news in 2025 did not need anything clever. A package version that should not have been installed. An install script that read a token and sent it somewhere. An API that returned whichever record you asked for. A prompt template that read a field anyone on the internet could write. Each one ended in a headline, and each one started as a line of code or configuration that a check could have pointed at.

This post goes through twelve of them, from late 2024 to early 2026. For each: what happened, as the public source describes it, the weakness underneath, and the Vulkro check that flags that weakness. Every check id below is in the shipped catalogue, and the core of each mapping was run against a small reproduction of the weakness before it was written down.

For most of the last decade, a security scanner was something a software team adopted when it had the time, the budget or a nervous customer. Testing was good practice. Writing down the results was better practice. Neither was something a regulator, a court or a board could reliably hold you to.

That has changed, and 2026 is the year it became hard to ignore. Six EU laws now reach software teams, from the GDPR baseline to the new Cyber Resilience Act, and read side by side they share one demand: not that you are secure, which no law can define, but that you can show, at any moment, what you tested, what you found and what you did about it.

This is a plain-language summary of EU law for software teams, not legal advice: check the official text and your counsel before you rely on it.