We Planted SQL Injection in a Delphi App — Cursor Ran the Scan, DerTriage Confirmed It

An administrator account sees every project on the installation and carries permissions that automation does not need. Create a separate user for this work, give it a non-administrative role, and use it for the scan, the token, and the interface.

The account used throughout this guide is a regular user with full access to product functions and no administrative panel. Scan quotas were raised for the evaluation period so that repeated scans would not exhaust a limit mid-guide.

Sign in as that user before continuing. The first sign-in asks the account to accept the end user licence agreement.

DerScanner publishes an IDE extension for SAST and SCA, and it is a reasonable way to work if you live in the editor. It is not a prerequisite for anything below. A named API token gives the same control from a shell, a pipeline, or any HTTP client.

Request a token with the account credentials and a name you will recognise later. The name matters because tokens are listed and revoked by name.

The response contains an access token. Send it as a bearer token on every subsequent request. Treat it as a credential — it carries the permissions of the account that issued it, so keep it in a secret manager rather than in a shell history or a repository.

A verification feature can only be assessed against code whose defects you already know. This guide therefore uses a synthetic application, written for this purpose and for no other. It is not a real product, it was never deployed, and it is not an open-source project belonging to anyone else.

The application is a Delphi warehouse operations tool of about 8,000 lines across 23 units — a login form, an inventory module, orders, suppliers, reporting, backup, and a data access layer. It contains deliberate defects, including SQL statements assembled by string concatenation from values the operator types into the interface.

Package the source as a zip archive. The scan in the next step uploads that archive directly, so nothing needs to be checked into a repository the scanner can reach.

Scan settings include AI triage per severity, plus an option to apply the triage result to the finding status automatically. When those are on, every finding of the selected severities is verified as part of the scan. That is the workload to size GPU capacity for, and it is the workload to avoid on a CPU-only host.

Start the scan with those flags explicitly off. The scan then does what a scan does — analyse the code — and leaves every finding unverified for you to choose from.

The response returns the scan identifier you will poll in the next step.

Poll the project's scan list until the scan reports COMPLETE. The same record carries the severity counts, so a single request tells you both that the scan finished and how much it found.

This scan reported 65,272 lines of code and two critical findings, both SQL injection. Findings are grouped by the rule that produced them, so a second request returns the rule names with the number of findings under each.

Resolve an individual finding identifier to its position in the source. The response gives the file and line along with the current verification status, which is where the DerTriage verdict will appear later.

Open the finding in the interface. The code panel highlights the flagged line together with the surrounding function, which is usually enough to decide whether the data reaching the sink is attacker-controlled.

In this finding the order reference is a string parameter that is concatenated into a SQL statement inside single quotes, with no parameterisation and no escaping. The caller passes the order number the operator selected in the grid or typed into the quick filter, so the value is operator-controlled by design.

That is a genuine injection, and knowing it independently is what makes the next step meaningful.

Selective verification is started from the actions menu of an individual finding — the three dots at the right-hand end of the finding row. This is the row that names the file and line, not the row that names the rule and carries the count. Opening the menu on the group row gives you bulk status editing instead.

The menu contains a DerTriage button below the comment field. Pressing it queues verification for that finding alone. The button is replaced by a progress indicator while the job runs, and the verdict appears in the same menu when it completes.

This is the mode that makes local, CPU-only installations useful. One finding is a small job, so a CPU host can return a verdict in a reasonable time, while verifying an entire scan the same way is not a workload to plan without a GPU.

The verdict is written into the finding's menu as plain text. For this finding DerTriage reported that the SQL query is constructed by directly concatenating user input, named the parameter it followed, and recommended a status.

The recommendation matches the reading of the code from the previous step — the same parameter, the same mechanism. That agreement is the point of the exercise. Press Apply to record the status on the finding, or set a different status if you disagree.

The verdict names `AOrderRef`, which is the parameter on the flagged line. A verdict that discusses a parameter you cannot find in the code is a signal to look at what context the analyzer actually supplied, not a reason to accept the status.