Scanner Finding Tag and Label Taxonomy

Why scanner-emitted tags do not constitute a workspace taxonomy

Scanners ship their own classification systems because their vendors needed something to describe rules, plugins, and detections inside their own product context. Those classifications are vendor signals, not workspace decisions. Nessus organises plugins into families (Web Servers, CGI abuses, Misc., Backdoors); Burp Suite organises issues into types (cross-site scripting reflected, SQL injection, authentication bypass); Semgrep organises rules into rulesets keyed to language, framework, and policy; CodeQL ships query suites tied to query packs; SCA tools emit the CWE the upstream CVE was assigned to; cloud configuration scanners emit control identifiers against the cloud provider taxonomy.

None of these vendor taxonomies match the way the workspace actually answers the questions the programme reads at standup, at leadership review, at audit fieldwork. How many access-control findings are open this quarter? How many cryptography findings landed in the last release cycle? How many supply chain findings are owned by platform engineering? How many findings on customer-facing applications need remediation before the next compliance evidence window? Each of these questions requires a category the workspace defines, not a category the scanner happened to ship.

The structural reason matters. A vendor taxonomy is optimised for the vendor product: the granularity reflects what the vendor wants to talk to customers about, not what customers need to talk to leadership and auditors about. The classification axes reflect the vendor scanning model, not the workspace asset model, the remediation ownership model, or the compliance crosswalk model. A workspace that propagates vendor tags into canonical fields inherits a different taxonomy per scanner and a backlog where the same logical vulnerability lands under five different category strings depending on which tool fired first.^1,2,5,15

The five axes a defensible workspace taxonomy classifies along

Five axes carry the operational load in mature programmes. Each axis answers a different question, each carries a closed value list, and each finding carries exactly one value per axis where the axis applies.

The five axes are independent: a SQL injection finding (vulnerability class) on an internet-facing customer-facing web application (asset class, exposure context) with data confidentiality and data integrity impact (impact dimension) owned by the AppSec team (remediation owner) reads cleanly across all five axes without forcing any one of them to carry information that belongs to another. Programmes that conflate axes (using vulnerability class to also encode asset class or remediation owner) produce value lists that grow by combinatorial accretion and that nobody can keep consistent.^4,5,7,8,14

Taxonomy versus severity, deduplication, and asset binding

The taxonomy is one of four classification disciplines a multi-scanner workspace runs. It is easier to design each one cleanly when the boundaries between them are named.

• Deduplication answers whether two records describe the same underlying vulnerability and how to collapse them without losing evidence. The scanner output deduplication guide covers the merge mechanics.
• Severity normalisation answers what numeric severity the canonical record carries once the records are collapsed. The scanner output severity normalisation guide covers the translation table.
• Asset binding answers which durable asset the finding lives on. The scanner finding to asset binding guide covers the foreign-key model and the orphaned-finding queue.
• Tag and label taxonomy answers which structured classification axes the canonical record sits under for search, routing, reporting, and audit. This guide covers the discipline.
• Routing and owner assignment answers who owns each finding given the taxonomy value, the asset binding, the severity, and the engagement scope. The scanner finding routing and owner assignment guide covers the six routing inputs the rule reads, the recurring-detection assignment inheritance, and the unowned-finding controlled queue.

The four disciplines reinforce each other but do not substitute for each other. A programme that operates strong deduplication and severity normalisation without a taxonomy still produces a backlog that cannot answer how many findings of a class are open against an asset class right now. A programme that operates a taxonomy without strong deduplication produces a backlog where the same logical vulnerability sits under three records with three classifications. The defensible operating model is all four disciplines as parallel workstreams with named owners and documented policies, not one substituting for another.

Anchoring the workspace taxonomy against external schemes

External taxonomies are useful as crosswalks, not as the canonical workspace scheme. OWASP Top 10 revises on a roughly four-year cadence (2017, 2021, expected 2025 or later); the LLM Top 10 revises faster (2023, 2025); CWE adds entries and merges entries continually; CAPEC restructures its attack pattern hierarchy. A workspace that pins its canonical category list to one external version inherits churn every revision; a workspace that mirrors an external taxonomy directly inherits the granularity choices and scope boundaries the external committee made for reasons that may not match the workspace operating model.

The defensible pattern is treating the workspace taxonomy as a stable internal scheme and treating external taxonomies as crosswalks that the workspace maintains as separate mapping artefacts. The crosswalk reads: workspace category -> OWASP Top 10 entry, workspace category -> CWE identifier, workspace category -> OWASP ASVS verification requirement, workspace category -> OWASP LLM Top 10 entry for LLM-specific findings. When OWASP Top 10 revises, the crosswalk updates without disturbing the canonical category on any existing finding. When the workspace adds a new asset class (LLM endpoints, container images), the crosswalk extends without churning the existing category list.

The crosswalk is illustrative, not exhaustive. The workspace owner extends it for the asset classes the programme covers and for the external taxonomies the audit reads against. The OWASP ASVS verification requirements, OWASP API Security Top 10, OWASP MASVS for mobile applications, and OWASP LLM Top 10 each add a separate crosswalk column when the corresponding asset class is in scope.^{1,2,3,4,5,6,7}

Compliance control mapping as a separate axis

Compliance control mapping is the sixth axis that sits alongside the taxonomy without replacing it. Each finding carries a control reference that names the framework control the remediation evidence supports. The control reference is not the category; the category is the technical class and the control reference is the audit evidence anchor. A SQL injection finding carries vulnerability-class injection in the taxonomy and a control reference of PCI DSS 6.3.1 or ISO 27001 Annex A 8.8 in the compliance field. The category lets the AppSec team find every injection finding open against the customer-facing product line; the control reference lets the GRC team produce evidence that ISO 27001 Annex A 8.8 is operating.

Programmes that conflate the two end up with categories named after compliance controls (SOC 2 finding, PCI DSS finding, ISO finding) that lose the technical signal the remediation owner needs and that read inconsistently when the same issue evidences multiple controls. A finding can evidence ISO 27001 Annex A 8.8 (technical vulnerability management), SOC 2 CC7.1 (system monitoring), PCI DSS 6.3 (vulnerability identification), and NIST 800-53 RA-5 (vulnerability monitoring) simultaneously; the taxonomy classifies the technical class once, and the control reference (or a separate compliance mapping table) reads the controls each technical class evidences.

The clean pattern is: category captures the technical class on a closed list; control reference captures the primary framework control on a separate field; a documented mapping artefact maintained by the GRC owner extends each technical class to the framework controls it typically evidences across ISO 27001 Annex A 8.8, SOC 2 CC7.1, PCI DSS 6.3, NIST 800-53 RA-5, NIST CSF 2.0 ID.RA, and CIS Controls v8.1 control 7.^{8,9,10,11,12,13}

Enforcement at creation, triage, and review

A taxonomy without enforcement is a wish list. The enforcement workflow runs at three points across the finding lifecycle, and the audit evidence is the operating trail across all three.

Common failure modes and how the taxonomy prevents each

Six failure modes recur in programmes that operate without a taxonomy. Each one is an audit risk in addition to an operational risk.

How compliance frameworks read the taxonomy as operating evidence

Auditors do not read the taxonomy as a single control; they read it through adjacent controls that depend on consistent classification to operate. A programme that classifies findings well produces evidence that several controls read as operating; a programme that does not classify leaves the same controls reading as partial.

• ISO 27001:2022 Annex A 8.8 (technical vulnerability management) treats vulnerability identification, ranking, and remediation as a documented and repeatable control. The taxonomy is the artefact that makes the ranking and the remediation routing repeatable across team changes; the value list and the named owner are read at audit alongside the operating evidence.¹⁰
• SOC 2 CC7.1 (system monitoring) reads the categorisation across the observation period: do the findings produced across the year reflect a consistent classification, or do they vary with the analyst on duty. CC4.1 (monitoring activities) reads the trend of classes across the period as evidence the monitoring is operating against a stable scheme.¹¹
• PCI DSS v4.0 Requirement 6.3(vulnerabilities are identified and addressed) and 6.3.1 (vulnerability ranking) read the classification as the artefact that operationalises the ranking process. The audit reads the value list, the named owner, and the finding-level classifications to confirm the requirement is operating.¹²
• NIST SP 800-53 RA-5 (vulnerability monitoring and scanning) requires vulnerabilities to be analysed and remediated according to a risk-based approach. The taxonomy operationalises the risk-based approach by capturing the vulnerability class, impact dimension, and exposure context as classification axes that drive the risk picture.⁸
• NIST CSF 2.0 ID.RA (risk assessment) and PR.IP (information protection processes) read the classification as a programme-level discipline that produces the inputs to risk assessment. Classifications that drift across engagements produce risk assessments that cannot trend year over year.⁹
• CIS Controls v8.1 control 7(continuous vulnerability management) reads the value list and the finding classifications as the operating discipline that produces the management view. Programmes without a taxonomy fail safeguard 7.5 (perform automated application vulnerability scans) on the analytical side because the scans run but the output is not classified consistently.¹³

The shared pattern is that the classification is itself a control. Storage of scanner output is not the control; the workspace decision about which category that output produces is the control. Programmes that store scanner output without classifying it satisfy the storage requirement and fail the ranking and remediation routing requirement that depends on consistent classification.

Operating the taxonomy on a multi-tool stack

A workspace ingesting Nessus, Burp Suite, Semgrep, CodeQL, SCA, container, and cloud scanner output has to make taxonomy decisions at each ingest. The pattern below covers the recurring decisions.

• Preserve the source-emitted tag on evidence. The Nessus plugin family, the Burp Suite issue type, the Semgrep rule identifier, and the CWE the SCA tool emitted all stay on the finding evidence so the audit reads the source signal without recovering it from raw scanner exports.
• Map the source-emitted tag to a workspace category at import. The mapping is documented per scanner family (Nessus plugin family -> workspace category, Burp Suite issue type -> workspace category, Semgrep rule identifier or ruleset -> workspace category, CWE -> workspace category). The mapping artefact is owned by the same role that owns the taxonomy.
• Triage promotes drafts into canonical findings. Bulk-imported findings arrive as drafts the workspace triage promotes into canonical findings with the workspace category attached. The triage adjusts the category when the imported mapping is wrong for the specific finding context.
• Asset class is a separate decision from scanner type. A SAST finding is not automatically an internal-only asset class; a code-scan finding inside a publicly deployed customer-facing application carries customer-facing exposure context. The taxonomy axes resolve through the asset binding, not through the scanner that emitted the finding.
• Remediation owner reads from asset ownership. The remediation owner axis inherits from the asset register entry rather than being denormalised at intake. When ownership changes, the asset register entry updates, and every finding bound to that asset inherits the new owner through the binding (see the asset binding guide for the foreign-key model).
• Continuous monitoring scans produce findings that inherit the workspace category through the template. The 300+ finding template library ships with pre-set categories so recurring detections of known vulnerability classes inherit the workspace classification rather than being re-tagged each cycle.

The discipline is the same across every scanner: the source signal stays on evidence, the workspace category is the canonical decision, and the activity log captures every change so the audit reads back the classification history.

Operational checklist for a defensible taxonomy

For internal security, AppSec, GRC, and vulnerability management teams

A workspace taxonomy is the artefact that turns scanner output into a backlog leadership and audit can both read. Internal security teams, AppSec teams, vulnerability management teams, GRC teams, and security engineering teams operate the taxonomy as a workspace policy rather than as analyst preference, because preference does not survive team change.

• Anchor the canonical classification to a stable internal scheme; treat OWASP Top 10, CWE, and ASVS as crosswalks rather than as the canonical scheme.
• Name the five axes (vulnerability class, impact dimension, asset class, exposure context, remediation owner) and run each one as a closed list.
• Separate the technical category from the compliance control reference so both readings stay reliable.
• Preserve the source-emitted scanner tag on evidence so the audit chain from scanner output to canonical category stays intact.
• Run enforcement at finding creation, triage, cross-engagement review, and policy review with named owners and documented cadence.
• Review the value list annually and on external-taxonomy revision triggers rather than letting it accrete by analyst memory.

For internal security teams, AppSec teams, vulnerability management teams, GRC and compliance teams, and security engineering teams, a defensible taxonomy is the gate that turns scanner output into a backlog the whole programme reads consistently. The vulnerability prioritisation workflow covers how the classification feeds into the prioritisation decision the programme actually operates, and the cross-engagement finding search workflow covers how the structured classification turns into a search interface that answers leadership questions across the backlog.

How SecPortal supports the workspace taxonomy

SecPortal stores findings with structured fields that the workspace taxonomy maps into, preserves the source-emitted scanner tag on evidence, and records every classification change in the activity log so the audit trail reads from the live engagement rather than from a reconstructed history.

Related scanner and operating discipline

Taxonomy sits inside a family of classification disciplines a multi-scanner workspace runs. The pages below cover the connected decisions.

• Scanner output severity normalisation covers how the severity band is set on the canonical finding once the records are collapsed; severity is the prioritisation axis the taxonomy carries alongside the technical class.
• Scanner output deduplication covers the upstream discipline of recognising when two records describe the same underlying issue; deduplication produces the canonical finding the taxonomy classifies.
• Scanner finding suppression and deferral controls covers the three structured override types (false positive, accepted risk, severity override) that record how a finding leaves the active backlog without dropping out of the audit trail.
• Scanner finding to asset binding covers the foreign-key model that resolves the asset class and exposure context axes through the asset register rather than denormalising them onto the finding.
• Scanner evidence chain covers the seven evidence layers that hold the chain from scan execution to closed finding, with the taxonomy sitting inside the source-emitted and platform-canonical values layer.
• Importing third-party scanner results covers the import workflow that produces the drafts the taxonomy applies workspace categories to.

For the wider operating discipline the taxonomy plugs into, the cross-engagement finding search workflow covers how the structured classification turns into a search interface, the security leadership reporting workflow covers how the rollup reads against the classification axes, and the vulnerability prioritisation framework covers how class, severity, exposure context, and EPSS combine into the prioritisation decision.

Scope and limitations of this guide

A workspace taxonomy is a workspace policy, not a substitute for scanner-side tuning. A scanner that mislabels a class of findings is a tuning problem at the scanner; the taxonomy is the downstream discipline that turns scanner output into a workspace decision. No closed value list fixes a scanner that lacks coverage for an issue class, and no taxonomy policy substitutes for the analyst judgement an override requires.

Classification claims that depend on whichever scanner happened to fire first almost always understate the operating discipline. Classification claims that decompose into a documented value list per axis, a named owner, a review cadence, an enforced closed list at intake, and a versioned policy are the claims that survive both the audit observation period and the team change.

Frequently Asked Questions

Sources

1. OWASP, OWASP Top 10:2021
2. OWASP, OWASP API Security Top 10:2023
3. OWASP, OWASP Top 10 for LLM Applications 2025
4. OWASP, OWASP Application Security Verification Standard (ASVS) v4
5. MITRE, Common Weakness Enumeration (CWE)
6. MITRE, CWE Research Categories and View Hierarchy
7. MITRE, CAPEC Common Attack Pattern Enumeration and Classification
8. NIST, SP 800-53 Rev. 5 RA-5 Vulnerability Monitoring and Scanning
9. NIST, Cybersecurity Framework (CSF) 2.0
10. ISO/IEC, ISO 27001:2022 Annex A 8.8 Technical Vulnerability Management
11. AICPA, SOC 2 Trust Services Criteria CC7.1 System Monitoring
12. PCI Security Standards Council, PCI DSS v4.0 Requirement 6.3 Vulnerabilities are Identified and Addressed
13. CIS, CIS Controls v8.1 Control 7 Continuous Vulnerability Management
14. NIST, SP 800-30 Rev. 1 Guide for Conducting Risk Assessments
15. SARIF, OASIS Static Analysis Results Interchange Format v2.1.0 (rule and taxonomy elements)
16. SecPortal, Findings Management Feature
17. SecPortal, Bulk Finding Import Feature
18. SecPortal, Activity Log Feature
19. SecPortal, Compliance Tracking Feature
20. SecPortal, Global Search Feature