Red Teaming: support reference

Internal. The customer-facing explanation is in the screen reference.

The smallest module in the product, and deliberately so. A red team engagement produces a narrative and a handful of findings rather than a scanner's inventory, so the module records the engagement and its outcomes rather than trying to model the exercise.

Findings are reached through the engagement

The vulnerabilities screen is opened from an audit. Navigating to it directly — from a bookmark, or an old link — returns to the audit list, because there is no engagement to show findings for.

A caller reporting that "the vulnerabilities page keeps bouncing me back" is describing that behaviour, not a fault.

Its statuses are its own

Red Teaming carries its own validation status list, separate from Application Security's and from Network Security's. Quoting a status from another module may name a value this one does not have.

The confirmation dialog here also differs from the other modules', which is cosmetic but worth knowing when comparing screenshots.

Volumes are small on purpose

An engagement with eight findings is normal. Low counts are not evidence that an import failed — there is usually no import at all, because findings are recorded by the team that ran the exercise.

If a customer expects scanner-scale numbers here, the expectation is the problem.

Reports carry the narrative

The value of a red team engagement is the attack path, not the finding count. Where the narrative lives in an uploaded report rather than in the findings, the module holds the report and the findings summarise it.

What to collect before escalating

1. The engagement (audit) name and ID.
2. The finding's identifier and its status, quoted — this module's list is its own.
3. Whether the caller reached the findings screen from the engagement or directly.
4. Whether the engagement's report has been uploaded, for narrative questions.