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, and Renovate 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 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 — an OSV consumer registers KernelScan as a distinct vulnerability source and collapses our record into the same finding as NVD's via the alias. (For Dependency-Track, prefer the analyzer plugin below, which uses native CVE identity.)

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

For Dependency-Track, use the open-source KernelScan analyzer plugin — not the OSV mirror. The plugin runs in-process in your DT apiserver, matches the kernel component in each project's SBOM, and reports only the CVEs actually reachable in that kernel's .config, under native CVE-* / NVD identity so findings merge with DT's own NVD records — no duplicates.

Source, docs, and the downloadable JAR: github.com/kernelscan/kernelscan-dt-plugin · latest release.

The OSV mirror is for generic scanners, not Dependency-Track. The tokenized OSV / CycloneDX feed (see the feed docs) still serves OSV-Scanner, Trivy, Grype, and Renovate. DT's own OSV matcher is config-blind and PURL-only — it floods a project with every kernel CVE for the version. The plugin is config-aware and deduplicates against NVD, so we recommend it for DT instead.

Why the plugin

• Config-aware. Reports the CVEs reachable in the running .config, not every CVE for the kernel version — a typical appliance drops from thousands of NVD matches to the few hundred actually reachable.
• Native CVE / NVD identity. Findings carry the plain CVE-… id under source NVD, so they merge with DT's own NVD records — no KSCAN-* duplicates, one audit trail.
• Earlier & wider coverage. Surfaces kernel CVEs before NVD's CPE matching catches up — including LTS-backport cases NVD misses entirely, attributed to the kernelscan analyzer.
• Config-aware triage. A companion VEX push marks the config-gated CVEs Not Affected with the exact CONFIG_* justification, so the audit view is actionable rather than noisy.
• Read-only outbound. The plugin only fetches verdicts from your KernelScan account — it never transmits your SBOM, components, or findings anywhere (see the repo's SECURITY.md).

Step 1 — Install the plugin

Download kernelscan-dt-plugin-<version>.jar from the latest release and mount it into the apiserver's lib/ directory — the apiserver launches with -cp 'dependency-track-apiserver.jar:lib/*', so it is discovered via ServiceLoader at startup:

# docker-compose.yml — apiserver service
volumes:
  - ./plugins/kernelscan-dt-plugin.jar:/opt/owasp/dependency-track/lib/kernelscan-dt-plugin.jar:ro

Restart the apiserver; the analyzer appears under Administration → Analyzers. Requires Dependency-Track 5.0.x (the plugin extension point) and Java 25.

Step 2 — Configure it

1. Under Administration → Analyzers → KernelScan, enable it and paste your account API key (ks_live_…, minted on /account).
2. Your kernels must exist as products in your KernelScan account — that's where the .config and its verdicts live. The analyzer resolves the product by the kernel component's version, or by an explicit kernelscan:product SBOM property when several products share a version.
3. Run vulnerability analysis on a project — the config-reachable kernel CVEs appear as findings, attributed to kernelscan, each linking to its full CVE analysis on kernelscan.io.

Step 3 — Apply the config-aware verdicts (VEX)

DT v5 analyzers produce findings only; analysis states come from VEX imports. Push your product's config-aware VEX to the project (PUT /api/v1/vex) from a small in-network job — the config-gated CVEs are then marked Not Affected with KernelScan's CONFIG_* justification. The repo ships a reference push_vex.py.

Full install, SBOM requirements, product binding, and the two-stage model are documented in the plugin README.

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. One asymmetry to know up front: the web UI's product-less .config upload (the homepage analyze form) has no MCP equivalent — every MCP analyze call goes through create_product, which requires a Basic plan or higher.

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

Nine 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.

Why no full VEX over MCP. A product VEX document is a multi-megabyte artifact (up to 8,000+ vulnerability entries) — far past any sane model-context budget. Over MCP it is served bounded: get_product_vex returns a manifest, list_product_vex_entries returns filtered pages capped at 256 KiB each. The complete CycloneDX document stays on the authenticated REST endpoint GET /api/products/{id}/vex (same ks_live_… key) — the canonical way to retrieve the full artifact; gzip-compressed on the wire since backend#339.

Plan matrix

Heads-up on the analyze flow. The web UI's product-less .config upload (homepage analyze form, available to every registered user including free) has no MCP equivalent. On MCP, the only path through the analysis pipeline is create_product, which is in the heavy rate class — free-tier callers are capped at 0 heavy calls. To run the equivalent of the homepage analyze flow from an agent, a Basic plan or higher is required.

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 — the short way

Claude's connector dialog can sign you in directly, with no key to copy and no config file to edit. Add a custom connector pointing at https://kernelscan.io/mcp, click through to sign in, and approve the request on the KernelScan consent screen. The connector then holds its own credential tied to your account, and you can disconnect it again from /account — the Connected apps list beside your API tokens.

What the connector can and cannot do. An approved connector reaches the MCP tools at your plan's level, plus the two REST endpoints they depend on — the .config upload behind create_product and the full-VEX download behind get_product_vex — and nothing else. It cannot read your password, touch billing, or mint API keys — so revoking it revokes everything it had. Signing out everywhere (or resetting your password) disconnects live connectors too.

Connecting Claude Desktop with an API key

Still supported, and the right choice for a shared or headless setup where nobody is around to click Approve. 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 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. Two factors here are stronger gates than typical hardening: unpriv-escalation-blocked can yield not_affected outright (an unprivileged process literally cannot acquire the kernel capability a local-escalation CVE needs), while mediated-mgmt-plane keeps a compromised management service away from raw kernel APIs (→ mitigates). 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