30 posts tagged with "Application security"

PCI DSS 4.0 requirement 6 is the part of the card industry standard written for the people who build software. If your application stores, processes or transmits cardholder data, or can affect the security of the systems that do, your assessor will ask how its code is reviewed, how it is protected against common attacks and what third-party components it contains. They will want evidence for each answer, not a policy that says it happens.

This post walks through the parts of requirement 6 that land on engineering teams (6.2.3 code review, 6.2.4 attack prevention and 6.3.2 the software inventory), what automated code scanning can contribute to each, and where it stops. It ends with the evidence Vulkro Core produces against the PCI DSS 4.0 requirements it maps.

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.

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.

Apex SOQL injection happens when a value the caller controls is pasted into a query string and the string is run with Database.query. The caller can then change what the query means: widen a filter, drop a condition, or sort and page through records the code never meant to return. SOQL cannot delete or update data the way SQL injection can, but reading the wrong records is usually the whole breach.

It is also one of the oldest findings in Salesforce security reviews, and it keeps coming back because dynamic queries are genuinely useful. Search screens, list views with a sort column, filter builders and admin tools all assemble queries at runtime.

This post shows the common vulnerable shapes, the fix for each (static queries, bind variables, Database.queryWithBinds, and allowlisting names through Schema describe), where String.escapeSingleQuotes stops helping, and how Vulkro for Salesforce traces the flow from the caller to the query.

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

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

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

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

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