Vulnerability finding intake
a structured front door, not a shared inbox

The Nessus result lands as High because Nessus said so; the Burp finding lands as Medium because the tester said so; the developer escalation lands without a severity at all because nobody asked. Three weeks later the triage queue cannot be sorted by risk because the severity column is a mix of incompatible scales. The fix is normalising severity at intake against the workspace severity policy: source severity is recorded, CVSS 3.1 is auto-calculated from the vector string, and any override carries the named reason so the next reader reads the calibration rather than re-deriving it.

A finding lands against a vague target ("the marketing site") with no IP, no hostname, and no repository reference. The triager spends thirty minutes hunting down the asset; the named owner is never set; the finding stalls for two cycles because nobody is on the hook. The fix is requiring the asset binding and the named owner of record at intake before the finding opens on the queue, with RBAC routing rules that read the asset tier and the source to push the new record to the right named person rather than to the room.

The same vulnerability lands once from an external scan, once from an authenticated scan a week later, and once again from a manual writeup during a pentest. The queue carries three records for one issue; the retest is scheduled three times; the close-out evidence has to be cross-referenced before anyone can mark anything closed. The fix is deduplicating at the door: bulk import flags duplicates before findings land, manual entries check open findings for the same asset and CWE before opening a new record, and the activity log captures the merge decision so the audit chronology reads as one finding rather than three parallel ones.

A finding the programme accepted as a risk last quarter with a documented expiry lands again from the next scan cycle, opens on the queue as a new record, and the team re-debates whether to accept it. The exception register is invisible to the intake path. The fix is checking the workspace exception register at intake so findings that match an active acceptance, deferral, or false-positive suppression inherit the existing record and the existing expiry rather than producing a new ticket the team has to dismiss.

A tester finds an issue while exploring beyond the engagement scope, writes it up, and lands it on the queue without an explicit acceptance decision. The engagement scope and the rules of engagement get questioned later; the finding sits in an awkward state because nobody agreed to receive it. The fix is the intake check that verifies the engagement scope and ROE permitted the work that produced the finding, and the explicit decision path for out-of-scope discoveries (accept as a new engagement, defer, or close with rationale) so the queue does not absorb undirected work silently.

The first event captured on the finding is when a remediation owner left a comment three days after intake. The chain of custody from scan to finding to owner is missing; the auditor reads the finding without knowing how it got onto the queue, who decided the severity, or which scan ID it came from. The fix is stamping the activity log at intake with the source, the actor, the source severity, the normalised severity, the asset binding, the dedup decision, and any exception match, so the chronology is continuous from the first record through remediation and retest.

The named source (external scan module, authenticated scan, code scan rule, bulk import file, manual entry from named engagement, third-party report from named vendor, VDP submission, internal escalation), the capture timestamp, the source identifier (scan ID, repository and commit SHA, import file name, report reference, submission ID), and the source severity as recorded before any normalisation. The source attribution survives into remediation and audit so the chain of custody is reconstructable rather than reconstructed from email.

The engagement reference, the target asset (hostname, IP, repository, application service, mobile app, API endpoint), and the named owner of record under the workspace RBAC. The owner of record is the person on the hook for the finding through remediation; the engagement reference is the planning context the finding sits inside. Both are captured at intake so the finding does not stall waiting for a routing decision.

The source severity (vendor-rated, CVSS base, tester-assigned, qualitative, or absent), the normalised severity that the workspace operates against, the CVSS 3.1 vector and base score auto-calculated where the source provides a vector, and the named reason for any override of the auto-calculated severity. The normalisation policy is a workspace decision; the override reason makes the decision auditable.

The evidence the next reader needs to triage and remediate: the scanner request and response or module output, the code snippet and rule identifier for SAST findings, the package and version for SCA findings, the manual writeup and screenshot for tester-entered findings, the external report excerpt for third-party intake, and the disclosure submission body for VDP intake. Document management holds the original artefacts as versioned attachments cited by the finding rather than re-authored on the record.

The result of the dedup check against the open catalogue (new record, merged into existing finding ID, suppressed against an active workspace suppression), the result of the exception match against the workspace register (no match, matches accepted risk reference, matches deferral reference, matches false-positive suppression), and the named actor and timestamp for each decision. The intake decisions are queryable so the next operator does not re-litigate them.

The named recipient on the workspace who receives the intake notification (the owner of record, the engagement lead, the secondary on-call where the asset tier requires it), the notification channel (in-product, email, both), and the acknowledgement timestamp. The routing is part of the finding record rather than a separate Slack message so a missed notification surfaces on the queue rather than in nobody-noticed inbox limbo.