Cursor Wrote the App, DerTriage Confirmed Three Real Bugs — On a CPU-Only Host

This guide uses a synthetic FastAPI service written for the walkthrough only. It is not a real product and was never deployed. The entire application was produced from one prompt in Cursor; nothing under app/ was edited by hand afterwards.

The prompt asked for a small internal supply desk — staff login, searchable request lists, CSV reports that can be zipped for email, document upload, saved filter presets from a desktop tool, and a couple of admin endpoints. It deliberately did not ask for vulnerabilities, and it did not ask for tests or Docker.

Keeping the prompt intact matters for provenance. If you reproduce the workflow, save the prompt text alongside the archive you upload, so later readers can see what the model was asked to produce rather than what an engineer added afterwards.

DerScanner publishes an IDE extension, but it is not a prerequisite here. A named API token gives the same control from curl, a pipeline, or any HTTP client.

Request a token with the account credentials and a name you will recognise later. Send the access token as a bearer credential on every subsequent request.

The companion guide on selective verification with DerTriage walks through token issuance, session limits, and the first scan in more detail if you need a fuller treatment of those steps.

Create a SAST project for the archive, then start the scan with AI triage flags explicitly off for every severity. The scan analyses the code and leaves every finding unverified until you choose otherwise.

Restrict languages to PYTHON so the result set reflects the generated service only. Sending one comma-separated languages field is required on some installations; one form field per language is rejected even when every language is licensed.

The response returns the scan identifier to poll in the next step. The project identifier in the commands below belongs to the synthetic SupplyDesk sample created for this guide.

Poll the project scan list until the scan reports COMPLETE. This scan reported 1,167 lines of Python and twenty-seven findings — twenty-two critical and five medium.

Grouped by rule, the scan reported twelve SQL injection findings, three command injection, three deserialization, five path manipulation, two hardcoded passwords, and one each for weak hashing and weak randomness. That volume is the point of selective verification — you choose what to confirm rather than sending the entire set through DerTriage at once.

Resolve individual finding identifiers when you need file and line positions in scripts. The interface groups findings by rule name and expands to show each file and line.

The clearest SQL injection in the generated code is the list endpoint, where search text, column name, status, and sort parameters are concatenated straight into the statement. That is the ground truth to read before trusting any verdict.

The scanner reported the sink at the shared db.query helper rather than at the route handler line. That is normal for inter-procedural analysis — the finding name in the interface points to db.py, while the untrusted values enter in supply.py.

Open the finding in the interface, read the highlighted code, then start selective verification from the three-dot menu on the individual finding row — not the group row that carries the count.

The report packaging endpoint builds a shell command from the export directory and archive name, then runs it with shell=True. The date range and status values that feed the CSV name also influence the command string.

DerTriage names the mechanism directly. For this finding it points to shell=True and recommends Confirmed, which matches a straight reading of the flagged line.

The preset import endpoint accepts a base64-encoded blob from the client and passes it to pickle.loads. That is arbitrary object deserialization on attacker-controlled input — one of the standard reasons pickle is discouraged on untrusted data.

Selective verification is started the same way as for the other findings. The verdict text appears in the finding menu when the job completes.

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

The DerTriage button sits below the comment field in that menu. While the job runs, the button is replaced by a progress indicator. The verdict appears in the same menu when it completes.

You can also queue verification through the REST API with GET /issues/{uuid}/triage?update=true if you prefer to script the step, but the verdict is read the same way — as plain text in the finding menu or in the API response.

All three verifications in this walkthrough ran on the same CPU-only host that serves local DerAI. None of them used scan-wide triage, and none required an IDE extension.

Each verdict is a recommendation, not proof. DerTriage suggested Confirmed for one SQL injection sink, one command injection call, and one pickle.loads — and in each case the recommendation aligned with a direct reading of the flagged code.

Press Apply in the menu to record the status on the finding, or set a different status if you disagree. The value of the exercise is the combination — a fast AI-generated codebase, a selective scan workflow, and a second opinion you can compare against your own reading.