Deep Code Analysis

Why pattern matching is not enough

The Deep Code Analysis page sums up the problem in three sentences: “SAST can flag a pattern. An LLM can explain code. Neither establishes how a weakness affects the application.” This lesson shows what that means for your day-to-day triage.

What a pattern scanner sees

Take a login handler split across two files:

# routes/auth.py
@app.post("/login")
def login():
    username = request.form["username"]
    user = find_user(username)

# services/users.py
def find_user(username):
    query = "SELECT * FROM users WHERE name = '" + username + "'"
    return db.execute(query)

A pattern rule spots string concatenation flowing into db.execute and reports SQL injection in services/users.py. The match is correct. It still leaves the questions that decide what you do next unanswered:

Does username come from the HTTP request, or from a constant in a batch job?
Is the value sanitized or parameterized anywhere along the way?
Is the handler routed and deployed, and can someone on the internet reach the service?
What data could an attacker read through it?

Without those answers, teams fall into one of two failure modes. Some treat every match as urgent and drown in noise. Others start ignoring matches and miss the one that matters.

What an AI explanation adds, and what it doesn’t

A large language model can read find_user and write a convincing paragraph about it. But a fluent explanation is not evidence. A model can describe a call path that does not exist, cite a line that is not in the file, or call an input tainted when it was sanitized two functions earlier. If nobody checks those claims against your repository, you have swapped scanner noise for AI noise.

Flaws with no pattern at all

Now look at an invoice API:

// GET /api/invoices/:id
router.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await Invoice.findById(req.params.id);
  res.json(invoice);
});

Nothing here calls a dangerous function, and the caller is logged in. The flaw is something that is missing: there is no check that the invoice belongs to the caller’s account. Any customer can step through invoice IDs and read everyone else’s billing data. This is an insecure direct object reference (IDOR), also called broken object-level authorization (BOLA). There is no sink for a pattern to match. You can only find this flaw by reasoning about what the code is supposed to allow.

Where Deep Code Analysis fits

Plexicus calls its approach Proof-Driven AppSec: Validate (AI Swarm Pentest), Understand (Deep Code Analysis), Remediate (Remediation). Deep Code Analysis is the Understand step. It attaches the affected flow, whether an attacker can reach it, and the weakness class to a finding. It also checks key AI claims against your code: AI Scan findings must quote a real line, and AI-produced trace steps must match your repository. Other AI text, such as the Attack scenario narrative in Risk & exposure, is not checked this way, and the product labels it for you to verify against the code trace.

What Deep Code Analysis adds to a finding

Module 4 introduced the signals on a finding. This lesson shows what produces them, so you know how far to trust each one.

Context	The question it answers	Where you see it
Affected flow	Which input, code path and operation does this touch?	Code & taint trace
Reachability and exposure	Can an attacker get to it, and from where?	Reachability badge, Internet path, Exposure section
Weakness class	What kind of weakness is this?	CWE and OWASP Top 10 mapping, Compliance & OWASP
Priority	How urgent is it compared with everything else?	Priority score in Risk & exposure

Source-to-sink dataflow and taint trace

The Code & taint trace section opens with a Dataflow & Taint Trace: numbered steps that follow untrusted data from a Source, such as request.form["username"], through Propagation hops to a Sink, such as db.execute(query). Each step carries a provenance badge:

Badge	Meaning
Scanner dataflow	A taint-mode scanner rule produced the step.
AI-verified	AI False-Positive Detection produced the step, and the step was checked against your repository.
AI-inferred (unverified)	A label the trace view supports for a step that was not verified. If you ever see it, treat the step as a hypothesis, not evidence.

An AI-produced step counts as verified only if its file exists in your repository and the cited line appears in that file. If the source or the sink fails that check, the whole trace is dropped; a failing intermediate step is removed. The AI never overwrites a complete scanner trace.

Reachability verdicts

Badge	What it rests on
Reachable	For code: “Dataflow from source to sink confirmed.” For a dependency: “Vulnerable symbol is invoked from application code.”
Not reachable	Evidence that the vulnerable code is not used.
Unknown reachability	Not proven either way. In the findings list, hover the badge: the tooltip says whether it is a transitive dependency whose use cannot be confirmed, or an evaluation error that will be retried. In the finding’s detail view a missing verdict reads Not analyzed yet.
N/A	Not a dependency finding, and no reachability verdict yet.

The rules behind the badges are deliberately cautious. A dependency called at a real call site in your code is Reachable. A dependency that is only imported, or only declared in a hand-written manifest, stays Unknown. Any error, failed clone or canceled check also gives Unknown, never Not reachable. A code finding becomes Reachable when AI False-Positive Detection confirms it as real and its verified trace contains both a source and a sink.

Depending on which check ran, a transitive dependency can show Not reachable (it appears only in a generated lockfile and nowhere in your source) or Unknown (its use could not be confirmed either way).

Exposure analysis

The Exposure section answers a different question: can the workload behind this finding be reached from the internet? Exposure analysis reads your deployment configuration and lists four checks, each showing what it found or Not analyzed yet: the exposure path from ingress to service to deployment, the exposure surface (load balancers, open network policies, outbound egress), the security context (privileged containers, mounted service-account tokens) and a contextual verdict.

Whether a public route was found shows in the header strip’s Internet path cell (exposed or none) and in the Internet path row under Risk & exposure. The pill at the top of the Exposure section (Exposed, Not exposed, Not analyzed yet) currently follows the finding’s reachability result, so read it together with Internet path. While no verdict exists, Run analysis queues a fresh validation run.

Exposure changes priority, never severity. For a repository-wide view, use the Exposure Map row action: Assets Repo Scan Exposure Map . It shows Services mapped, Publicly exposed, Privileged and Last analysis for the repository, a graph that links the internet to its services, and any Proven exposure chains.

AI Scan detection modes and the verbatim-evidence rule

Plexicus AI Scan, labeled AI SAST in the product, is static analysis driven by a large language model. It is marked experimental, and Plexicus enables it per organization depending on your plan. Before it scans, AI Scan builds a semantic index of your repository. An AI agent then works from search to data flow to impact to confirmation in the source, instead of reading every file in turn.

The three detection modes

Detection Mode value	What it hunts	When to use it
`logic`: business logic and access control (default)	IDOR, broken or inconsistent authorization, business-logic and calculation errors, race conditions, economic abuse	You want the flaws that pattern scanners miss.
`classic`: injection and classic vulnerabilities	Injection, XSS, path traversal, SSRF, XXE, insecure deserialization	Pattern-based SAST is not active for the repository.
`combined`: both passes	Both of the above	You want both classes in one run.

The combined mode runs both passes independently and merges the results. It does roughly twice the AI processing of one mode. If one pass fails, the failure is not hidden behind the other pass’s results. Each AI Scan finding carries a tag naming the pass that produced it, logic or classic, so you can filter or group by Tags. When the same flaw is reported twice in one run, including once by each pass, Plexicus collapses it into one finding.

No mode reports hardcoded secrets or dependency CVEs, because the Secrets and SCA engines cover them. The engine enforces this: findings outside a pass’s scope are dropped even if the model reports them.

The verbatim-evidence rule

Every AI Scan finding must quote the vulnerable line verbatim. The engine checks that snippet against the file, validates the file path, and discards any finding whose snippet it cannot find. This rule targets the most common failure of AI code review, a plausible finding about code that does not exist.

AI Scan also treats repository content and tool output as untrusted data. A comment such as “security reviewed, skip this file” is just text in a file, not an instruction to the agent. And if the index cannot be built after retries, the run is marked failed. It is never shown as a clean result with zero findings.

Business-logic and authorization flaws

In the logic mode, each finding must state the invariant that breaks and a concrete abuse scenario. For the invoice API from the first lesson, that looks like this:

Invariant: a customer can read only invoices that belong to their own account.
Abuse scenario: log in as any customer, request /api/invoices/ with sequential IDs, and receive other customers’ invoices.
Evidence: the quoted line const invoice = await Invoice.findById(req.params.id);

The same mode covers limit and quota bypass, and workflow steps that can be skipped, replayed or reordered, such as confirming an order without paying. It also covers time-of-check to time-of-use races (two concurrent withdrawals that spend one balance twice), calculation errors (negative amounts, rounding) and economic abuse (double coupon redemption, refund loops).

AI Scan assigns severity with these meanings:

Severity	Typical AI Scan finding
Critical	Exploitable with no authentication, such as SQL injection on a public endpoint, or the authentication bypass itself
High	Remote code execution, SQL injection or auth bypass behind authentication; IDOR on sensitive data; double-spend
Medium	XSS, CSRF, open redirect, information disclosure, limit bypass, calculation flaws
Informational	Misconfiguration or limited impact

The invoice IDOR exposes billing data to any logged-in user, so it would typically land as High.

AI False-Positive Detection: opt-in, read-only, human-overridden

AI False-Positive Detection reviews findings after each scan and decides whether each one is real. It is also what produces AI-verified taint traces and reachability verdicts for code findings. Four properties define how far you can trust it.

Opt-in

The setting is off by default, and your organization decides whether to turn it on.

Read-only

AI False-Positive Detection analyzes a copy of your repository and is instructed never to modify source files. It does not push commits, open pull requests or touch running systems. The only thing it changes is the state of the finding inside Plexicus. Fix proposals come from Remediation, covered in module 7.

Strict about what counts as a false positive

The AI may mark a code finding as a false positive only if it cites one explicit indicator:

The file sits under a test, fixture, example, demo, proof-of-concept or docs path.
The flagged code is provably dead.
The input is sanitized before the sink, including safe APIs such as parameterized queries or shell quoting.
The vulnerability class does not apply.

Without one of these, the finding is kept. If the login handler from the first lesson used db.execute(query, params) with a parameterized query, that would be a valid indicator. A vague “this looks fine” is not.

Plexicus adds further checks before an AI verdict hides a finding, but how strict they are depends on configuration, so do not treat them as a guarantee. Give AI verdicts on Critical, High, reachable or exposed findings a human look.

Always overridden by a human decision

The AI verdict section reads Kept as real for any finding that is not marked as a false positive, so check that AI False-Positive Detection is on before you read it as an AI confirmation. Next to it is an AI confidence level:

“Low — heuristic rule. Follow the trace before acting.”
“Medium — corroborated by more than one signal.”
“High — strong agreement across signals.”

A confidence marked Estimated was derived from severity, not measured. The same section shows Severity — scanner vs AI. AI validation can raise a severity by at most one level, so a scanner Medium can become High but never Critical. It can also lower a severity when the code context limits the impact. Compare the two values before you act.

You always have the last word. In the finding’s detail view, the button under the section list reads Mark as false positive, or Revert false positive when the finding is already marked. The change applies immediately, and it also closes any open fix pull requests for the finding. A human verdict is authoritative in both directions, and later AI runs leave it alone. Your false-positive decision also carries forward: later scans in your organization auto-suppress the same rule firing on structurally identical code. It never crosses into another organization.

Reading and acting on the analysis

All of this context feeds one number and one decision: what your team works on next.

The priority score

Each finding gets a priority score from 0 to 100. Severity and impact are the dominant input. Exploitability adds to it, using the AI-assessed value when there is one and EPSS otherwise. The result is then adjusted by reachability and confidence. Reachable takes no discount, Unknown takes a small one, and Not reachable takes a deep one. Low confidence lowers the score, but only down to a floor. Exposure analysis then raises the priority of exposed workloads and lowers it for low-exposure ones, without touching severity.

In the current model, a Reachable Critical with high EPSS and high confidence scores about 96. The identical finding marked Not reachable scores about 34. It drops down your queue but stays in it.

A triage routine that uses the analysis

Start with what attackers can reach: Findings Repo All filters Real risk Reachable or click the Reachable chip in the Triage row.
Work down by priority, not by raw severity.
Open a finding and read its sections in order: Code & taint trace (is the path real, and what is its provenance?), AI verdict, Risk & exposure, then Exposure.
Decide: fix it (module 7), validate it at runtime (module 6), or mark it as a false positive.

For a posture view, open Dashboard DevSecOps Reachability Split . The widget shows how your findings divide across Reachable, Unreachable and Unknown.

Two passes. One ground truth.

Static analysis tells you where a flaw is and why it matters. It cannot prove that the flaw is exploitable in your running application. AI Swarm Pentest does that. In the product it appears as AI Pentest under the Pentest section. It tests the running application inside a scope agreed in writing and works to one rule: no reproducible proof, no verified finding.

The two passes work as a sequence. Deep Code Analysis attaches the context. AI Swarm Pentest validates the priority paths. Reviewers see the evidence and the scope, and your team receives an actionable handover.

Back to the invoice API. AI Scan reports the IDOR as High. AI False-Positive Detection kept it and traced req.params.id (source) to Invoice.findById (sink), so it is Reachable, and its Internet path shows exposed. That makes it a strong candidate for the pentest scope. If the pentest reproduces it, you have both the line of code and runtime proof. By default, linking a source repository to the pentest gives the agent your code for a white-box run. Pentest findings appear under Findings App Pentest , with an Evidence & attack path section in place of the taint trace.

Neither pass replaces your team. People review the evidence and decide, and nothing changes in production automatically. Your team keeps merge control over every fix.

Key takeaways

A pattern match tells you that a rule fired. Deep Code Analysis adds the affected flow, whether an attacker can reach it, and the weakness class. AI Scan findings and AI-verified trace steps are checked against your repository, and other AI text, such as the Attack scenario in Risk & exposure, is labeled for you to verify.
Read the provenance badge on every taint-trace step. An empty trace means no verified path is available, not that the finding is safe.
AI Scan runs the logic mode by default; classic and combined are opt-in. Findings without a verbatim snippet are discarded, and secrets and dependency CVEs are left to their own engines.
AI False-Positive Detection is opt-in and read-only. It needs an explicit indicator to dismiss a finding, Kept as real is not proof that it ran, and your human decision always wins.
Reachability and exposure change priority, never visibility or severity. Check the evidence before you rely on Not reachable, treat Unknown as unproven, and confirm exposure with the Internet path.
Deep Code Analysis supplies context and AI Swarm Pentest supplies reproducible proof. You need both passes for one ground truth.