Glossary¶
Terms as NxSAM uses them. Several are ordinary security words with a narrower meaning here, and those are the ones worth reading even if the term is familiar.
Assets and scope¶
Asset — anything that can hold a vulnerability: a web or mobile application, an API, a network host, a thick client, or a container image. Each type is a separate inventory with its own columns and its own licensed limit.
Asset property — an attribute recorded against an asset, such as criticality or whether it is internet-facing. Properties are more than description: they narrow SLA durations and feed the contextual risk score.
Bifurcation — splitting one application into separately assessed parts, so a large system can be tested module by module rather than as one unit.
Collection — a grouping of container images that comes from the scanning platform rather than from NxSAM, and is not editable here.
Scope — what an assessment covers. For applications this is the application; for compliance it is a host list, which is why compliance scope disputes are settled with an exported list of addresses.
Assessments¶
Audit — one assessment of one asset. It has a type, a category, a cycle, a scope, and a status of its own, separate from any finding's status.
Audit cycle — which round of a recurring programme an audit belongs to.
Confirmatory audit — a re-test created against a parent audit to verify that fixes hold. It is evidence about the original rather than an independent assessment, so the two should not be counted as two rounds of testing.
Considered — the marker deciding whether an audit contributes to aggregate figures. Normally the latest audit per asset that reached a final state. An audit that is not considered still shows its findings on the module screen while contributing to no dashboard or report.
Initial audit — a first assessment, as opposed to a confirmatory one.
Findings¶
Vulnerability (also finding, issue) — one weakness on one asset, found by one assessment.
Vulnerability master — the catalogue entry (title, description, remediation) inherited by every occurrence of that vulnerability everywhere. Editing the master changes all of them.
Posture — Policy Compliance's unit: one control checked against one host. Every check produces a posture whether it passed or failed, which is why this module's volumes dwarf the others.
Artifact — the evidence attached to a finding: the steps, description and images that let someone else reproduce it.
Instance — which occurrence, where the same control or finding applies more than once to the same asset.
Status¶
Validation status — whether a finding has been confirmed. Nothing is counted anywhere until this reaches Approved, which is also when Discovered On is populated.
Client status (also current status) — what is being done about the finding. Of its values, only two close it.
Closed type — the flag deciding whether a status stops something counting as open. It is configuration rather than a fixed rule, so a deployment can change what "closed" means.
Posture status — what a compliance check returned: pass, fail or error. Error means the check could not run — a scanner or credentials problem rather than a compliance result.
Sub status — the qualifier beneath a main status: which kind of acceptance, or which stage of an approval.
Time and SLA¶
SLA duration — how long a finding of a given severity on a given asset type may remain open. Configurable, and narrowable by asset property.
SLA expiry — the resulting deadline. Changing an SLA duration re-derives expiry dates, which can make a batch of findings overdue with no data change at all.
Discovered On — when a finding was first observed. Blank until the finding is approved.
Last observed — the most recent sighting, which is how a finding is known still to exist.
Overdue — past SLA expiry and not closed.
Decisions¶
Deviation (also risk acceptance, RA) — a recorded decision not to fix something, with an approval chain and an expiry. It does not close the finding: the exposure is still live and still counts as open.
Exception — a status marking an agreed exception rather than a resolution. Reporting that conflates the two overstates remediation.
Auto reject end date — when a temporary acceptance lapses on its own.
Integrations and processing¶
Integration — a connection to a scanning tool, either pulling from its API or parsing an uploaded report.
Vulnerability key — the columns deciding whether an incoming finding is one already seen. Changing it redefines "the same finding" and splits history.
Queue — asynchronous work: imports, syncs, report generation. A screen that seems not to have updated usually has a queue entry that explains it.
Data process — how far a tool-fed audit has got through the import pipeline; the difference between "the upload finished" and "the data is ready".
Beat — a scheduled job maintaining derived data, such as recalculating SLA states as dates pass. A stopped beat produces figures wrong by a fixed interval and raises no error.
Governance¶
RLCM — Red Line Compliance Management: assessment of controls against frameworks, rather than of systems for weaknesses.
TPRM — Third-Party Risk Management: the same control assessment applied to suppliers. It shares screens with RLCM and differs by the audit's type.
UCF — Unified Control Framework: the mapping that lets one control satisfy several frameworks at once, so answering it once covers each of them.
Control — a requirement being assessed, as opposed to a weakness being found.
Standard — the framework a control belongs to, such as ISO/IEC 27001 or PCI DSS.
Reporting¶
Considered audit filter — the switch on Report Search that reproduces either the dashboard's numbers or the module screens'. Comparing the two settles most disagreements about counts.
Design template — the layout a report renders through, separate from the template that decides its content.
Share view against share copy — sharing a template as a view keeps one definition that your edits reach; sharing a copy creates an independent template that will drift.