Issues and triage

An issue is one finding from one scan: a vulnerable dependency, a code weakness, a leaked secret, a misconfiguration or a DAST or pentest result. Issues with the same scanner and CVE, CWE or title form an issue group (GET /v1/issues/groups).

Statuses

Status	Meaning
open	Needs attention
resolved	Marked fixed
snoozed	Hidden until a date; then it is open again
false_positive	Not a real problem
accepted_risk	A known risk the workspace accepted, until a date

By default lists show issues from the latest scan of each repository or target (latest_only=true), as the dashboard does. Pass latest_only=false for every scan.

Resolve and reopen

POST /v1/issues/{issue_id}/resolve and …/reopen change the status at once (scope issues:triage). They are recorded in the workspace audit log and the dashboard’s history. An accepted risk cannot be changed through the API; a workspace admin does that in the dashboard.

Exception requests

Marking an issue as a false positive, snoozing it or accepting its risk is an exception, and a person must approve it. The API creates a pending exception request; the issue does not change until someone approves the request in the dashboard (scope issues:exceptions):

curl -s https://api.devsecure.io/v1/issues/8e4b7a2c-1d3f-4e5a-9b6c-7d8e9f0a1b2c/snooze \
  -H "Authorization: Bearer $DEVSECURE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Fixed in the next release", "until": "2026-12-01T00:00:00Z"}'

{
  "id": "5c4d3e2f-1a0b-4c9d-8e7f-6a5b4c3d2e1f",
  "issue_id": "8e4b7a2c-1d3f-4e5a-9b6c-7d8e9f0a1b2c",
  "type": "snooze",
  "status": "pending",
  "reason": "Fixed in the next release",
  "expires_at": "2026-12-01T00:00:00Z",
  "requested_by": "usr_9d8c7b6a5f4e3d2c1b0a9f8e",
  "decided_by": null,
  "created_at": "2026-10-01T12:00:00Z",
  "decided_at": null
}

• The requester is the person who created the API key. They cannot approve their own request, and no API call approves or denies anything.
• Follow requests with GET /v1/exception-requests, or subscribe to the exception_request.decided webhook.
• Cancel a pending request with POST /v1/exception-requests/{id}/cancel.

Pentest targets work the same way: POST /v1/pentest/targets asks for a target, and a person approves it in the dashboard before pentests can run.