13 posts tagged with "Developer workflow"

Almost every team that adds a security gate in CI does it the same way. Run the scanner on every pull request, fail the build on any High or Critical finding, and fix what it reports. The first run on a real codebase reports hundreds of findings that were there long before anyone opened this pull request. Every build is red. Within a few weeks someone adds || true and the gate is gone.

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?"

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

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

Most teams that care about security already run more than one tool. A query-based analyser in CI, a linter with security rules, a dependency checker, and lately an AI reviewer that comments on pull requests. Each one writes findings, and someone has to decide which of them are real.

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.

Every suggested fix makes two claims. The first is that it removes the problem. The second is that it does not add a new one. Most fixes, whether they come from a colleague, a linter or an AI assistant, arrive with neither claim checked. Someone reads the diff, it looks reasonable, and it is merged.

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.

Salesforce DevSecOps has a problem that application teams do not: half of what decides your security never passes through the pipeline. Apex, Lightning components and Flows live in a repository and can be scanned like any other code. But a profile edited in Setup, a connected app approved for a vendor, or a guest user given one more object never becomes a commit. A pipeline that only scans pull requests sees the code and misses the org.

So a working Salesforce security pipeline has two halves. One runs on every change, from the developer's laptop to the merge. The other runs on a schedule against the live org, because the org changes whether or not anyone deploys.

Air-gapped SAST sounds simple: run the static analysis on a machine with no network. In practice, many tools that run locally still expect the internet somewhere. A licence check calls home, a dependency lookup goes to a public API, an explanation is fetched from a hosted model. On a classified or regulated network, any of those calls stops the tool from being approved.

The code that most needs review often sits on exactly those networks: defence programmes, government systems, payment and core banking platforms. This post sets out what offline scanning actually requires, how to keep vulnerability data current across the gap, and how Vulkro's command-line tools handle each part.

An AI coding agent adds a tenantId parameter to findById, updates the two call sites in the file it was looking at, writes a cheerful summary and stops. There were five call sites. The other three are in files it never opened, they still pass one argument, and in a dynamically typed codebase nothing will complain until a request reaches one of them in production.

This is the most ordinary way an agent's edit goes wrong. Not a subtle logic error, not a security hole: a change whose consequences live somewhere the agent did not look. People make the same mistake, but people tend to make small changes and run the build. Agents make wide changes quickly and often declare victory before anything has been run.

Watch an AI coding agent fix a small bug. It searches for the function name and gets forty matches across comments, tests and unrelated files. It opens the file with the best-looking match and reads all 900 lines. It searches again for the callers, opens three more files, and reads those whole as well. The fix it finally makes is four lines.

Every one of those reads stays in the conversation, and the conversation is sent again on every turn. The agent was not careless. It used the tools it had, cat, grep and sed, and none of them can answer the question it was really asking: show me this function, and who calls it.

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

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

Secrets in git history are one of the most common leaks in software, and one of the most misunderstood. Someone commits an API key, notices a few minutes later, deletes the line and commits again. The working tree is clean. The key is still in the repository, in every clone made since, in every fork, and in any CI cache that fetched it.

The scale is not small. Researchers at North Carolina State University scanned public GitHub commits in near real time for almost six months and found secret leakage affecting over 100,000 repositories, with thousands of new, unique secrets leaked every day (Meli, McNiece and Reaves, NDSS 2019). This post covers why deletion does not help, what to do first, when rewriting history is worth the cost, and how to stop the next one.

A penetration test report arrives with an injection at src/routes/users.js:42. The security scanner has run on every pull request for a year and never mentioned that line. The first question in the room is the obvious one: why did it not flag this?

Usually nobody can answer. Maybe the scanner never read the file. Maybe it read it and decided the input was sanitised. Maybe it found the bug, rated it below the default view, and it has been sitting one flag away the whole time. Maybe someone suppressed it eight months ago. Each of these calls for a different response, and without an answer the team guesses, loses some trust in the tool, and moves on.

Vulkro has a command for that question. vulkro why-not <path[:line]> explains why nothing was reported at a location. This post covers why silence needs explaining, what the command can tell you, and where its answers stop.

Most Salesforce security feedback reaches a developer at the worst possible moment. It arrives in a review comment two days after the pull request was opened, in a scan report nobody owns, or in a rejection letter from the AgentExchange (formerly AppExchange) Security Review weeks after the class was written. By then the developer is three tickets further on, the context is gone, and a one-line fix has become a small project.

The cheapest moment to fix a missing field-level check is the moment the query is on the screen. That is an argument for putting security analysis in the editor. It is also a list of things the editor version has to get right, or developers will turn it off within a week.