20 posts tagged with "Research"

Apex looks enough like Java that it is easy to read it as Java. Security tooling does the same, and the places where Apex is not Java are where findings go missing. A scanner that matches Database.query( will not see DataBase.Query(. A reviewer who sees an access check at the top of a method tends to assume everything below it is covered.

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.

Every finding a scanner reports is a claim about your code. Some claims come with evidence: the scanner followed a value from the request, through two helpers, into a SQL string, and can show every step. Others are a pattern that looked suspicious. Others are questions the scanner raised but could not answer from the source at all.

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.

A JSON Web Token has three parts: a header, a set of claims and a signature. The claims are what the application wants to know (who the caller is, what roles they hold, when the token expires). The signature is the only part that makes those claims worth believing. Without it, a token is a base64 string anyone can write by hand.

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.

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

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

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

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

Knowing how to evaluate a SAST tool matters more than any feature list, because the demo is the worst evidence you will get. A vendor demo runs on code chosen to show findings, usually a deliberately vulnerable app the tool has seen many times. Your code is different: older, larger, built on frameworks the demo never touched, and full of safe code that looks risky.

The real cost of a static analysis tool is not the licence. It is the hours your engineers spend deciding whether each finding is real. A tool that reports more findings is not better if most of them are wrong. This checklist is built around that: measure precision first, on your code, and ask the questions that a findings count hides.

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

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

Open a public Experience Cloud page, a help centre or an application form, and watch the network tab. The page talks to Salesforce through one endpoint, /s/sfsites/aura, as the site's guest user. Nothing about that endpoint knows whether the request came from the site's own components or from a script. Whatever the guest user is allowed to read, anyone on the internet can read.

That is not a theory. In 2023 an independent researcher found hundreds of public Salesforce sites exposing records such as Social Security and bank account numbers to anonymous visitors. In March 2026 Salesforce warned customers that threat actors were mass-scanning public sites through that endpoint and extracting data, and said the cause was customer guest user configuration, not a platform flaw. This post walks the path a leak takes, hop by hop, and where each hop can be closed.

In 2025 a self-replicating worm showed the npm ecosystem what one stolen publish token could do. We covered that year in supply-chain attacks are a code problem. This post is about what came after: 2026 brought several more worms, and each wave changed the trick it used to run code during npm install.

The pattern held. A malicious version runs code at install time, harvests whatever credentials the machine holds, and uses any npm token it finds to publish poisoned versions of other packages. What changed was where the code hid and how the payload ran.

Below is what the primary write-ups and advisories say, the defences that slow these worms down, and where Vulkro fits. We are careful about that last part, because a scanner that reads code after it is installed is not a substitute for not running it.

A security scan finishes, prints zero findings and exits 0. The pipeline goes green and the pull request merges. Two very different situations produce exactly that output. In the first, the scanner read every file and found nothing worth reporting. In the second, it read a fraction of the project, found nothing in that fraction, and said nothing about the rest.

From the outside the two look identical. That is the problem. An empty result is only evidence of safety if you know what the scanner actually looked at, and most scan output does not say.

This is not a bug in any one tool. It is what happens when a scanner meets a language it does not support, a file it cannot parse, or an analysis pass that does not finish, and its output has nowhere to put that fact.

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

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

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

A security scan of a mature Salesforce org rarely comes back short. Hundreds of findings is normal: permissions that are broader than they need to be, Apex that runs without sharing, a session setting nobody has looked at since the org was created. Every one of them is technically true. Almost none of them tells you what to do on Monday morning.

The question a security team actually has is narrower: which of these lets someone reach data they should not?