API Security: every screen, column and action

API Security mirrors Application Security in structure and differs in several details that matter when tracing a finding — including two audit-table implementations whose menus are worded differently for the same operations.

The audit list

Column	What it holds
Request Info	Who requested the audit, when, and the request ID
Audit Details	Audit name and the API asset it runs against
Vulnerabilities	Open counts with the severity split and the risk score
Audit Properties	The chips — type, cycle, category, scope, considered
Audit Status	A dropdown offering only the legal next steps

Row actions — twelve

Action	What it does
View Vulnerabilities	The findings for this audit
Vulnerability Overview	Severity and asset summary without leaving the list
Manage Audit Scope	Records what was in and out of scope
Manage Test Summary	A free-text description of what testing was performed
Assign Auditors	Who performs the work
Edit Audit Details	Name, cycle, dates, properties
Edit Tags	Labels for grouping and reporting
Update Audit Start Date	Changes the start date after creation
Re-Audit	Creates a follow-up audit against the same scope
View Audit Chain	The original and every re-audit in sequence
View Audit Status History	Every status change with who made it
Delete Audit	Soft delete

Manage Test Summary is what makes an API audit defensible

APIs are largely tested by hand, so the summary is the record of what was actually attempted — which endpoints, which authentication, which abuse cases. An audit without one cannot be reviewed later, and an auditor asking "what did you test" is asking for this field.

Two audit tables, two vocabularies

The module ships two audit-table components. One labels its menu Assign Auditors, Edit Audit Details, Manage Audit Scope; the other labels the same operations Assign Api Auditors, Edit Api Audit Details, Manage Api Audit Scope, and View Api Audit Chain / View Api Audit Status History.

They do the same things. If a caller quotes a menu item you cannot find, this is why — ask which screen they reached it from rather than assuming a version difference.

The vulnerability list

Column	Notes
Vulnerability	The finding and its category
Tool	Which scanner reported it, or Manual
Risk	Severity as derived from the score
Validation	Whether the finding is agreed
Current Status	What is being done about it. API Security keeps its own status list, separate from the AppSec one
Discovered On	Last seen, and blank until the finding is approved
SLA Details	Duration and expiry
Artifacts	Evidence attached to the finding

Row actions — eight

Action	What it does
Edit Vulnerability	The finding's own fields
Edit CVSS Metrics	The CVSS vector, component by component
View CVSS Metrics	The same, read-only
Edit Issue Master Details	Edits the underlying catalogue entry, not just this instance
Edit Sequence	Reorders findings within the report
View Vulnerability History	Every change to the finding
View Client Status History	Status changes specifically, with who made them
Delete Vulnerability	Removes the finding from the audit

Edit Issue Master Details changes the catalogue, not the finding

The two edit actions sit next to each other and do different things. Edit Vulnerability changes this occurrence. Edit Issue Master Details changes the master entry — the title, description and remediation that every occurrence of that vulnerability inherits, across every audit and every asset.

Correcting a typo through the master is right. Recording something specific to one endpoint through it is not, and the effect is not obvious from the dialog.

Edit Sequence matters because API findings are usually presented as a narrative — a chain where one weakness enables the next. The sequence is the order they appear in the generated report, and it is set deliberately rather than by severity.

Artifacts

Evidence attached to a finding, structured as steps:

Column	What it holds
Step	The position in the reproduction sequence
Description	What was done at this step
Images	Screenshots for that step

This is the reproduction path. An API finding is often only demonstrable as a sequence — authenticate as A, obtain a token, alter an identifier, read B's data — and a single screenshot proves nothing. The step structure is what makes it re-testable by someone other than the original tester.

Vulnerability history

Column	What it holds
Audit ID / Audit Details	Which audit the change belongs to
Risk	The severity at that point
Vulnerability Status	The status it moved to
Created On	When
Status Changed By	Who

Because it spans audits, this is how you see that a finding was closed in one assessment and re-opened by the next — the single most common dispute on a re-test.

Add Old Vulnerabilities

Opened when creating a re-audit. It lists findings from previous audits — vId, Vulnerability, Audit Name, Risk, Client Status — so the ones still outstanding can be carried into the new audit rather than re-entered.

Carrying a finding forward preserves its history and its original discovery date. Entering it again creates a second finding with neither, and the two then age separately, which is why the option exists.

Edit Tags

Tag ID and Tag Name, multi-select. Tags are shared across audits, so renaming one here renames it everywhere it is applied.

The status models

API Security keeps its own master tables. The values overlap Application Security's without matching them, so a status list quoted from one module will not fit the other.

Audit status — fourteen values

In sequence: Saved, Reverted, Requested, Approved, Scheduled, Work In Progress, Not Hold, Completed, Report Published, Aborted, Review Requested, Processed, Changes Requested, PMO Verified.

• Closed types — Completed and Aborted only.
• Comment required — Aborted, Changes Requested and PMO Verified, and any other status the administrator has marked as needing a reason. Moving an approved audit to Hold asks for one.
• Report Published sits after Completed: the assessment is finished and the report has been issued, which are separately meaningful to a customer.
• Not Hold is the release from a hold rather than a hold itself, despite reading like one. Nothing is placed into Not Hold to pause it.

Validation status — five values

Saved, Submitted, Approved, Closed, False Positive — the same five as Application Security, and notably not the three Network PT uses.

Client status — fourteen values

New, Patch in progress, Patched, Not Patched, To be patched, On hold, Reopen, Validated, Not Applicable, Risk accepted, Risk acceptance, Duplicate, Exception Handled, Expired.

Closed types are Validated and Exception Handled. Not Applicable and Risk accepted require a comment; Risk accepted, Risk acceptance and Expired display a date alongside the status.

The dashboard

Each widget exports individually through Download PDF and Download PNG.