Findings and reports

Distinguish findings, red-team reports, structured agent reports, retained context, and their lifecycles.

The security factory uses three related records.

Record	Meaning
Finding	One security issue or decision unit with evidence, risk, status, and remediation context
Red-team report	The run record and evidence from one Red Team engagement
Structured agent report	The typed result a customer agent returns through Superagent MCP

A finding can originate in a red-team report or another security worker. A customer agent acts on that finding and returns a structured agent report. Superagent retains the report as customer context and applies that context to later work.

Finding queue and lifecycle

Every issue Superagent raises lands in one place. Security Factory is the org-wide queue where red-team results and incoming GitHub advisories arrive deduplicated, get verified by automated triage, and turn into fix PRs. Security teams work the queue instead of chasing reports across tools. See the Overview for how this queue connects your software, security workers, and development workflow.

Where findings come from

Source	Typical content
Red Team	Exploit paths found across applications, repositories, agents, infrastructure, and package artifacts
PR Security	Code, workflow, and dependency risks found before merge
Agent Guardrails	Risky agent context or runtime actions
Customer-provided security agents	Customer-specific security issues normalized into the factory
Connected advisories	Incoming GHSA/CVE-style advisories for connected repositories

All findings appear in the same queue with title, risk level, source, triage status, and source context. Filter and sort to prioritize high-risk or unassigned work.

The finding detail page

Open a finding at /app/factory/[factoryId] to:

Read the description, CWE IDs, CVSS vector, and advisory links
Review the triage summary, recommendation, and evidence when automated triage has run
Inspect the proposed patch with its diff and code references when Superagent produced one
Create a fix PR from the proposed patch without leaving the finding
Update the triage status and record a resolution
Navigate to the parent report for full scan context

Status lifecycle

Every finding moves through a four-stage lifecycle:

Status	Meaning
New	The finding arrived from a report or advisory and has not been triaged.
Triaging	An automated triage run is in progress (system-managed).
In review	Triage produced a verdict, or someone moved the finding into active review.
Resolved	The finding is closed with a recorded resolution.

When a finding is resolved, a resolution captures why it was closed:

Resolution	Use when
Fixed	The vulnerability was remediated.
Accepted risk	The issue is real but the risk is accepted.
False positive	The finding is not a real vulnerability.
Won't fix	The issue will not be addressed (also used by bulk archive).

Resolved findings can be reopened, which returns them to New and clears the resolution.

Triage workflow

A finding appears as New after a security worker, customer-provided security agent, or connected advisory source creates it.
Optionally run automated triage. The finding shows Triaging while the sandbox run is active.
When triage completes, a confirmed or inconclusive verdict lands in In review for a human decision; a not-reproducible verdict auto-resolves the finding as a False positive. If a run fails, the finding returns to its lane with a "Triage failed" indicator.
Resolve the finding with the appropriate resolution, or drag it to the Resolved column on the board (you will be prompted for a reason).
Track remediation in your issue tracker; use the finding page as the system of record in Superagent.

Automate the handoff