菜单
Calculates the final risk score based on empirical evidence and architectural impact. Use when findings have been fully processed by previous stages and you need to append final risk scores to the finding files. Don't use for discovering new vulnerabilities or writing patches.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/google/mantis --skill mantis-calibrate命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Proactive security advisor and guardrail assistant for secure code development. Use to query threat models, historical vulnerability lineages, verified patch patterns, triaged false positives, and learned trajectory invariants before and during code edits to prevent repeat mistakes. Don't use for automated multi-pass red-team exploitation or fuzzing.
Assesses the production viability of findings, filtering out debug-only features and assertion traps. Use when findings have been validated and you need to confirm they are triggerable in production release builds (with assertions disabled). Don't use for writing reproduction scripts or patches.
Interactively guides the design and implementation of custom deterministic orchestrator harnesses. Use when a user wants to build their own pipeline to wrap and run Mantis skills reliably. Don't use for executing the default pipeline directly.
基于 SOC 职业分类
正在显示 SKILL.md
| name | mantis-calibrate |
| description | Calculates the final risk score based on empirical evidence and architectural impact. Use when findings have been fully processed by previous stages and you need to append final risk scores to the finding files. Don't use for discovering new vulnerabilities or writing patches. |
Risk Analysis Expert. Evaluates confirmed findings against a rigorous risk matrix, taking into account successful reproduction and production viability to produce a final risk score (1-10).
/mantis-calibrateworkspace/findings/*.json (all finding files to load full pipeline state).workspace/kb/THREAT_MODEL.md (if exists, to check threat boundary
overrides and asset criticality).workspace/.mantis_state.json (to track the current loop pass, and to read
active_snapshot — {snapshot_id, snapshot_pinned, root} — for finding
provenance and history stamping; absent ⇒ degraded/today's behavior).impact_score, likelihood_score, availability_tier,
inferred_exposure, attacker_position, mantis_risk_score, priority,
sanity_triage_applied (may begin with STALE_EVIDENCE when the
STALE-EVIDENCE guard suppresses heuristics), calibration_checklist
(entries may carry STALE_EVIDENCE: reasons), outrage_commentary,
executive_summary). Appends a history entry with snapshot provenance
(see history JSON template in the body).workspace/helpers/append_calibrate.py.workspace/findings/.Convert the raw security findings and their empirical results (repro/patch) into a prioritized, actionable risk report.
Execute the calibration as follows:
Locator resolution (findings-only). Calibrate never needs to read target source to compute a score, but some heuristics below may re-inspect code; resolve the code root the same way every stage does. Block A is inlined below:
LOCATOR RESOLUTION (before reading ANY target code or artifact):
0. ROLE: If this skill NEVER reads target source (report, calibrate, reflect),
you are a FINDINGS-ONLY stage: skip steps 2-6; still read active_snapshot from
state for provenance/annotation; NEVER stop merely because a code root is unset.
1. Determine CODE_ROOT, in this priority order:
a. If --target_root is passed on THIS invocation, CODE_ROOT = --target_root.
It is AUTHORITATIVE and OVERRIDES SNAPSHOT_ROOT and the state fallback
(used when a caller hands you a prepared tree, e.g. a patched shadow).
b. Else if --snapshot_root (or SNAPSHOT_ROOT) is passed, use it.
c. Else read state_root/workspace/.mantis_state.json (state_root from
--state_root if passed, else ./workspace/... relative to the current dir)
-> active_snapshot.root / .snapshot_id / .snapshot_pinned.
d. Else (no arg AND no readable active_snapshot): CODE_ROOT = current directory,
treat snapshot_pinned = false (MODE-OFF). Do NOT stop.
2. SENTINEL CHECK (only if snapshot_pinned is true AND you did NOT take path 1a):
verify CODE_ROOT/.mantis_snapshot_id exists and equals SNAPSHOT_ID. If missing
or different -> STOP "snapshot sentinel mismatch". (A --target_root tree (1a) is
deliberately mutated and is sentinel-EXEMPT.)
3. PATH FIELDS:
- SNAPSHOT-RELATIVE (read under CODE_ROOT): code_paths entries; plan target_files
that are file paths. Strip ONLY a trailing ":<digits>". A code_paths entry
containing "://" is a URL/endpoint, NOT a file read. A code_paths entry that is
NOT of the form <existing-path>:<integer> is a non-source LOCATOR
(symbol/offset/endpoint): only check that the artifact/symbol exists; skip ALL
line-range and line-existence logic.
- STATE-RELATIVE (read/write under state_root/workspace, NEVER prefix CODE_ROOT):
kb_references, repro_file_path, reattack_file_path, helper scripts, report
files, and all state/findings JSON.
4. Never WRITE under CODE_ROOT when snapshot_pinned is true. Any command that
compiles, generates, or writes artifacts MUST run in a PRIVATE SHADOW copy
(mktemp -d from CODE_ROOT), never with cwd=CODE_ROOT. Read-only inspection may
cd into CODE_ROOT.
5. VCS-METADATA CARVE-OUT: history-log extraction and any VCS diff/blame command
run in the LIVE repository root (which still has .git/.hg/.repo), NOT CODE_ROOT
(the snapshot copy strips VCS metadata). Do NOT stop merely because CODE_ROOT
lacks .git/.hg/.repo.
6. Every shell command uses ABSOLUTE paths and sets its own working directory on
that call. Do NOT assume the working directory persists between calls.
[!NOTE] CURRENT-PASS CHECK (defensive; the binding guarantee is on the harness per
mantis-pipeline-adapterScenario 2): ifactive_snapshotis present ANDactive_snapshot.pass != state.pass_number, treat the snapshot as STALE for this pass — STOP "stale active_snapshot: pass mismatch" or degrade as HALT (snapshot_pinnedeffectively false: no authoritative verdicts, Block B NOT_MATCHED, reproducenot_attempted). This catches a custom harness that preservedactive_snapshotacross the Stage 15 pass increment without re-pinning. The reference meta-agent re-pins every pass, so this check never fires there. Block B itself cannot detect this (it issnapshot_id-only, notpass-aware).
Snapshot provenance & STALE-EVIDENCE guard (mechanical; do this before scoring):
P0. Read active_snapshot ({snapshot_id, snapshot_pinned, root}) from
state_root/workspace/.mantis_state.json (Block A step 0/1c). NEVER stop if it
is absent — calibrate is a FINDINGS-ONLY stage (Block A step 0).
P1. MODE (single decision for the whole run — branches on active_snapshot
presence, 3-state model): - active_snapshot is ABSENT in state (no --sync
was requested — MODE-OFF = today's default) -> MODE = MODE-OFF. Score exactly
as today: run every heuristic as written, do NOT compute PROVENANCE, do NOT
emit STALE_EVIDENCE, and do NOT emit any HALT/PINNED banners.
(Backward-compatible default path — byte-for-byte today's behavior.) -
active_snapshot IS present AND snapshot_pinned is not exactly true (HALT
mode — the tree raced or could not be pinned) -> MODE = HALT. SNAPSHOT_ID =
active_snapshot.snapshot_id (a live: id). Compute PROVENANCE per P2 below
and fire the STALE-EVIDENCE guard conservatively (same as PINNED for guard
purposes), because findings' locators may be stale. Authoritative verdicts
(VERIFIED_SECURE, failed_to_reproduce, DUPLICATE, FALSE_POSITIVE, NON_VIABLE)
are forbidden this pass. - snapshot_pinned == true -> MODE = PINNED.
SNAPSHOT_ID = active_snapshot.snapshot_id. Full provenance + STALE-EVIDENCE
guard as below.
P2. In MODE = PINNED or HALT, compute PROVENANCE per finding F using Block B's
compare rule: - F.discovery_commit missing OR empty OR the literal "MIXED"
-> NOT_MATCHED. - F.discovery_commit != SNAPSHOT_ID (exact string compare,
no fuzzy) -> NOT_MATCHED. - F.discovery_commit == SNAPSHOT_ID -> MATCHED.
P3. A per-finding heuristic is STALE for F when MODE is PINNED OR HALT AND
either: - PROVENANCE(F) == NOT_MATCHED, OR - the finding's code_paths target
file does NOT exist under CODE_ROOT. (Resolve CODE_ROOT via Block A steps 1 & 3;
strip a trailing :<digits>; read ONLY the pinned root, NEVER the live tree. If
you cannot resolve CODE_ROOT at all, treat the file as absent -> STALE.)
P4. When a heuristic is STALE for F, do NOT apply it; keep the conservative
(pre-adjustment) score; and ensure the literal token STALE_EVIDENCE is the
FIRST token of sanity_triage_applied (add it once, before any UNKNOWN warnings
and any fired-rule list). The four guarded heuristics and their exact STALE
handling are: - Dead-code 0.2 multiplier (Section 2, "Asset Criticality &
Reachability"): do NOT apply the 0.2 reduction; use the multiplier you would
otherwise have. - repro_failure (Section 3 rule): do NOT force-LOW; set
calibration_checklist.repro_failure.outcome = "UNKNOWN", reason beginning
"STALE_EVIDENCE: ". - vague_code_paths (Section 3 rule): do NOT
force-LOW; set calibration_checklist.vague_code_paths.outcome = "UNKNOWN",
reason beginning "STALE_EVIDENCE: ". - static_confirmation trace-lift
(Section 3 rule, its "valid external stack trace/sanitizer…" exception): do NOT
apply the trace-lift; KEEP the static HIGH cap in force (likelihood_score <=
3, 0.8 Hazard multiplier, NOT CRITICAL). Set
calibration_checklist.static_confirmation.outcome = "APPLIES", reason
beginning
"STALE_EVIDENCE: trace-lift suppressed; trace/crash-log may predate the active snapshot; ".
P5. NON-SOURCE finding: if the finding's code_paths entry is a non-source
LOCATOR (contains "://", or is not of the form <path>:<integer> — per Block
A step 3: a symbol / offset / endpoint), SKIP all source-only heuristics for it
— dead-code, file-path/imports/caller-hierarchy exposure inference,
vague_code_paths, and static trace re-inspection — and score from the
finding's DECLARED metadata (attacker_position, privileges_required,
production_viability, repro_status, threat model). A non-source skip is NOT
flagged STALE_EVIDENCE (it is normal, not drift). Non-source findings default
inferred_exposure to "INTERNAL" (0.8) unless the finding/threat-model
declares otherwise.
Load Full Pipeline State:
workspace/findings/ directory. Because the
pipeline appends data to each finding file at each stage, these files
provide the complete picture of each finding's journey (including its id,
reproduction status, and production viability).production_viability is missing, treat it as "CONDITIONAL_VIABLE".repro_status is missing, treat it as "not_attempted".workspace/kb/THREAT_MODEL.md from the Knowledge Base (if it exists)
to evaluate component exposure, trust boundaries, asset criticality, and
any custom Calibration Overrides (e.g., specific threat positions or
caps that should be lifted or customized for the project).--snapshot_root=<active_snapshot.root>,
--snapshot_id=<active_snapshot.snapshot_id>, and
--state_root=<workspace parent> so every subagent resolves the same
CODE_ROOT via Block A. Any code inspection a batch performs (exposure
inference, dead-code, static-trace verification) MUST read through that
CODE_ROOT (the pinned copy), NEVER the live tree, and MUST honor the
STALE-EVIDENCE guard (preamble P3–P4). Findings-only fields (score,
priority, history stamp) are computed from the finding JSON regardless.Calculate Risk Score (1-10): For each unique finding file, calculate the actual technical risk score in a matrix form based on the following formula components, where Hazard = Impact + Likelihood:
Save your updates to the individual finding files. When complete, notify the user.
likelihood_score by 1 or 2 (but not below
1.0) if the exploit path relies on uncommon or non-default usage
patterns. This applies if:
status is FALSE_POSITIVE or NEEDS_RESEARCH, or if
production_viability is NON_VIABLE: Drop this finding completely.
Do not score it or update its file with calibration data.production_viability is VIABLE, CONDITIONAL_VIABLE, or
SAMPLE_OR_TEST:
workspace/kb/THREAT_MODEL.md does not exist or does not mention the
component:
inferred_exposure to
"INTERNAL" (0.8) unless the finding or threat model declares
otherwise. When MODE is PINNED or HALT and the finding is
NOT_MATCHED or its code_paths file is absent under CODE_ROOT, do
NOT lower the exposure multiplier below the declared/default value
on the basis of live re-inspection (keep the conservative, higher
multiplier).inferred_exposure to "INTERNAL" unless there is clear evidence
of direct external exposure (EXPOSED) or deep nested isolation
(PRIVILEGED). Local SUID/LPE binaries should default to
"INTERNAL" exposure.inferred_exposure based on the Network/Trust Exposure
multiplier:
"EXPOSED""INTERNAL""PRIVILEGED"attacker_position from the finding JSON.attacker_position
must represent the outermost boundary that the first untrusted
principal (the ultimate human attacker or external threat actor)
must cross to reach the interface. Do not key on the transport
protocol (e.g., HTTP, gRPC, IPC) or the immediate protocol peer.
localhost or uses local IPC (unix
sockets, pipes, shared memory), the position is "LOCAL", even
if it uses HTTP/TCP under the hood."INTERNAL_NETWORK" (or
"IN_CLUSTER" if restricted to pod-to-pod), even if it is a web
service."EXTERNAL" if the interface is directly
reachable from the public internet."PHYSICAL_TEMPORARY" or "PHYSICAL_LONG_TERM", regardless of
the protocol used."authenticated <role>", "customer with",
"tenant <role>", "Fitbit user" on a public product ->
"EXTERNAL" (with privileges_required: "LOW")."local user", "local shell",
"local access" -> "LOCAL"."peer <role> in same job/cluster/pod",
"co-tenant",
"in-cluster (Kubernetes/container-orchestrator) workload",
-> .availability_tier in
the Threat Model (if missing, default to STANDARD):
LOW_CRITICALITY: Reduce multiplier to 0.5.STANDARD: Reduce multiplier to 0.8.CRITICAL: Keep multiplier at 1.0.code_paths file is absent under the pinned CODE_ROOT) —
drifted code can look "uncalled" spuriously; keep the higher
multiplier and set STALE_EVIDENCE as the first token of
sanity_triage_applied. Any dead-code analysis you do run MUST
inspect the pinned CODE_ROOT, never the live tree. NON-SOURCE
(preamble P5): skip this heuristic entirely for non-source LOCATOR
findings.user_interaction is REQUIRED (e.g., CSRF, Clickjacking, or
convincing a user to open a malicious file), apply a 0.7
multiplier to the Context Multiplier (e.g., if exposure is Internal
(0.8) and user interaction is required, the combined multiplier is
0.8 * 0.7 = 0.56). This ensures these findings are capped below the
CRITICAL threshold.production_viability is SAMPLE_OR_TEST:
0.4, as this would incorrectly increase it if the component's
exposure or dead-code status was already calculated to be lower than
0.4 (e.g. 0.2).executive_summary, explicitly state that this is not a
production bug. The recommendation MUST focus on fixing the
example/test so that developers do not copy insecure patterns into
production code.production_viability is CONDITIONAL_VIABLE:
0.7,
as this would incorrectly increase it if the component's exposure was
already deep/isolated (0.5).executive_summary, document the specific conditions required
for viability.Final Score (Hazard) = (Impact + Likelihood) * Multiplier (Capped at 10.0).
Note on Outrage: In your reasoning, comment on the broader equation Risk = Hazard + Outrage, where the "outrage risk" (e.g., reputational damage, user sentiment fallout) is taken into account. Do not include the outrage factor in the final numerical score.
Critical Sanity Triage (Downgrading & Capping Findings): Before determining the final priority, perform a second-level sanity check on the quality of the finding, its context, and accumulated evidence.
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.
The complete, detailed definitions of the 27 calibration sanity rules are stored in the reference catalogue at Calibration Rules. You MUST evaluate each finding against the 27 rules listed there.
Check if the THREAT_MODEL.md defines any Calibration Overrides (e.g.,
LIFT_CAP: PHYSICAL_LONG_TERM). If an override exists for a finding's
position or component, it takes precedence and lifts the corresponding cap.
Otherwise, the caps and downgrades specified in the reference catalogue (and
general applications of the Marginal Capability principle) override any
upgrades calculated in Section 2 (including the Security Control Bypass
upgrade). You should also apply the general principle to cap or downgrade
other findings that offer low marginal capability. Important: A cap (HIGH
or MEDIUM) only limits the maximum allowed score/priority. It must NOT
upgrade a lower score/priority (e.g., a finding with a score of 5.0 is
naturally MEDIUM and must remain MEDIUM, even if it is subject to a cap at
HIGH).
Precedence & UNKNOWN Rules Policy:
code_paths file is absent under the pinned CODE_ROOT), the following
rules MUST NOT be used to lower or inflate the score from live
re-inspection: repro_failure (do not force-LOW), vague_code_paths (do
not force-LOW), and the static_confirmation trace-lift exception (do
not treat a stale trace/sanitizer/crash-log as live reproduction — KEEP the
static HIGH cap). Also do not apply the Section 2 dead-code 0.2 multiplier
(see Section 2). Keep the conservative score and prepend the literal
token STALE_EVIDENCE as the FIRST token of sanity_triage_applied
(before any Incomplete Calibration (UNKNOWN: …) warnings and before the
fired-rule list). Record the guarded rules in calibration_checklist as
specified in preamble P4 (repro_failure/vague_code_paths -> UNKNOWN
with a STALE_EVIDENCE: reason; static_confirmation -> APPLIES with a
STALE_EVIDENCE: reason noting the trace-lift was suppressed). In MODE ==
MODE-OFF, this bullet does nothing (score as today).UNKNOWN, do
not apply the cap or downgrade (be score-conservative; keep the
score/priority at their higher calculated values). However, mark the
overall calibration as incomplete/provisional by prepending a warning to
the "sanity_triage_applied" string:
"Incomplete Calibration (UNKNOWN: <rule_name>)" (or a semicolon-separated
list of warnings if there are multiple UNKNOWNs). This signals that manual
review is required to resolve the rule status.sanity_triage_applied as a semicolon-separated list, most restrictive
first (e.g., "Local Attack Vector; Internal/Nested"), appended after any
UNKNOWN warnings if present, so the effective cap remains fully auditable.Determine Priority:
privileges_required is NONE) who is not already in an effective
position to compromise the system, AND user_interaction is NONE
(zero-click). This rule is absolute: even if a finding (like a CSI host
escape) has its Section 3 caps lifted, if it requires HIGH privileges at
entry, it MUST NOT be rated CRITICAL and must be capped at HIGH (7.9).
Availability-only findings (DoS) MUST NOT be rated CRITICAL unless the
availability_tier is explicitly documented as CRITICAL in the Threat
Model AND no automatic recovery mechanism (e.g. auto-restart, load balancer
failover) mitigates the impact.Token-Optimized File Updates: To minimize LLM output tokens, do not
re-emit or manually rewrite the entire JSON object in your output. Instead,
write a reusable helper script (e.g.,
workspace/helpers/append_calibrate.py) during your first finding update.
For all subsequent findings, do not regenerate the script; simply execute the
existing helper script with the new parameters to append the required fields
to workspace/findings/<id>.json.
append_calibrate.py MUST be the exact comment
# MANTIS_HELPER_VERSION = 2. Before reusing an existing helper, read its
first line: if the file is absent, OR the first line is not exactly
# MANTIS_HELPER_VERSION = 2 (marker missing or a different integer),
regenerate the helper from scratch (an older helper silently drops the
new snapshot history field and the STALE_EVIDENCE handling). The
regenerated helper MUST be able to write the snapshot key into the
appended history entry and to prepend STALE_EVIDENCE to
sanity_triage_applied. The helper is STATE-RELATIVE
(workspace/helpers/…, Block A step 3) — never write it under CODE_ROOT.Alongside the existing core finding data, explicitly append the following fields to show the matrix breakdown:
"impact_score" (1-5)
"likelihood_score" (1-5)
"availability_tier" (CRITICAL, STANDARD, LOW_CRITICALITY or null)
"inferred_exposure" (EXPOSED, INTERNAL, or PRIVILEGED)
"attacker_position" (preserved from input, or populated from fallback
inference if missing)
"mantis_risk_score" (the final Hazard score)
"priority" (CRITICAL, HIGH, MEDIUM, LOW)
"sanity_triage_applied" (semicolon-separated list, or null). Ordering:
STALE_EVIDENCE first if the finding was STALE (preamble P4); then any
Incomplete Calibration (UNKNOWN: <rule>) warnings; then the Section 3
rules that fired, most-restrictive first. Example:
"STALE_EVIDENCE; Incomplete Calibration (UNKNOWN: physical_long_term); Local Attack Vector".
"calibration_checklist" object containing evaluations for all 27 sanity
caps. Each key in the object maps to the sanity cap rule of the matching
name:
{
"repro_failure": { "outcome": "APPLIES" | "DOES_NOT_APPLY" | "UNKNOWN", "reason": "<string>" },
"unreachable_inputs": { "outcome": "APPLIES" | "DOES_NOT_APPLY" | "UNKNOWN", "reason": "<string>" },
"third_party_reachability": { "outcome": "APPLIES" | "DOES_NOT_APPLY" | "UNKNOWN", "reason": "<string>" },
"minor_config_hygiene": { "outcome": "APPLIES" | "DOES_NOT_APPLY" | "UNKNOWN", "reason"
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
"outrage_commentary" (your reasoning about the outrage factor)
"executive_summary"
An entry to the "history" array:
{
"stage": "calibrate",
"action": "calibrated",
"details": "Calculated risk score as [score] and priority as [priority].[ STALE_EVIDENCE: scored without trusting live-code re-inspection.]",
"pass_number": <current_pass_number>,
"snapshot": "<active_snapshot.snapshot_id, or omit in MODE-OFF>",
"timestamp": "<current_iso8601_timestamp>"
}
"NCCL peer rank""IN_CLUSTER""malicious dependency", "upstream package",
"build-time", "CI pipeline" -> "SUPPLY_CHAIN"."host hypervisor", "host OS",
"hypervisor access" -> "HOST_SYSTEM"."physical access", "fault injection" ->
"PHYSICAL_LONG_TERM" or "PHYSICAL_TEMPORARY" based on
barrier."EXTERNAL": If the component is "EXPOSED", or it's an auth
bypass on a public portal."LOCAL": If it's a local privilege escalation (LPE) or SUID
exploit."IN_CLUSTER": If it targets in-cluster infrastructure (CSI/CNI)
from a pod."HOST_SYSTEM": If the attacker is the hypervisor, host OS, or
an emulated/physical device attacking software it hosts (guest
driver, enclave runtime, firmware target). This enum is strictly
for the outer-to-inner direction. The reverse direction —
guest-to-host (VM escape), sandbox-to-outside, enclave-to-host,
or contained-process-to-container — must be classified as
"LOCAL" (or "IN_CLUSTER" for Kubernetes pod-to-node; a
KVM/hypervisor guest attacking its host is "LOCAL"), never
"HOST_SYSTEM"."PHYSICAL_LONG_TERM" / "PHYSICAL_TEMPORARY": If the bug
description, title, or code path indicates hardware fault
injection, side-channel, evil maid, or USB physical access."SUPPLY_CHAIN": For build-time or dependency modification
prerequisites."INTERNAL_NETWORK": Default fallback for other internal
components.attacker_position is "LOCAL" or "IN_CLUSTER", you
MUST resolve inferred_exposure to "INTERNAL" (using 0.8
multiplier) even if the vulnerable code path resides in a folder
mapped to "EXPOSED" in the Threat Model, unless the exploit
explicitly escapes the container boundary to the host node.attacker_position is "INTERNAL_NETWORK", you MUST
resolve inferred_exposure to at most "INTERNAL" (using 0.8
multiplier or lower) even if the component is mapped to
"EXPOSED" in the Threat Model, as the interface is not directly
reachable from the public internet.attacker_position is "EXTERNAL", you MUST resolve
inferred_exposure to "EXPOSED" (using 1.0 multiplier) even if
the component is mapped to "INTERNAL" or "PRIVILEGED" in the
Threat Model (reflecting that untrusted external inputs reach the
component).For each rule, outcome must be set to:
"APPLIES": if the sanity cap rule applies (fires) to this finding,
capping or downgrading its score/priority. A detailed reason string is
required."DOES_NOT_APPLY": if the sanity cap rule does not apply. The reason
field is optional and may be omitted to optimize tokens."UNKNOWN": if it is unresolved. A detailed reason string is
required.For backward compatibility, the schema also permits "fires": <bool> (with
reason required only if fires is true), but the new "outcome"
format is preferred.