How KernelScan works

Where the data comes from

KernelScan is a continuous pipeline. Every new CVE published by the Linux kernel CNA is ingested, enriched, mapped, and re-published — directly off kernel.org, well ahead of when the same CVE eventually surfaces in NVD-driven tools.

Merge logic preserves fields per source — NVD doesn't overwrite kernel.org branch fixes, kernel.org doesn't overwrite NVD CVSS. Re-running an importer is always safe; it upserts.

The Linux kernel community publishes CVEs weeks ahead of NVD enrichment. KernelScan rides that pipeline directly so your scanners see kernel CVEs as soon as upstream does — not a month later.

CVSS scoring & the gap KernelScan fills

Severity scores (CVSS) are how the rest of the software industry decides what to patch first, what counts as "critical", and which CVEs trip a regulatory threshold. Kernel CVEs sit in an awkward position: the upstream community has principled reasons to refuse to score them, the body that would normally fill the gap (NVD) is chronically backlogged, and downstream consumers still need a number. KernelScan is where that compromise is reconciled.

Why the Linux kernel community doesn't score CVEs

kernel.org operates as a CNA — it assigns CVE IDs, publishes structured records, and tracks fixes per LTS branch. It explicitly does not assign CVSS scores, by policy. The reasoning, articulated repeatedly by kernel maintainers, comes down to three points:

• Severity is heavily context-dependent in the kernel. A use-after-free in a rarely-built USB driver is a fundamentally different attack surface from one in core memory management or networking — but a single CVSS score doesn't carry that context. Encoding it honestly per-CVE is impossible without knowing the consumer's build and deployment.
• The kernel ships fixes per CVE, not severity assessments. Maintainers focus on producing correct, minimal patches and stable-branch backports. Adding a CVSS triage step at the CNA level would slow CVE publication and create false precision the community explicitly doesn't endorse.
• CVSS encourages selective patching. The kernel community's stance is that everything fixable should be fixed on a stable branch — not that customers should be triaged into "High" vs "Low" buckets and gamble on the low end. A single number tends to push consumers in exactly the opposite direction.

The result: every kernel CVE arrives at downstream consumers with no severity, no vector, no CWE — just the description, the affected ranges, and the fix.

Why NVD enrichment is slow

NVD has historically been the institution that filled the scoring gap — NIST analysts manually triage each CVE to add CVSS, CWE, and CPE data. That model has run into hard scaling problems:

• Every record is hand-triaged. A small analyst team is responsible for the entire CVE corpus, across every ecosystem. Throughput is gated on people, not pipelines.
• The kernel firehose is hostile to that model. kernel.org's CNA assigns thousands of CVEs per year — orders of magnitude more than any other major CNA — and the rate is rising as the community gets more aggressive with assignment.
• NVD has publicly acknowledged its backlog. Lengthy delays are common; some records sit in awaiting analysis indefinitely. For a manufacturer relying solely on NVD, the kernel is effectively a blind spot during the window between CNA publication and NIST analysis.

But commercial product developers still need a score

Whatever the merits of the upstream position, here's how vulnerability management actually runs in industry:

• SBOM scanners and vulnerability platforms are CVSS-keyed. Filters, alerts, dashboards, and reporting all sort by severity. An unscored CVE is effectively invisible to most workflows.
• Compliance regimes reference severity thresholds. CRA's "severe vulnerability" reporting trigger, CISA's KEV catalog with its 14-day federal patch deadline, internal patch SLAs ("all High and Critical within X days") — they all depend on a score being present.
• Customer security questionnaires and audits ask for it. "How many High-severity CVEs are open in your product?" is the standard form. "Unscored" is not an acceptable answer.
• Engineering prioritization needs a comparable metric. Without a number, every CVE looks the same; with one, teams can rank and plan releases.

The kernel community's principled refusal to score is defensible. The commercial software supply chain's need for a score is real. The two positions are incompatible — and waiting weeks for NVD isn't a viable answer when a CRA reporting clock starts ticking the moment a vulnerability is publicly known.

How KernelScan steps in

KernelScan computes a CVSS v3.1 score — vector, base score, severity rating, and a matched CWE — for every kernel CVE while NVD enrichment is pending. The score is derived from the published CVE record, the fix patch, and the affected subsystem context. Every record is stamped so the score's provenance is unambiguous:

• NVD's score, when it eventually lands, is preserved. KernelScan's calculated score lives in a namespaced field, and the canonical NVD score takes precedence in scanner workflows that pick one source per scalar (Dependency-Track among them). KernelScan's score surfaces when — and only when — there is no NVD score yet.
• Per-LTS-branch fix tracking is published alongside the score. Severity is one signal; knowing exactly which stable branches contain the fix and which don't is what turns "patch the High ones" into a concrete release plan.
• Provenance and license travel with every record. Source organization (KernelScan / NVD / kernel.org), CC-BY-4.0 license, and machine-readable attribution — so audit trails and SBOM artefacts can show exactly where each piece of data came from.

The compromise: the upstream community keeps its principled position and is never asked to produce a number it can't honestly defend; manufacturers get a score that exists at the moment the CVE is published, not weeks later when NVD catches up.

Live CVE feed (OSV + CycloneDX)

KernelScan re-publishes the entire kernel CVE corpus as a public, machine-readable feed in two formats. This is the "NVD lag killer for kernel CVEs" — subscribers see new kernel CVEs the same day they land instead of the same month.

Two formats

• OSV 1.6 — what Trivy, Grype, OSV-Scanner, Renovate, and Dependency-Track's OSV mirror consume natively.
• CycloneDX 1.6 VDR (Vulnerability Disclosure Report) — native to Dependency-Track and richer for our AI-extended fields.

Endpoints

Two parallel surfaces — Bearer-authenticated for scripts and CI, and tokenized URLs for tools like Dependency-Track that don't forward Authorization headers.

Tier semantics

The same URL serves every tier; the body changes based on the authenticating account.

Per-CVE lookups (/feed/osv/CVE-2024-XXXX.json) are unrestricted at every tier — a free account can always look up any specific CVE by ID. Only the bulk endpoints are windowed.

CVE IDs and aliasing

OSV records use a KernelScan-namespaced ID (KSCAN-CVE-2024-1086) and carry the canonical CVE ID in aliases. This mirrors how GHSA records relate to CVE — Dependency-Track registers KernelScan as a distinct vulnerability source and collapses our record into the same finding as NVD's via the alias. One row per CVE in the findings view, both sources visible, one audit trail.

CycloneDX VDR records use the canonical CVE-… ID directly; CDX has no equivalent of OSV's namespace-id model.

License

Feed contents are CC-BY-4.0. Free for redistribution, commercial use, and integration into SBOM / vulnerability scanning pipelines. Attribution travels in-band on every record so downstream tools surface it automatically.

Setting up Dependency-Track

The fastest path from a self-hosted Dependency-Track instance to fresh kernel CVEs is to configure KernelScan as DT's OSV mirror. KernelScan publishes a curated ecosystems.txt so DT's admin UI shows KernelScan as a first-class ecosystem checkbox alongside PyPI, npm, Debian, etc.

Why bother

• OSV's stock Linux stream is empirically broken. Sample-checked counts show under 1% coverage of the kernel.org CNA's 2024 corpus. KernelScan ships the missing records.
• Earlier kernel CVEs. KernelScan re-publishes weeks ahead of when the same CVE lands in NVD-driven scanners.
• Per-LTS-branch fix tracking. One OSV range per LTS branch (mainline, 6.6, 6.1, …) so DT's affected-version matcher gets data NVD doesn't ship.
• No bandwidth tax for the rest of OSV. Tick PyPI in DT and KernelScan returns a 302 to Google's bucket — DT pulls directly. KernelScan never proxies the bytes; your token never reaches Google.

Step 1 — Generate a tokenized URL

DT 4.x doesn't forward Authorization headers to its OSV mirror loader, so KernelScan issues a per-user URL-embedded token (kf_pub_…). On /account, click Generate URL in the Dependency-Track URL card. Copy it immediately — it's shown exactly once. KernelScan stores only the hash; if you lose it, click Rotate URL.

Step 2 — Verify it works

URL='https://kernelscan.io/feed/t/kf_pub_…/osv/KernelScan/all.zip'
curl -sS -o /tmp/kscan.zip -w 'HTTP %{http_code}, %{size_download} bytes\n' "$URL"
unzip -l /tmp/kscan.zip | tail -1   # ~13K KSCAN-CVE-*.json files

Invalid tokens return 404 (never 401) so the URL space can't be enumerated.

Step 3 — Configure Dependency-Track

1. Sign in to DT as an admin.
2. Open Administration → Vulnerability Sources → OSV.
3. Set the OSV Mirror URL to the /osv/ base of your token URL: https://kernelscan.io/feed/t/<your-token>/osv/
4. Save, then reload — DT fetches our ecosystems.txt and re-populates the ecosystem list. KernelScan appears at the top.
5. Tick KernelScan + any other ecosystems your SBOMs need.
6. Set sync cadence to ≥ 60 minutes. Faster polling buys nothing — KernelScan re-publishes upstream changes promptly — and risks throttling.
7. Click Mirror OSV to trigger an immediate sync.

Step 4 — Verify ingestion

After DT's first sync completes, open a known kernel CVE in DT (one that already had an NVD entry is a safe choice). You should see:

• Title — the canonical CVE id (e.g. KSCAN-CVE-2024-1086). KernelScan deliberately doesn't synthesise summaries from description prose, matching NVD / osv.dev convention so DT's title column stays clean.
• Source — KernelScan appears alongside NVD in the sources list. Per-record package.ecosystem remains Linux so DT's component matcher works unchanged.
• Severity / CVSS — DT picks one source per scalar field by precedence, so an NVD score will usually win. Where NVD has no score yet, KernelScan's AI-calculated CVSS surfaces instead.
• Affected ranges — multiple ranges. KernelScan contributes one per LTS branch; the Affected Version Attribution view shows which source supplied each.
• References — kernel.org patch URLs, the KernelScan landing page for the CVE, and vendor advisories alongside NVD's references.

For a stronger signal, pick a CVE that is in cvelistV5 but not yet in NVD. The DT finding only exists thanks to KernelScan — without this integration it would only show up after NVD enrichment landed weeks later.

Throughput & throttling

Each tokenized URL is rate-shaped per-token. Normal state serves at 2 MB/s — the 19 MB OSV mirror zip in ~10 seconds. If a misconfigured DT polls aggressively (> 60 requests/hour), the URL flips to 64 KB/s until the customer rotates. Recovery is rotation-only by design — auto-recovery against a broken poll loop just oscillates.

The Account page shows the current state in real time (yellow banner when throttled). HTTP responses also carry X-KernelScan-Feed-Throttled and X-KernelScan-Feed-Requests-Hour so external monitoring can pick the state up. To recover after a throttle event, click Rotate URL on /account, then update DT's mirror URL to the new value — the old URL stops working immediately.

Operational notes

• One active URL per account. Generating or rotating produces a fresh URL and atomically invalidates the previous one. There is no multi-token mode — if you need separate mirrors for staging and prod DT instances, mint them under separate accounts.
• Rotation cadence. No hard requirement, but rotate periodically as you would any long-lived credential. Generate → update DT's mirror URL → DT re-syncs cleanly.
• Revocation. Click Revoke on /account to invalidate the URL without minting a replacement. DT's next sync attempt returns 404.
• One alias per record. KernelScan ships a KSCAN-CVE-… id with the canonical CVE id in aliases. That single alias is what lets DT collapse our record into the same finding as NVD's. Make sure your DT instance has alias sync enabled for the OSV source — otherwise you get two findings per CVE.
• CI / scripts use a different credential. The URL token (kf_pub_…) is read-only, scoped to feed access, and throughput-shaped — meant for tools that can't send Authorization headers. CI scripts and your own automation should use a Bearer API key (ks_live_…) against the flat URLs instead. The two are minted independently and rotate independently.

Troubleshooting

MCP endpoint — KernelScan for agents

KernelScan is a service for humans and for agents. The web UI and the REST API are how people interact; the Model Context Protocol endpoint at /mcp is how Claude Desktop, Cursor, and any other MCP-speaking client interact. Same database, same tier rules, same per-user API keys — just a different entry point.

Plug your KernelScan account into your AI tooling and ask things like "which of my products have unfixed KEV CVEs this month?" or "summarise the high-severity kernel CVEs published in Q1 affecting the BPF subsystem". The agent calls KernelScan tools directly and answers from your live data — no copy-paste, no screenshots, no stale exports.

What you can do over MCP

Eight tools cover the main read and write paths. Read tools work for every plan (free callers see only CVEs published more than 60 days ago, mirroring how the public feed is windowed). Write tools require a paid plan and run the same analysis pipeline as the web app.

* Free callers get a 60-day publish lag on CVE reads — the same window the public feed applies to bulk endpoints, applied here to search_cves and get_cve.

Plan matrix

Authentication

Every request carries the same ks_live_… API key the REST surface accepts:

Authorization: Bearer ks_live_<your_personal_api_key>

Mint or revoke keys on /account. Validation is hash-based — KernelScan only stores the SHA-256; the full key is shown exactly once. JWT browser sessions and tokenised feed URLs (kf_pub_…) are not accepted on /mcp — only the API-key surface, so MCP traffic is consistently identifiable.

Connecting Claude Desktop

Add a server entry to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, equivalent path on Windows / Linux):

{
  "mcpServers": {
    "kernelscan": {
      "transport": "http",
      "url": "https://kernelscan.io/mcp",
      "headers": {
        "Authorization": "Bearer ks_live_..."
      }
    }
  }
}

Restart Claude Desktop. The KernelScan tools appear in the tool picker. First-time check: ask "Use the KernelScan whoami tool" — the response shows your plan and quota, confirming auth is working.

Connecting Cursor and other MCP clients

Any client speaking Streamable HTTP MCP works. Point it at https://kernelscan.io/mcp with the same Bearer header. The server advertises a KernelScan server name on the initialize handshake.

Verification

For a bare-metal smoke check outside any agent, use @modelcontextprotocol/inspector:

npx @modelcontextprotocol/inspector
# In the UI:
#   Transport:  HTTP
#   URL:        https://kernelscan.io/mcp
#   Header:     Authorization: Bearer ks_live_...

Expected: whoami returns your account state, the eight tools above are listed, and a free-tier get_cve call against a CVE published in the last 60 days returns not found. A get_product call against a product_id belonging to another user also returns not found — never a permission error and never the product itself — so existence isn't leaked across accounts.

Rate limits — bounded by class, per user

MCP tools are grouped into three cost classes, with per-user limits scaled to your plan. The whoami tool returns your current limits.

When a limit trips, the tool error tells the agent how many seconds to back off — well-behaved clients pace themselves automatically. search_cves additionally enforces a 3-200 character query length to avoid pathological full-table scans.

Why this exists

Vulnerability triage is a natural fit for agents: the inputs are structured, the questions are repetitive, and the people asking them ("did anything ship this month I need to patch?") often don't speak CVE-CVSS-CWE fluently. An MCP endpoint lets KernelScan plug straight into the agent workstation — Claude Desktop, Cursor, Continue, your in-house tool — without anyone writing a wrapper integration. The same ks_live_… key works everywhere, the same tier rules apply, the same data is served. KernelScan for humans, KernelScan for agents.

CVE → CONFIG_* mapper

The mapper is the deterministic engine that decides "this CVE is not_affected because CONFIG_FOO is disabled in your build". No AI involved — it's pure Makefile and git diff parsing.

The algorithm

1. Parse all kernel Makefiles (per series + patch level) to build a file → CONFIG_* map. The mapper understands the whole vocabulary: obj-$(CONFIG_FOO) += bar.o, subdirectory gating (obj-$(CONFIG_X) += subdir/), conditional descents, and Kbuild fragments.
2. For each CVE with a fix commit, run git diff-tree to enumerate the changed .c files.
3. Trace each changed file back through the Makefile rules and any subdirectory gating to collect the CONFIG_* options that gate it into the build.
4. Resolve kconfig dependency chains: CONFIG_A depends on B depends on C — if C is off, A is unreachable too.
5. Produce a DNF expression ("disjunctive normal form" — sums of products) over CONFIG_* options. A typical expression looks like (CONFIG_NETFILTER && CONFIG_NF_CONNTRACK) || CONFIG_BRIDGE_NETFILTER.

How exclusion works at analysis time

When you upload a .config, the engine evaluates each CVE's DNF expression against your enabled symbols:

• Expression evaluates true → CVE is exploitable (the vulnerable code is in the build).
• Expression evaluates false → CVE is not_affected with justification code_not_present (CycloneDX standard).
• No mapping exists for this CVE in this series — typical for very recent CVEs the mapper hasn't processed yet, or CVEs that touch core code with no CONFIG_* guard → in_triage.

Per-series, per-patch-level

The mapper runs once per kernel series (e.g. 6.6.x, 6.12.x) and stores the mapping per patch level. Makefile rules drift between series — a config option that gates foo.c in 6.1 may have been renamed or the file moved by 6.12. Per-series storage keeps the mapping precise.

100% deterministic. No model, no probability — given the same kernel source tree and the same fix commit, the mapper produces the same DNF expression every time.

Three-layer VEX analysis

VEX (Vulnerability Exploitability eXchange) is the standard for asserting "this CVE does not apply to me, here's why". KernelScan emits CycloneDX 1.6 VEX with full per-CVE provenance.

Per-CVE statuses

What's in the VEX file

• Components — the kernel as an SBOM component, with version, architecture, and the .config hash.
• Vulnerabilities — every relevant CVE with description, references, CVSS scores, CWE.
• Analysis blocks — per-CVE: state, justification (e.g. code_not_present), and response recommendations.
• Detail — the human-readable reasoning. For Layer 1: which CONFIG_* were missing. For Layer 2: the LLM's argument referencing your factors.
• Properties — kernelscan:engine_version, kernelscan:config_hash, kernelscan:factor_set_hash, attribution.

Layer 2 verdicts (Pro tier)

When a product has security factors, the LLM produces one of four verdicts per (CVE, factor combination):

Security factor taxonomy

The factor taxonomy is what makes KernelScan more than a CVE list. It is a structured way to describe your specific product — where it lives, what it can be touched with, what runs on it, who interacts with it — so that each kernel CVE can be evaluated against your reality and not against an abstract worst case. This section is your modelling guide. Read it before you fill in the New Product Wizard.

Why deployment context decides reachability

The same kernel runs on a public-kiosk payment terminal, a sealed datacenter appliance, a residential router, an industrial controller, and a connected car. The same kernel CVE has wildly different real-world impact across those products. A use-after-free in a USB driver is a critical issue on a publicly-accessible kiosk and a near-non-issue on a sealed appliance in a locked cabinet. Severity scores don't capture this; deployment context does.

KernelScan asks two questions for every CVE:

1. Is the vulnerable code in the build? Answered deterministically by the config mapper — a function of your .config.
2. Can a real-world attacker actually reach it on your product? Answered by your factor taxonomy. This is what this section is about.

If the answer to (1) is no, the CVE is not_affected immediately, no matter what factors you set. If the answer to (1) is yes, the factor taxonomy decides what happens next.

The four verdict outcomes

For each CVE that survives the config check, KernelScan produces one of four verdicts based on your factors:

Reasoning about the threat actor, not the slugs

Verdicts always argue about which kind of attacker a CVE requires — local user, network attacker, physically adjacent person, USB-wielding visitor, malicious tenant, supply-chain insider — and whether your product's factors permit that actor to plausibly exist near the device. A CVE that needs physical USB access is not_affected on a sealed appliance in a locked datacenter cage because no actor at that exposure tier can reach the port. The reasoning is about the threat model the CVE describes, not about whether usb-enclosure happens to be in your slug list.

This is why honest factor selection matters more than checking every box. Over-stating exposure — selecting Wi-Fi when there is no radio, exposed USB when ports are sealed, internet-facing when the device is on a private LAN — produces conservative but useless assessments where everything stays exploitable. Under-stating exposure produces a comfortable VEX that doesn't survive an audit. Be precise, the way you would be in front of a regulator.

Scoping: which factors apply to which CVE

Most CVEs only intersect with a subset of the taxonomy. A Wi-Fi management-frame CVE has nothing to say about CAN bus exposure; a CAN bus CVE has nothing to say about Wi-Fi. KernelScan narrows each CVE to the categories that actually bear on its threat model before producing a verdict — a USB driver CVE looks at physical interfaces and user access; a TCP stack CVE looks at network exposure and hardening. You don't need to worry about this scoping yourself. Fill out every category that genuinely applies to your product; the system will use only the parts that are relevant to each CVE.

The 10 categories at a glance

The remaining subsections walk through each category in detail. Every factor lists what it actually means and when you should select it for your product.

1. Deployment Environment

The single biggest determinant of which threat actors can plausibly exist near the device. A residential gateway, a hospital infusion pump, and a roadside cabinet face different attacker populations even if they ship the same kernel. Pick the option that best describes the typical install location for the product. If the product ships into multiple environments, model the worst realistic one — that is the deployment your VEX has to defend.

2. Physical Protection

Pairs with Deployment Environment. Once a plausible attacker is near the device, the question is what stands between them and the actual interfaces. Sealed-and-locked is the strongest combination; tamper-evident-only is forensic value, not prevention. Pick exactly one — the weakest barrier wins. A locked cabinet around an open chassis is still effectively "locked cabinet"; a sealed enclosure not in a cabinet is still effectively "sealed".

Interface exposure tiers — the same port at three different risk levels

The next three categories all describe physical interfaces, but split them into three exposure tiers because the same kind of port has fundamentally different attack-surface implications depending on where it sits. A USB port on a PCB header inside a sealed enclosure in a locked cabinet is not the same threat as a USB port on a public kiosk's faceplate.

Be deliberate. If your product has Ethernet on the back panel and Ethernet running into the field on a different connector, both apply. If a USB port is on the chassis but behind a screwed-on faceplate, model it as enclosure-tier and select the appropriate Physical Protection.

3. Interfaces: On PCB (internal)

Interfaces only reachable by opening the device. CVEs in subsystem drivers — JTAG, USB, serial, peripheral buses — become near-irrelevant for products with strong Physical Protection if the corresponding interface only exists at this tier. Select what is physically present on the board, even if you do not advertise it.

4. Interfaces: On Device Enclosure

Chassis-level interfaces inside whatever physical security perimeter applies. A chassis USB port in a locked datacenter cabinet is reachable only by operators; the same port on a desktop appliance in a corporate office is reachable by anyone who walks into the room. The category captures presence; Deployment Environment + Physical Protection captures who can actually reach it.

5. Interfaces: Exposed Beyond Perimeter

Interfaces accessible without crossing any physical security boundary. This is the most attacker-favourable tier — Physical Protection cannot mitigate it because there is, by definition, no protection. The presence of an exposed-tier interface generally turns a "sealed appliance, not_affected" verdict into "exploitable" for any CVE in the corresponding driver. Be honest here: a kiosk USB port behind a removable cover is still usb-exposed; OBD-II in a vehicle is can-exposed regardless of how the vehicle is otherwise secured.

6. Network Exposure

The network reachability surface — distinct from the physical Ethernet interface tier. Network-stack CVEs (TCP, IP, IPsec, NFS, …) are dominated by this category. An air-gapped device is immune to entire CVE classes regardless of which network drivers are compiled in; an internet-facing bridge router is the worst case. Select the actual reachability of the device in production, not what the lab prototype could do.

7. Wireless

Radios attached to the device. Wireless-stack CVEs (Wi-Fi management frames, Bluetooth pairing, BLE GATT, NFC, baseband-adjacent kernel code) are gated on the corresponding radio being present and active. A device without a Wi-Fi radio is immune to Wi-Fi-stack CVEs even if CONFIG_CFG80211 is compiled in. Select only what is physically present and operational.

8. Execution Context

What runs on the device and who can put code on it. Privilege-escalation CVEs require an attacker who can already execute code; container-escape CVEs require a hostile container; hypervisor-escape CVEs require a hostile VM. A bare-metal appliance with no untrusted users gives an attacker no foothold to escalate from; a multi-tenant container host is the polar opposite. Select all that apply — these are not mutually exclusive.

9. Security Hardening

Active mitigations that change exploitability rather than reachability. Hardening rarely turns a CVE from exploitable to not_affected; it more often turns it into mitigates — the CVE remains theoretically exploitable but the practical bar is raised. KASLR raises the cost of memory-disclosure CVEs; SELinux can block lateral movement after initial compromise; secure boot constrains persistence. Select honestly — a feature compiled in but not enforced doesn't count.

10. User Access

Who can interact with the system, how, and at what privilege level. Most local-attacker kernel CVEs require an attacker with at least an unprivileged shell. An appliance with no interactive users gives them no starting point; an SSH-listening server with operator accounts is a different threat model entirely. Pick all that apply.

Industrial interfaces — cross-tier reference

Kernel-supported industrial buses appear in multiple interface-tier categories so they can be modelled at the right exposure level. Use this table to find the right slug for your bus + exposure combination:

Modelling principles in summary

• Be precise about exposure tier. The same port at three tiers produces three different verdicts. Model what is actually true for the shipping product.
• Pick the worst realistic deployment. If the same product ships into multiple environments, model the most exposed one. Your VEX has to defend that case.
• Don't pad the hardening list. "Compiled in but not enforced" doesn't count as enforcing. Be honest the way an auditor would be.
• Treat absence honestly. If a radio isn't physically present, leave the wireless factors empty. Adding factors "just in case" produces conservative-but-meaningless verdicts.
• Update when the product changes. A firmware release that disables a previously-shipped radio, hardens defaults, or seals an enclosure changes the factor model. Re-run the assessment.

FAQ