Malicious Code Without a Vulnerability: The AppSec Blind Spot

Your pipeline is full of scanners. SAST reads the source, DAST hammers the running app, SCA checks the dependencies, and a secret scanner sits somewhere in the middle. On a busy week they'll hand you a few thousand findings.

None of them would have stopped the two breaches in this post.

That isn't a dig at the tools. It's how they're built. Every scanner in that list looks for one thing: a vulnerability, a weakness in the code. But some of the most expensive incidents of the last decade didn't involve a weakness at all. The code was clean. Someone just changed what it did.

The one-line change that walks past every scanner

Picture a payout service in a fintech backend. One line moves:

// src/main/java/az/paylink/core/settlement/PayoutService.java

// BEFORE - legitimate
ledger.sendTo(COMPANY_IBAN, amount);

// AFTER - one line, changed in a compromised or insider commit
ledger.sendTo("AZ21NABZ00000000ATTACKER0001", amount);

No SQL injection. No XSS. No buffer overflow, no CVE, no insecure call. The syntax is perfect and the data flow is clean. Even a focused penetration testing engagement might shrug at it, because nothing here is technically exploitable - the function just does what it now plainly says to do.

Run it past the stack and watch how quiet things get. SAST reads well-formed code with no tainted flow and moves on. DAST sees the app return 200 OK and the payment go through, so it's happy. SCA finds no vulnerable package, because this is your code, not a dependency. And code review only helps if the change actually went through review - which compromised accounts, direct pushes, and trusted insiders routinely skip.

Every vulnerability hunter in your pipeline is blind here for the same reason: there's no vulnerability to find. There's an unauthorized, malicious change. Those are not the same problem, and almost nobody scans for the second one.

This already happened: SushiSwap MISO (2021)

MISO - Minimal Initial SushiSwap Offering - was the token-launch platform built on SushiSwap, one of the biggest decentralized exchanges on Ethereum.

In September 2021 a contractor working on MISO, using the GitHub handle AristoK3, pushed a change into the platform's front-end code. It swapped the auction's payout wallet for the contractor's own Ethereum address. One NFT auction later, about 864.8 ETH - roughly $3 million at the time - had been redirected. SushiSwap's CTO, Joseph Delong, flagged the transaction publicly, and the funds came back after the developer was identified.

Look at what wasn't involved. No smart-contract exploit. No reentrancy bug. No CVE. Just a payout address, quietly changed in the app's own front end - the same one-line swap as the example above, except it happened for real, for $3 million, at the hands of someone with commit access.

It works from the outside, too: British Airways / Magecart (2018)

In 2018, attackers edited a JavaScript file that British Airways served from its own site. They added around 22 lines that read the card details a customer typed on the booking page and copied them to a domain the attackers controlled - while still passing everything to the real backend, so checkout looked completely normal.

Two things about that should bother any AppSec team. First, the mobile app pulled the same front-end script, so one code change hit web and mobile at once; a large share of the roughly 380,000 affected customers were on mobile. Second, there was nothing wrong with the JavaScript libraries involved - RiskIQ made that point clearly at the time. The code was clean. The added logic was the whole attack. BA later took a £20 million GDPR penalty for it.

Same shape as MISO: no CVE, no injection, no dependency to patch. A first-party change on the payment path that every vulnerability scanner would wave straight through.

Why this is a posture problem, not a scanner problem

You don't fix this by buying another scanner. Scanners answer "is this code vulnerable?" and here the honest answer is no. The question that actually protects you is a different one: did this sensitive code path change in a way that was authorized, from a source you expected, with behavior you expected?

That's an Application Security Posture Management (ASPM) question, and answering it takes three signals working together.

Sensitivity

Not all code carries the same risk. Payment and payout functions, checkout, wallet and IBAN handling, auth, crypto - that's what attackers actually turn into money. Defenzon tags those paths up front, so a change to processPayout never gets treated like a tweak to a stylesheet.

Provenance

A clean-looking diff still needs a story. Did it come through the normal PR and review flow? Is it tied to a ticket? Do the author and timing make sense? In both MISO and British Airways the malicious change skipped the usual path - a direct contractor commit in one case, an unreviewed production edit in the other. Provenance is where that stands out.

Behavior

This is the part passive tools can't touch. Defenzon re-runs the payment and checkout flow the way an attacker would, and watches what the code actually does now. If card data starts leaving for a domain nobody recognizes, or a payout lands somewhere off the allowlist, the behavior gives it away no matter how tidy the source looks.

Defenzon's Commit Review flags the tampered payout path as critical - sensitivity, provenance and behavior all firing - even though no scanner reports a vulnerability.

When all three line up - sensitive path, out-of-band change, changed behavior - you don't get one more low-confidence alert buried in a queue of ten thousand. You get proof: this payout path was tampered with, here's the evidence, here's who touched it and when.

The diff looks trivial and the syntax is clean, so scanners stay silent. Defenzon re-runs the payout flow and proves the money now goes somewhere it shouldn't.

The takeaway

Neither MISO nor British Airways was clever in the classic sense. No zero-day, no exotic exploit chain. The trick was staying inside the rules your scanners enforce - clean syntax, working app, no known CVE - while doing something obviously malicious.

As long as your DevSecOps program only asks "is this vulnerable?", that gap stays wide open. It doesn't matter whether the threat is an outsider who reached your front end or a developer who decided to help themselves. Closing it means watching posture, not just vulnerabilities: proving, on every change, that your most sensitive code paths move only in ways you authorized.

Alarm tells you something might be wrong. Proof tells you what happened. That's the line Defenzon is built on.

FAQ

Can SAST detect malicious code?

Usually not. SAST looks for vulnerabilities - insecure patterns, injection risks, tainted data flows. A deliberately malicious but syntactically clean change, like a swapped payout address, contains no vulnerability, so SAST has nothing to flag.

How is this different from a supply chain attack?

Supply chain attacks target third-party dependencies. The SushiSwap MISO and British Airways cases involved changes to the application's own first-party web and mobile code, which SCA and dependency scanning don't cover.

What is ASPM and how does it help here?

Application Security Posture Management correlates signals across the SDLC - code sensitivity, change provenance and runtime behavior - to judge whether a change is safe and authorized, not just whether it's technically vulnerable.

See how Defenzon turns findings into proof instead of noise.

Book a demo