Why mapping matters more than the findings list

A raw findings export answers an engineer's question: what is wrong, where. A reviewer has a different question: which of my controls does this evidence, and which does it leave open? Translating findings into framework categories is tedious by hand and easy to get wrong in both directions. Under-mapping throws away evidence you already have. Over-mapping is worse: a dashboard that shows "OWASP A03 Injection: no issues" because a passive scanner never tested for injection is a false statement an auditor will find.

The rule that keeps a mapping defensible is simple: map a finding only where the framework text supports it, and mark every category the tool cannot observe as not assessed.

OWASP Top 10

The OWASP Top 10 (2021) is the edition many questionnaires and contracts still cite, and it is the one Attack Surface Scan's compliance view uses. An outside view evidences five of the ten categories and cannot assess the other five:

CategoryExternal evidence
A01 Broken Access ControlPartial: CORS policies that let any site read authenticated responses
A02 Cryptographic FailuresMissing HTTPS enforcement, old TLS versions, weak or invalid certificates, forms and mixed content over HTTP
A03 InjectionNot assessed: needs attack payloads
A04 Insecure DesignNot assessed: needs a design review
A05 Security MisconfigurationMissing security headers, exposed ports and services, version banners, dangling DNS
A06 Vulnerable and Outdated ComponentsCVE matches and end-of-life software, from announced versions
A07 Identification and Authentication FailuresNot assessed: brute force, password and session handling need testing from inside (login forms over HTTP are reported under A02, where OWASP files cleartext credentials)
A08 Software and Data Integrity FailuresThird-party scripts without integrity checks
A09 Security Logging and Monitoring FailuresNot assessed: internal
A10 Server-Side Request ForgeryNot assessed: needs active testing

OWASP published a 2025 edition that reorders and renames several categories (vulnerable components broadened into A03 Software Supply Chain Failures, for example). If your reviewer asks for 2025, the evidence is the same; the category labels change.

PCI DSS 4.0

The current text is PCI DSS v4.0.1; v4.0 was retired at the end of 2024, and the limited revision kept the requirement numbers below unchanged. PCI DSS is the framework where scope honesty matters most, because it has its own external scanning requirement (11.3.2): scans at least once every three months by an Approved Scanning Vendor (ASV). No monitoring tool that is not an ASV produces that artifact. What external monitoring does evidence is a set of specific requirements between scans:

  • 4.2.1: strong cryptography protecting cardholder data (PAN) over open, public networks, with certificates confirmed valid and not expired or revoked (TLS findings, forms over HTTP, expiry warnings on hosts in your payment flow).
  • 1.2.5 and 2.2.4: only approved, necessary ports and services exposed (open-port findings), with 2.2.5 and 2.2.7 for cleartext protocols and unencrypted remote administration.
  • 5.4.1: anti-phishing mechanisms, where the guidance names SPF, DKIM and DMARC.
  • 6.3.1 and 6.3.3: vulnerabilities identified, ranked and patched (CVE matches), and 12.3.4 for end-of-life technology.
  • 6.4.3: payment page scripts authorized, their integrity assured and inventoried. The guidance lists subresource integrity (SRI) and a Content Security Policy among the integrity methods, so scripts without SRI and a missing CSP are the external evidence. See the privacy checks guide for what an external crawl can and cannot show here.
  • 8.3.2: strong cryptography renders authentication factors unreadable in transmission and storage (login forms over HTTP cover the transmission half).

CIS Controls v8

The CIS Critical Security Controls are organized as safeguards, and an external view touches a handful directly: 1.1 (enterprise asset inventory, for dangling DNS left behind by decommissioned assets), 2.2 (supported software), 3.10 (encrypt sensitive data in transit), 4.1, 4.4 and 4.8 (secure configuration, firewalling, unnecessary services), 7.7 (remediate detected vulnerabilities), 9.5 (implement DMARC), 16.2 (a way for outsiders to report vulnerabilities, which is what security.txt provides) and 16.5 (up-to-date third-party components).

The safeguard numbers are the same in v8 and the current v8.1. One nuance worth raising before your assessor does: safeguard 7.6 asks for automated vulnerability scans of externally exposed assets, monthly or more often (the original v8 wording also called for a SCAP-compliant tool; v8.1 dropped that). A passive monitor matches the versions your hosts announce against known CVEs rather than probing for the flaws, so treat its output as supporting evidence for 7.6 rather than the control itself.

CWE and CISA KEV

CWE gives each mapped finding a standard name for its underlying weakness: CWE-319 for cleartext transmission, CWE-1395 for depending on a vulnerable component, CWE-353 for a missing integrity check. It is the vocabulary secure development programs and some customer questionnaires use. CVE findings also inherit the CWE that NVD assigns to the specific vulnerability.

The CISA KEV catalog is less a framework than a priority list. For US federal agencies, BOD 26-04 (June 2026, replacing BOD 22-01) makes KEV status one of the factors that set how fast a fix is due. Reviewers elsewhere ask for it by name too: "do you have anything on KEV exposed to the internet?" The answer should be a filtered list, not a paragraph. For how KEV and EPSS feed prioritization, see prioritizing vulnerabilities by exploitation.

What should stay unmapped

Some useful checks have no defensible framework clause behind them: registrar locks, CAA records and blocklist listings, for example. Forcing them into a category inflates coverage and invites questions you cannot answer. Leave them out of the framework view; they still belong in your findings and your risk register. Informational findings, which describe the estate rather than a failing control, should not map either.

How this works in Attack Surface Scan

The Compliance page has a tab per framework: Evidence, OWASP Top 10 (2021), CWE, Known exploited (CISA KEV), Privacy (GDPR), CIS v8 and PCI DSS. Each category shows one of four statuses (Action needed, No issues found, Risk accepted or Not assessed) and drills down to the hosts and findings behind it. The mapping is static per finding ID, plus dynamic tags on vulnerability findings (CISA-KEV, CWE-<n>). Framework views are on every plan and stay readable after a subscription lapses. Full detail is on Compliance frameworks and evidence.

The CSV an auditor can filter

The findings export carries the mapping as columns next to each finding: owasp_top10_2021, cwe, cis_v8, pci_dss_4, privacy and cisa_kev, alongside host, severity, finding ID, remediation, evidence, triage state and scan date. Multiple values in a cell are joined with a semicolon, so a reviewer can filter to "everything evidencing PCI 4.2.1" in a spreadsheet without asking you to re-cut the data. The same references come back on every finding from the REST API on Growth and above.

The evidence PDF

A mapping shows posture today. An audit asks whether the control operated across a period. The evidence pack leads with cadence and coverage (scans performed, distinct weeks covered, first and latest scan per domain, score trend), then summarizes current posture by framework. Every PDF is dated, and reports are kept for a year, so "what did it look like in March?" is a download. The companion article on SOC 2 and ISO 27001 evidence covers which controls that pack is usually filed against.

Risk acceptance is evidence too

A finding you have decided to live with should not vanish from the mapping. Accepting a risk with a reason and a review date (at most a year) turns it into Risk accepted in the framework view and resurfaces it when the date passes. That record, who accepted what and until when, is exactly what an assessor asks for when a sampled finding is still open.

Scope, stated plainly

  • This is evidence for the external rows of a controls matrix, not a certification and not a compliance program.
  • It is not a penetration test and not a PCI ASV scan.
  • Findings come from passive checks on hosts under domains you have verified; categories that need active or internal testing are shown as not assessed.

Frequently asked questions

Can an external scan cover the whole OWASP Top 10?

No. Injection, insecure design, logging and monitoring failures, and SSRF need active testing, code or design review, or internal visibility, and so does most of identification and authentication (A07). An honest external mapping marks those categories as not assessed rather than passed, and covers the rest from TLS, header, service, component and page findings.

Does external monitoring replace a PCI ASV scan?

No. PCI DSS requires quarterly external vulnerability scans by an Approved Scanning Vendor, and only an ASV can produce that report. Continuous external monitoring evidences other requirements between those scans, such as 4.2.1 for cryptography in transit, 5.4.1 for anti-phishing and 6.4.3 for payment page scripts.

Which CIS Controls v8 safeguards can external scanning evidence?

Mainly 3.10 (encryption in transit), 4.1, 4.4 and 4.8 (configuration and exposed services), 7.7 (remediating vulnerabilities), 9.5 (DMARC), 16.2 (vulnerability reporting) and 16.5 (third-party components), plus 1.1 and 2.2. The numbers are the same in v8.1. Safeguard 7.6 calls for automated vulnerability scans of externally exposed assets, so passive monitoring is supporting evidence there rather than the control itself.

Which OWASP Top 10 edition should I map to?

Use the one your auditor, contract or questionnaire cites. Many still reference 2021; OWASP has since published a 2025 edition with reordered categories. The underlying findings do not change, only the labels they are reported under.

Sources