cme - Common Mitigation Enumeration (CME) — A taxonomy o

项目说明

CME — Common Mitigation Enumeration

A structured taxonomy of defensi controls mapped to C attenuation, served via an MCP (Model Context Protocol) ser by SQLite (single-user) or PostgreSQL (multi-user). Controls are organized in a hierarchical Function/Control structure and support both deterministic (guaranteed metric shifts) and probabilistic (e, conditional) attenuation.

See the MCP ser for the complete tool, resource, and connection guide.

---

Table of Contents

O

Why CME Exists

How It Relates to D3FEND

Architecture

Quick Start

Public Deployment

MCP Server

- How It Runs
- Query Tools (10)
- Curation Tools (3)
- Resources (3)
- Connecting to the Public Server
- Connecting Locally (stdio)
- Connecting to a Self-Hosted HTTP Server
- MCP Inspector (Manual Testing)

Taxonomy Structure

- Tactics
- Categories and Entry Counts
- ID Numbering Con
- C Quick Reference

Database

- Schema
- Seeding
- Querying Directly

JSON Schema

- Entry Structure
- Product Applicability (c)
-

Multi-User Workflow

- Proposing New Entries
- Re and Approving
- Git-Based Team Workflow
- Shared On-Prem Deployment

Examples

- AI Agent Risk Negotiation
- CWE-Based Mitigation Lookup
- CVE Risk Simulation

Static Website

Project Structure

Sources and References

---

O

While CVE identifies specific and CWE identifies classes of weaknesses, CME identifies the defensi that mitigate them.

A CME entry names a defensi for an identified class of weaknesses and products. It records the control's primary effect (pre, detective, or corrective), e maturity, operating conditions, , and typed relationships to other controls and frameworks. CVSS is CME's flagship scoring binding where applicable, not the membership test for a control.

Each CME entry carries:

A unique identifier (e.g., CME-601)

The D3FEND-aligned tactic it belongs to (Harden, Isolate, Detect, Evict, Restore)

An optional function grouping (e.g., selinux, seccomp) linking related controls under a broad capability

The technology layer it operates at (Network, OS/Kernel, Application, Data, Identity) — inherited from the function when grouped

An e state: deterministic ( pre effect), quantified (measured efficacy with probability and e), or unquantified (relevant but not automatically credited)

Optional framework bindings, including C and Temporal, SSVC, ATT&CK, ATLAS, ICS, D3FEND, and SCF

CWE weakness classes it mitigates (e.g., CWE-119, CWE-78)

Machine-executable commands a scanner or agent can run to confirm the control is active

Confidence level, platform applicability, and external references

Why CME Exists

C Scoring is rarely used because it requires manual, subjecti. A security analyst looks at a 9.8 Critical CVE and thinks *"I think our sandbox is pretty good, so I'll mark Confidentiality as Low."* This is a guess.

CME replaces guesswork with e control records. For C pre controls, the process becomes:

> "Asset Ser has CME-301 (SELinux Enforcing) and CME-601 (seccomp) active. The taxonomy defines CME-301 as reducing S:C → S:U and C:H → C:L. The taxonomy defines CME-601 as reducing S:C → S:U and I:H → I:L. The En Score is recalculated deterministically."

This enables:

Automated en scoring by scanners (Wiz, CrowdStrike, Qualys)

AI agent "Risk Negotiations" where agents disco controls and calculate effective risk

Dynamic risk tracking — when a control is removed (EDR goes offline, firewall rule deleted), scores spike automatically

ROI justification — "If we implement CME-402 (FIPS) across the fleet, our a En Risk Score drops by 2.4 points"

How It Relates to D3FEND

MITRE D3FEND is the structural inspiration for the CME taxonomy, but CME di in important ways:

| | D3FEND | CME |
|---|---|---|
| Purpose | Catalog defensi generically | Catalog controls with optional scoring-framework bindings |
| Granularity | Technique-level (e.g., "File Encryption") | Control-level with specific C impact |
| Output | Knowledge graph of defenses | Lookup table for en scoring |
| Relationship | Mapped to ATT&CK offensively | Mapped to CWE root causes + C |
| Control Layer | Not a primary dimension | Core attribute (Network, OS/Kernel, App, Data, Identity) |
| | Not included | Machine-executable commands per entry |

D3FEND's 5 tactic categories (Harden, Detect, Isolate, Decei) are used as the organizational backbone, with Restore added and Decei excluded because it has no defined CME effect model.

D3FEND mappings are preser they exist (e.g., CME-101 ASLR maps to D3FEND D3-SAOR Segment Address Offset Randomization), allowing cross-referencing between the two frameworks.

---

Architecture

The ser two deployment modes, selected :

Single-User Mode (default)

SQLite database, stdio transport. Each client spawns its own ser. No infrastructure required.

Multi-User Mode (Docker Compose)

PostgreSQL database, streamable HTTP transport. One shared ser serves all clients concurrently. Deployed via docker compose up.

---

Quick Start

Single-User (SQLite + stdio)

Multi-User (PostgreSQL + HTTP)

To stop: docker compose down (data persists in the pgdata ).
To reset: docker compose down -v && docker compose up -d.

---

Public Deployment

The CME taxonomy is publicly a at :

Static site — Browse all 119 entries, search by tactic/category/CWE, view C details

MCP server — Connect AI agents and tools to the live CME database at

The site is generated from entry JSON files by build_site.py and served . The MCP server runs as a Docker Compose stack (PostgreSQL + FastMCP) behind an nginx reverse proxy with TLS.

---

MCP Server

How It Runs

The ser two transport modes, controlled by the CME_TRANSPORT en :

stdio (default) — The MCP client (Claude Code, Claude Desktop) spawns the ser on-demand, communicates o/stdout, and tears it down when the session ends. No ports, no daemon, no manual lifecycle management. Best for single-user / local use.

streamable-http — The server runs as a persistent HTTP service on port 8000. Multiple clients connect to the same ser. Best for multi-user / shared deployments. Launch via docker compose up or manually with:

Query Tools

| Tool | Description |
|------|-------------|
| get_cme_entry | Look up a specific CME entry by ID (e.g., CME-601). Returns the full entry with description, C impacts, CWE relationships, commands, and references. |
| search_cme | Search entries by tactic (Harden, Isolate, Detect, Evict, Restore), category (Kernel Hardening, Network Isolation, etc.), control layer (Network, OS/Kernel, Application, Data, Identity), or free-text keyword across names and descriptions. |
| get_mitigations_for_weakness | Given a CWE ID (e.g., CWE-119), returns all CME controls that mitigate that weakness class (memory corruption returns 15+ controls spanning ASLR, NX, SMEP, seccomp, gVisor, and more). |
| get_mitigations_for_c | Given a C string, finds all CME entries whose impacts attenuate metrics that are set to high-se in that . |
| calculate_attenuation | Given a list of acti on a system, aggregates all C modifications. This is the core of CME: deterministic en scoring. |
| simulate_c | The "Risk Negotiation" tool. Feed in a CVE's base score, C string, and active CME controls — get back the modified showing exactly how each metric shifts. |
| list_cme_taxonomy | Returns the full taxonomy hierarchy: all tactics with entry counts, all categories with their tactic, control layer, and counts. |
| get_ | Returns the shell commands a scanner or agent can run to whether a specific control is active on a target system. |
| get_cme_co | Returns aggregate co statistics: CWE IDs covered with counts, C transitions, per-tactic and per-category breakdowns. |
| get_mitigations_for_product | Given a product identifier (CPE, PURL, /product, or platform), finds all CME entries applicable to that product join against c data. The flagship cross-referencing tool for C matching. |

Curation Tools

| Tool | Description |
|------|-------------|
| propose_cme_entry | Draft a new CME entry. Auto-assigns the next a CME-ID in the appropriate range, against the JSON schema, and writes to data/proposals/. Does NOT add to the li until approved. |
| list_proposals | Lists all pending proposals awaiting review. |
| appro | Moves a proposal from data/proposals/ to data/entries/ and inserts it into the li. |

Resources

| Resource URI | Description |
|---|---|
| cme://taxonomy | The full taxonomy structure |
| cme://entry/{cme_id} | A specific CME entry by ID |
| cme://schema | The CME JSON schema |

Connecting to the Public Server

The easiest way to use CME — connect to the hosted instance at cmetaxonomy.org:

Claude Code:

Claude Desktop (claude_desktop_config.json):

Connecting Locally (stdio)

Run the MCP ser from a clone of this repo:

Claude Code:

Claude Desktop (claude_desktop_config.json):

Connecting to a Self-Hosted HTTP Server

When running the server in HTTP mode ( Compose or manually):

Claude Code:

Claude Desktop (claude_desktop_config.json):

MCP Inspector

To test tools interactively outside of a Claude client, use the MCP Inspector:

This launches a web UI at localhost:6274 where you can call all 13 tools and browse resources.

---

Taxonomy Structure

Hierarchy

The taxonomy uses a four-le inspired by NIST CSF 2.0:

Functions group related controls under a shared technology. For example, SELinux has three controls (Enforcing Mode, Confined User Mapping, Booleans) that share a function_id: "selinux". Functions define a default control_layer and d3fend_mapping that controls inherit (controls can o). Standalone controls that are already 1:1 (e.g., ASLR) omit function_id — they implicitly *are* their own function.

The function registry lives in data/functions.json. There are currently 15 functions co SELinux, AppArmor, Seccomp, container runtime, pod security, systemd sandboxing, authentication methods, password policy, session management, authorization controls, origin/CORS, injection pre, input , transport cryptography, and mount option hardening.

Tactics

The taxonomy uses 5 D3FEND-aligned tactics:

| Tactic | Purpose | C |
|--------|---------|-------------|
| Harden | Proactively reduce attack surface or increase exploitation difficulty | Directly modifies base metrics (AC, PR, S, C, I, A) |
| Isolate | Limit blast radius by restricting lateral mo and scope changes | Primarily modifies AV, S, PR |
| Detect | Identify malicious activity (detection alone is a compensating control) | Compensating: AC:L → AC:H when coupled with response |
| Evict | Remove or neutralize acti; patch management | Temporal score reduction |
| Restore | Enable recovery and limit a impact of successful attacks | Primarily modifies A |

Categories and Entry Counts

119 entries in total, broken down by tactic and category:

Control layers: OS/Kernel (50), Application (38), Network (13), Identity (6), Data (2).
Counts drift as entries are added — regenerate them from data/entries/ rather than trusting this snapshot. The list_cme_taxonomy and get_cme_co tools always return li.

ID Numbering Con

Each category is assigned a number band. New IDs are auto-allocated to the next free
slot in the band by propose_cme_entry. The authoritati is _CATEGORY_RANGES
in src/server.py; a category's band runs from its start value up to the next start − 1:

| Starts at | Category |
|-----------|----------|
| CME-101 | Kernel Hardening |
| CME-201 | Network Isolation |
| CME-301 | Mandatory Access Control |
| CME-401 | Cryptographic Controls |
| CME-501 | Filesystem Hardening |
| CME-601 | Syscall & BPF Controls |
| CME-701 | Container Isolation |
| CME-707 | Pri Isolation |
| CME-801 | Credential Hardening |
| CME-901 | Protocol Hardening |
| CME-904 | Application Controls |
| CME-1001 | Runtime Detection |
| CME-1004 | Integrity Detection |
| CME-1101 | Patch Management |
| CME-1201 | Recovery Controls |
| CME-1301 | Application Input |

C Quick Reference

How CME entries modify CVSS v4.0 En metrics:

| Attenuation Type | C Modified | Example CME |
|-----------------|---------------------|-------------|
| Reduce Attack | MAV: N → L or A | CME-201 (Zero Trust), CME-205 (Localhost Bind) |
| Increase Attack Complexity | MAC: L → H | CME-101 (ASLR), CME-401 (Crypto Policy) |
| Increase Pri Required | MPR: N/L → H | CME-801 (MFA), CME-707 (NoNewPri) |
| Reduce Scope | MS: C → U | CME-301 (SELinux), CME-701 (gVisor), CME-601 (seccomp) |
| Reduce Confidentiality Impact | MC: H → L/N | CME-301 (SELinux), CME-204 (IPsec) |
| Reduce Integrity Impact | MI: H → L/N | CME-504 (dm-), CME-601 (seccomp) |
| Reduce A Impact | MA: H → L | CME-704 (cgroups), CME-1201 (Immutable Infra) |

E Scoring Model

CME distinguishes three e states. Only the first two can affect an automated score:

Deterministic — A pre control whose conditions hold and whose C effect is guaranteed. Examples include a correctly enforced noexec mount or a complete protocol disablement.

Quantified — E, conditional effecti with a measured probability. These controls carry:

| Field | Type | Description |
|---|---|---|
| probability | number (0-1) | Measured likelihood the metric shift applies |
| e | string | Citation for the probability ( benchmark, study, test methodology) |
| conditions | string[] | Prerequisites for the probability to hold (rule set , thresholds) |

Unquantified — A relevant control with declared conditions but no measured efficacy. It is returned to humans and agents, but ne an automated score.

The simulate_c and calculate_attenuation tools use conser scoring:

1. Deterministic pass — apply all guaranteed metric shifts (same as before)
2. Quantified adjustment — for metrics not already shifted by deterministic controls, compute combined probability from independently e controls: P(effective) = 1 - Π(1 - Pᵢ)
3. Unquantified context — surface controls without changing the score.

EPSS is intentionally not a framework binding: an asset's local controls do not change a global exploitation prediction.

---

Database

Database Schema

The SQLite database uses a normalized schema with 6 tables:

Indexes on tactic, control_layer, category, function_id, attenuation_type, cwe_id for fast lookups.

Seeding

The database is generated from indi JSON entry files:

Output: data/cme.db (SQLite, generated from 15 functions and 119 entries)

Querying Directly

The database can be queried directly with SQLite for debugging or integration:

---

JSON Schema

Entry Structure

Each CME entry follows the schema at schema/cme-entry.schema.json. The core structure:

New fields:

| Field | Required | Default | Description |
|---|---|---|---|
| function_id | No | — | Links to function registry (data/functions.json). Omit for standalone controls. |
| attenuation_type | No | deterministic | deterministic (guaranteed shift) or probabilistic (e, conditional). |
| control_layer | Conditional | — | Required when function_id is absent. When function_id is present, inherited from the function (can o). |

Probabilistic impact example:

Product Applicability (c)

CME entries can optionally declare which products they apply to using the c field — a structured product identity container that reuses the [CVE 5.x affected[] schema](). This enables the flagship use case: structural join against C to answer "which CME controls help with this CVE on this system?"

#### Schema alignment

| CME field | C | Purpose |
|-----------|---------------|---------|
| c | affected[] | Array of product objects with , product, CPE, PURL, ranges, platforms |
| c | data | Pinned C Format (e.g., "5.2.0") so parsers know which schema to expect |

The c field is required whenever c is present (enforced via dependentRequired).

#### Status semantics

CVE uses status: "affected" | "unaffected" | "unknown" to describe state. CME repurposes the same shape with different semantics:

| CME status | Meaning |
|-----------|---------|
| applicable | This control applies to this product |
| not-applicable | This control does not apply to this product |
| unknown | Applicability has not been determined |

Using distinct string (not reinterpreting "affected") prevents accidental misuse when the same codebase handles both CVE and CME records.

#### Example: CME-101 (ASLR) — cross-platform applicability

The legacy platforms string array (e.g., ["RHEL 9", "Ubuntu 24.04"]) remains for backward compatibility. c is the structured successor — entries without it continue to work in all query paths.

ATT&CK Crosswalk Con

Use ATT&CK as an external crosswalk, not as a replacement for CME controls.

ATT&CK mitigations (Mxxxx) belong in framework_bindings

ATT&CK techniques (Txxxx) belong in co assessments or carefully re relationships

CME remains the source of truth for concrete, , platform-specific controls

ATT&CK mitigation bindings should look like:

Technique-le should be recorded separately from entry identity. Use data/co/ when the claim is "CME covers ATT&CK technique Txxxx under these assumptions" rather than "this CME entry is itself an ATT&CK object." Co assessments now accept target.namespace: "ATT&CK" alongside CWE, CVE, and CAPABILITY.

The repository includes:

data/attack_mitigations_mappings.json — curated ATT&CK-to-CME mapping seeds

scripts/attack_mitigations_to_cme.py — reads ATT&CK STIX and emits binding suggestions for curator review

data/co/CMA-ATTACK-T1021.json and CMA-ATTACK-T0886.json — first technique-le assessments for Remote Services

Example usage:

#### Structural join with C

The get_mitigations_for_product MCP tool performs the structural join. Given a product identifier from a C, it finds all CME entries whose c[] matches:

1. CPE prefix match — most precise, standard in management
2. PURL match — for package-le (npm, PyPI, container images)
3. + product exact match — fallback when CPE/PURL aren't populated
4. platforms o — loosest match, for architecture-specific controls

all entries against the schema:

This checks both data/entries/ and data/proposals/:

Every file passes the JSON schema

Filenames match their cme_id field

function_id (if present) references a valid entry in data/functions.json

control_layer is present when function_id is absent

No duplicate CME-IDs exist within a directory

No proposal reuses an ID that already exists as a li (a leftover from a

hand-appro — appro removes the proposal automatically)

---

Multi-User Workflow

Proposing New Entries

Anyone with access to the MCP server can propose a new entry through natural con. The propose_cme_entry tool:

1. Auto-assigns the next a CME-ID in the appropriate number range
2. the entry against the JSON schema
3. Writes the proposal to data/proposals/CME-XXX.json
4. Does NOT add it to the li

Example :

> "Propose a CME entry for Landlock LSM filesystem sandboxing"

The tool returns the proposed entry with its assigned ID and file path.

Re and Approving

A re can:

1. Call list_proposals to see all pending entries
2. Read and discuss the proposal
3. Call appro("CME-506") to approve

Appro the file from data/proposals/ to data/entries/ and inserts it into the li immediately.

Git-Based Team Workflow

For teams, the data/entries/ directory is the source of truth — one file per CME entry. The recommended flow:

This ensures:

Every new entry is re before going live

Schema catches errors in CI

Full audit trail via git history

Easy rollback by re a commit

Shared On-Prem Deployment

For multiple concurrent users, deploy with Docker Compose:

This starts:
1. PostgreSQL 17 — persistent database with a named
2. Seed container — loads all data/entries/*.json into Postgres, then exits
3. CME MCP Server — HTTP transport on port 8000, serving all clients

All configuration is :

| | Default | Description |
|----------|---------|-------------|
| CME_DB_BACKEND | sqlite | Database backend: sqlite or postgres |
| CME_TRANSPORT | stdio | MCP transport: stdio or streamable-http |
| CME_HTTP_HOST | 0.0.0.0 | HTTP bind address |
| CME_HTTP_PORT | 8000 | HTTP port |
| CME_PG_HOST | localhost | PostgreSQL host |
| CME_PG_PORT | 5432 | PostgreSQL port |
| CME_PG_USER | cme | PostgreSQL user |
| CME_PG_PASSWORD | cme | PostgreSQL password |
| CME_PG_DATABASE | cme | PostgreSQL database name |

The git repo remains the source of truth. In a CI/CD pipeline, on merge:
1. CI runs uv run python -m src. to check all entries
2. CI rebuilds and restarts the seed container to load new entries into the shared Postgres

---

Examples

AI Agent Risk Negotiation

This is the primary use case from the CME proposal — an AI security agent scanning a system discovers a CVE and automatically negotiates the effective risk:

The agent can then report: *"C has a base score of 9.8, but because CME-201 and CME-601 are active on Pod-Alpha, the effective risk is significantly lower. The modified can be fed into a C for the exact en score."*

CWE-Based Mitigation Lookup

When a CVE's root cause is known (e.g., CWE-119 Memory Corruption), query for all applicable mitigations:

CVE Risk Simulation

For a real-world scenario like a Linux kernel eBPF pri escalation:

The effective risk drops dramatically — the attacker needs high pri, high complexity, and cannot escape the process scope.

---

Static Website

The static site at cmetaxonomy.org is generated from entry JSON files:

This reads all data/entries/*.json files and produces HTML pages in docs/:

docs/index.html — searchable index of all entries

docs/entries/CME-XXX.html — indi entry detail pages

docs/by-tactic.html — entries organized by tactic/category

docs/by-cwe.html — CWE-to-CME cross-reference

docs/search.html — full-text search

Templates are in templates/ using Jinja2. To update the public site after adding entries:

---

Project Structure

---

Sources and References

CME Proposal: Common Mitigation Enumeration Proposal (J. West, 2026)

MITRE D3FEND: — Defensi taxonomy (structural inspiration)

Red Hat Security Hardening Guide: RHEL 9 Security Hardening — primary source for Linux controls

CIS Benchmarks: CIS Red Hat Enterprise Linux 9 Benchmark — commands and configuration standards

NIST SP 800-53: Security and Privacy Controls for Information Systems

CVSS v4.0 Specification: FIRST CVSS v4.0 — base metric definitions and en scoring

CVE JSON 5.x Schema: — C Format; c reuses the affected[]/product definition

项目信息

开发语言：Python

Star 数：3

技术要点

该项目属于防护思路方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Common Mitigation Enumeration (CME) — A taxonomy of defensive security controls mapped to deterministic CVSS vector attenuation, with an MCP server展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。