/mantis-calibrate

Calibration Rules Catalogue

This document defines the 27 calibration sanity triage rules (caps and downgrades) used to calculate the final severity and priority of findings.

Table of Contents

• Core Principle: Marginal Capability
• Category A: Force-Downgrade to LOW (Cap at 2.0 / LOW Priority)
• Category B: Force-Cap to HIGH (Cap at 7.9 / Maximum HIGH Priority)
• Category C: Force-Cap to MEDIUM (Cap at 5.9 / Maximum MEDIUM Priority)

Core Principle: Marginal Capability

The final severity and priority of a finding are strictly bounded by the marginal capability gained by the attacker over their prerequisite position. If the exploit does not grant the attacker significant new control, access, or capabilities beyond what is already inherent to their starting position (or already possessed via legitimate means), the finding must be capped or downgraded.

Category A: Force-Downgrade to LOW (Cap at 2.0 / LOW Priority)

1. repro_failure (Reproduction Failure or Not Attempted) The reproduction failed (repro_status: "failed_to_reproduce"), was not attempted (repro_status: "not_attempted"), or the repro_status field was missing (treated as "not_attempted"), regardless of theoretical production viability.

   Snapshot carve-out (STALE_EVIDENCE): do NOT fire this rule when the finding is NOT_MATCHED to the active snapshot, or its code_paths file is absent under the pinned CODE_ROOT (see the STALE-EVIDENCE guard in mantis-calibrate/SKILL.md). A failed/absent reproduction against drifted or missing code is uninformative; keep the higher score and mark calibration_checklist.repro_failure.outcome = "UNKNOWN" with a STALE_EVIDENCE: reason instead of force-LOW.

2. unreachable_inputs (Unreachable / Uncontrolled Inputs) The finding relies on inputs that are documented as highly unlikely to be user-controlled, and no path from a trust boundary is proven.

3. third_party_reachability (Third-Party / Supply Chain Reachability) Vulnerabilities in third-party libraries (dependency CVEs) where a reachable path from application input to the vulnerable function has not been actively demonstrated.

4. minor_config_hygiene (Minor Configuration Hygiene) Minor deviations from best practice (e.g., slightly loose permissions on internal dirs, lack of modern encryption on low-value internal transport) without a clear exploit path.

5. non_security_critical (Non-Security Critical Components) The finding affects a component or data with no security sensitivity (e.g., public info, signatures on non-security payloads, cosmetic outputs).

6. vague_code_paths (Vague Code Paths / Fragile Assumptions) Relying on unverified assumptions about caller behavior or adjacent system components.

   Snapshot carve-out (STALE_EVIDENCE): do NOT fire this rule when the finding is NOT_MATCHED to the active snapshot, or its code_paths file is absent under the pinned CODE_ROOT. "Caller behavior" re-checked against drifted callers is meaningless; keep the higher score and mark calibration_checklist.vague_code_paths.outcome = "UNKNOWN" with a STALE_EVIDENCE: reason. Also skip this rule for non-source LOCATOR findings.

7. unreliable_triggers (Unreliable/Noisy Triggers) Triggers that are likely to be ignored in practice or indistinguishable from normal operations.

8. prerequisite_shell (Prerequisite Shell Access / Equivalent Primitives) The attacker already possesses local shell access on the target container or host with the same or higher privilege level than the exploit provides, rendering the gained access redundant under the Principle of Marginal Capability (e.g., exploiting a bug to get a standard user shell when already logged in as a standard user, or exploiting a local buffer overflow to run commands as root when already running as root). This does NOT apply to low-to-high privilege escalation (e.g., standard user to root), which should cap at MEDIUM.

9. physical_long_term (Physical Long-Term / Laboratory Access) If the attack requires long-term physical access to the device or specialized laboratory equipment (e.g., fault injection, side-channel analysis, chip decapping). Force-downgrade to LOW (2.0) due to the extreme execution barrier and requirement for physical possession.

10. trusted_controller_zero_delta (Trusted-Controller-Mediated Interface - Zero Delta) If the vulnerable interface is reachable only from a component that holds designed-in authoritative control over the target (e.g., orchestrator->worker, driver->device firmware, protocol master->slave, hypervisor->guest, management plane->data plane node), and the exploit grants zero marginal capability (i.e., the controller could already achieve the identical effect or level of compromise via its standard, legitimate interface), force-downgrade to LOW (2.0). (This generalizes the Standard Host-to-Guest Attacks rule below).

11. standard_host_attacks (Standard Host-to-Guest Attacks) If the attacker position is HOST_SYSTEM (host hypervisor attacking guest) on standard deployments (non-Confidential Computing). Force-downgrade to LOW (2.0) as the host OS/hypervisor already possesses total control over the guest by design, meaning the exploit offers zero marginal capability over the prerequisite position (equivalent primitives). Default assumption: treat as non-Confidential Computing (this rule fires) UNLESS the Threat Model, code path, or finding description explicitly names Confidential Computing, guest enclaves, TEE, SEV, TDX, SGX, or attestation (in which case apply the CC Host Attacks cap-HIGH rule instead).

Category B: Force-Cap to HIGH (Cap at 7.9 / Maximum HIGH Priority)

1. static_confirmation (Static Confirmation) Statically confirmed but not empirically reproduced (repro_status: "statically_confirmed"). Cap likelihood_score at 3, apply 0.8 multiplier to Hazard, and MUST NOT be CRITICAL. Exception: If the finding details (description, history, or reproduction output) include a valid external stack trace, sanitizer trace (e.g. ASan, UBSan, MSan), crash log, or core dump proving the vulnerability was triggered in execution (e.g., in a prior run or by external tools), treat it as empirically reproduced (Likelihood 5) and do not apply this static cap.

   Snapshot carve-out (STALE_EVIDENCE): the trace-lift Exception above MUST NOT be applied when the finding is NOT_MATCHED to the active snapshot, or its code_paths file is absent under the pinned CODE_ROOT — a stack trace / ASan / crash-log captured on a prior snapshot may not correspond to the current code, so treating it as live reproduction would falsely inflate to CRITICAL. In that case KEEP the static HIGH cap in force and mark calibration_checklist.static_confirmation.outcome = "APPLIES" with a STALE_EVIDENCE: reason noting the trace-lift was suppressed. (The base static cap itself is driven by repro_status: "statically_confirmed" from the finding JSON and still applies normally.)

2. strict_xss (Strict XSS Caps) All XSS vulnerabilities. Default to MEDIUM or LOW; cap at HIGH (7.9) only for stored XSS on critical admin pages with zero-click execution for the admin.

3. internal_nested (Internal / Nested Components) Any finding with a Network/Trust Exposure multiplier less than 1.0 (i.e., Internal Component or Privileged Zone). If the calculated score lands in the CRITICAL range, cap the score at 7.9 and downgrade the priority to HIGH. Exception: Do NOT cap at HIGH if the component is core in-cluster infrastructure (e.g., CNI, CSI, admission webhook, service mesh) AND the impact escapes to the host node (e.g., node-root file R/W) or allows cross-tenant escalation. These remain eligible for CRITICAL. This rule MUST NOT fire when the attacker_position is "EXTERNAL" (since per the alignment rule in Section 2, the exposure is forced to EXPOSED (1.0), which precludes this cap).

4. probabilistic_llm (Probabilistic LLM Vectors) Attacks relying on probabilistic LLM behavior (e.g., prompt injection, jailbreaking) to trigger a vulnerability. Cap at HIGH (7.9) and default to MEDIUM or LOW. Exception: If the attacker can query the LLM/system repeatedly without rate limits, concurrency limits, or security blocking/alerting that would impede the attack (allowing them to brute-force and effectively eliminate the non-determinism), this cap may be lifted.

5. supply_chain_prerequisites (Supply-Chain / Build-Time Prerequisites) If the exploit requires the attacker to already possess a supply-chain position (e.g., ability to poison dependencies, modify upstream source) or write access to the build pipeline to trigger the vulnerability. Cap at HIGH (7.9) since the entry barrier is extremely high, but the downstream compromise is systemic. (Force-downgrade to LOW/2.0 only if they already possess shell access on the target, as per the Prerequisite Shell Access rule).

6. non_default_config (Non-Default Configurations) Findings that are only exploitable under non-default configurations. Cap at HIGH (7.9) to reflect the additional configuration barrier.

7. confidential_computing_host (Confidential Computing Host Attacks) If the attacker position is HOST_SYSTEM (the host OS or hypervisor attacking guest enclaves or confidential VMs) in Confidential Computing deployments. Cap at HIGH (7.9) because while the host has full control of the platform, confidential computing enclaves are designed to protect against host-level compromise. (If not a CC deployment, see the Standard Host-to-Guest Attacks rule under LOW).

8. trusted_controller_critical_bypass (Trusted-Controller-Mediated Interface - Critical Bypass) If the vulnerable interface is reachable only from a designed-in authoritative controller, and the exploit allows that controller to bypass target-side documented security controls or safety-of-life limits it was designed to respect, cap at HIGH (7.9). (If the exploit allows lateral reach into a different trust domain or achieves persistence surviving controller re-provisioning, do not cap).

Category C: Force-Cap to MEDIUM (Cap at 5.9 / Maximum MEDIUM Priority)

1. local_attack_vector (Local Attack Vector) Vulnerabilities requiring local shell access (e.g., local privilege escalation, SUID exploitation) without VM escape. (Downgrade to LOW/2.0 if it only affects a single user's isolated data).

2. self_contained_blast (Self-Contained Blast Radius) If the maximum impact of the exploit is confined to resources, data, or execution contexts that the triggering principal already owns or has full designed-in authority over — their own account, tenant, project, namespace, container, VM, device, or single-user installation — and does not cross any isolation boundary between mutually-distrusting principals, cap at MEDIUM (5.9).

   • The exploit may grant genuinely new capability within that domain (e.g., API-user -> shell in their own container), but the deployment's core isolation guarantees to other parties still hold.
   • Do NOT apply this cap if the exploit:
     • reaches another principal's resources (cross-tenant, cross-user, cross-account),
     • touches shared or multi-party infrastructure (shared cache, shared filesystem, operator control plane, co-tenant side-channel),
     • places the attacker's domain upstream of others (build node, CI runner, package registry, model-serving host — i.e., a supply-chain position), or
     • persists in a way that survives the principal's own resource lifecycle and could later affect a different principal reusing that slot.

3. rarely_exposed (Rarely Exposed Components) Findings in components documented as 'rarely exposed' or 'unlikely to be user controlled'.

4. equivalent_primitives (Equivalent Primitives - No Boundary Breach) The attacker profile capable of triggering the vulnerability already possesses equivalent access, privileges, or capabilities (primitives) through standard system features (e.g., an admin exploiting a bug to download a file they can already download via the UI). Because this offers low marginal capability over their prerequisite position, cap at MEDIUM (5.9) to maintain visibility for defense-in-depth cleanup.

5. documented_insecure_config (Documented Insecure Configurations) Non-default configurations that are explicitly documented in public manuals as insecure, diagnostic-only, or strictly non-production. Cap at MEDIUM (5.9).

6. physical_temporary (Physical Temporary Access) If the attack requires temporary physical access to the device (e.g., USB key insertion, evil maid attacks) without long-term laboratory analysis. Cap at MEDIUM (5.9).

7. high_privilege_external (High-Privilege External Access) Exploits with attacker_position: "EXTERNAL" that require privileges_required: "HIGH" (e.g., admin RCE on public portals). Cap at MEDIUM (5.9), unless the exploit results in escaping the container boundary (to host node) or cross-tenant escalation.

8. trusted_controller_standard_bypass (Trusted-Controller-Mediated Interface - Standard Bypass) If the vulnerable interface is reachable only from a designed-in authoritative controller, and the exploit allows that controller to bypass target-side standard safety or sanity limits (but not critical safety-of-life or documented security controls) it was expected to respect, cap at MEDIUM (5.9).