Application Security: every screen, column and action¶
Complements Reading the Application Security screens, which covers the audit and vulnerability lists in narrative form. This page is the exhaustive list — every column and every menu item, including the ones that are easy to confuse with each other.
Application Inventory¶
The widest table in the product: seventeen columns, most of them stacked pairs. It is the business context that turns a finding into a decision, and it is filled by whoever onboards the application rather than by any scanner.
| Column | Holds | Why it matters |
|---|---|---|
| Application — Id / Type | Application name, its NxSAM identifier and asset type | Identity and asset type |
| URLs — Prod / Non-Prod | The production and non-production addresses | Which environment a finding was raised against |
| Data Class — Classification / Personal Data | Data classification, and whether personal data is handled | Whether a breach here is a regulatory event |
| Risk — Criticality / Rating | Business criticality, and the rating derived from it | Business criticality, and the resulting rating |
| Business Unit — BU / Sub-BU | Owning business unit and sub-unit | Who owns the remediation budget |
| Category — Cat. / Sub-Cat. | Application category and sub-category | Application classification |
| Tech Owner — Owner / Framework | The technology owner and the framework it is built on | Who can actually fix it, and in what |
| Host — IP / WAF | Address, deployment location, and whether a WAF is in front | Where it runs and whether a WAF sits in front |
| Usage — Users / Pages | Number of users and pages | Blast radius, and rough test effort |
| Scope — Exposure | Assessment scope, and internet-facing or internal | What was assessed, and how reachable it is |
| Attributes — CJ / PROP | Customer-journey and personal-information flags | Whether the application sits on a customer journey or handles personal data |
| Attributes — IMU / SGU | Internal management unit and service group unit | The internal ownership hierarchy |
| Status — Remarks | Lifecycle state and any note recorded against it | Lifecycle state and any note |
| Acceptable Downtime | The outage the business will tolerate | Decides whether a fix can be deployed immediately |
| End User Base — Size | Scale of the user population | How many people a change affects |
| Repository — Source URL | Where the source code lives | Needed for static scanning |
WAF and Acceptable Downtime change what remediation is possible
These two are the operational reality behind a finding. A Critical on an application behind a WAF with zero acceptable downtime cannot be fixed the same way as one on an internal tool that can be restarted at will — the first needs a virtual patch, the second a deploy.
They are the fields most often left blank at onboarding and most often wanted during an incident.
The audit list¶
Columns and the twelve row actions are covered in Reading the Application Security screens. Two are worth naming here because they are not obvious:
- Manage Test Summary — a free-text record of what testing was actually performed. For a manual assessment this is the evidence of scope; without it, an audit cannot be reviewed after the fact.
- View Audit Chain — the original audit and every re-audit against the same scope, in order. The answer to "why are there four audits for this application".
- Assign Auditors — who performs the assessment. Until someone is assigned the audit
can be requested and approved but not worked, which is a common reason an audit sits in
Approvedwith nothing happening. - Vulnerability Overview — the severity and asset breakdown for the audit without opening its finding list, useful when triaging a queue of audits rather than one.
As in API Security, the module ships two audit-table components with slightly different menus. Both perform the same operations.
The vulnerability list¶
| Column | Notes |
|---|---|
| Vulnerability | The finding, with category and OWASP mapping |
| Tool | Which scanner reported it — a numeric master-type code rendered as a name |
| Risk | Severity, derived from the score |
| Discovered On | Blank until the finding is approved |
| Validation | Saved, Submitted, Approved, Closed, False Positive |
| Current Status | The client status — fourteen values |
| SLA Details | Duration and expiry |
| Artifacts | Evidence attached to the finding |
Row actions — nine¶
| Action | What it does |
|---|---|
| Edit Vulnerability | This occurrence |
| Edit Vulnerability Master Details | The catalogue entry every occurrence inherits |
| Copy Vulnerability | Duplicates the finding onto another asset or audit |
| Edit CVSS Metrics / View CVSS Metrics | The CVSS vector, component by component |
| Edit Sequence | The order findings appear in the generated report |
| Vulnerability History | Every change to the finding, across audits |
| View Status History | Status changes with who made them |
| Delete Vulnerability | Removes it from the audit |
Edit Vulnerability Master Details is not Edit Vulnerability
They sit adjacent in the same menu. The first changes the master catalogue — the title, description and remediation inherited by every occurrence of that vulnerability across every audit and asset. The second changes only the row you opened it from.
Fixing a typo in the master is correct. Recording something specific to one application through it is not, and the dialog does not make the difference obvious.
Copy Vulnerability exists because the same weakness often affects several applications built from one template. Copying preserves the description and remediation while creating a genuinely separate finding, each with its own SLA and owner.
Page-level actions on the vulnerability screen¶
| Action | What it does |
|---|---|
| Export Vulnerabilities | Downloads the current list, respecting the filters applied |
| Compare | Two audits side by side — what is new, fixed and unchanged |
| Trend analysis | How the finding profile has moved over successive audits |
Compare is the re-test tool. After a confirmatory audit it answers the only question that matters — which of the original findings are actually gone — without reading two lists in parallel.
Artifacts¶
Step, Description, Images: the reproduction path, in order. A finding whose artifacts are a single unlabelled screenshot cannot be re-tested by anyone but its author.
Vulnerability history¶
Audit ID, Audit Details, Risk, Vulnerability Status, Created On, Status Changed By — and it spans audits, so it shows a finding closed in one assessment and re-opened by the next.
Add Old Vulnerabilities¶
vId, Vulnerability, Audit Name, Risk, Client Status. Carries outstanding
findings from earlier audits into a new one, preserving their history and original
discovery date. Re-entering them by hand creates fresh findings that age separately.
Edit Tags¶
Tag ID, Tag Name. Tags are shared, so renaming one changes it everywhere.
The dashboard¶
Every widget exports individually via Download PDF and Download PNG.