tachi-risk-scoring

Domain knowledge for quantitative risk scoring — four-dimensional scoring model (CVSS 3.1, exploitability, scalability, reachability), CVSS base vector mappings, composite score formulas, severity band thresholds, and governance field derivation rules. Consumed by the risk-scorer agent during scoring pipeline execution.

9 stars

Best use case

tachi-risk-scoring is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Domain knowledge for quantitative risk scoring — four-dimensional scoring model (CVSS 3.1, exploitability, scalability, reachability), CVSS base vector mappings, composite score formulas, severity band thresholds, and governance field derivation rules. Consumed by the risk-scorer agent during scoring pipeline execution.

Teams using tachi-risk-scoring should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/tachi-risk-scoring/SKILL.md --create-dirs "https://raw.githubusercontent.com/davidmatousek/tachi/main/.claude/skills/tachi-risk-scoring/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/tachi-risk-scoring/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How tachi-risk-scoring Compares

Feature / Agenttachi-risk-scoringStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Domain knowledge for quantitative risk scoring — four-dimensional scoring model (CVSS 3.1, exploitability, scalability, reachability), CVSS base vector mappings, composite score formulas, severity band thresholds, and governance field derivation rules. Consumed by the risk-scorer agent during scoring pipeline execution.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# tachi-risk-scoring

Quantitative risk scoring domain knowledge extracted from the tachi risk-scorer agent. This skill provides the reference tables, formulas, and assessment criteria that the risk-scorer uses to transform qualitative threat findings into data-backed risk scores.

## Domain Overview

The risk scoring model assesses each threat finding on four dimensions:

1. **CVSS 3.1 Base Score** (weight: 0.35) -- Inherent vulnerability severity using standard CVSS 3.1 vector analysis, with AI-specific refinements for agentic and LLM threat categories
2. **Exploitability** (weight: 0.30) -- Practical attack feasibility across four sub-dimensions: known techniques, attack complexity, tooling availability, and skill level
3. **Scalability** (weight: 0.15) -- Blast radius and operational economics across four sub-dimensions: scriptability, target scope, resource requirements, and detection difficulty
4. **Reachability** (weight: 0.20) -- Architecture-aware attack surface exposure derived from trust zone position, zone name analysis, and architecture barrier adjustments

Dimensional scores combine into a weighted composite score (0.0-10.0), which maps to a severity band (Critical/High/Medium/Low) that drives governance fields (SLA, disposition, review date).

## AIVSS Relationship

Tachi's four-dimensional composite scoring model **diverges** from OWASP AIVSS at the present time. AIVSS v0.8 (the latest published version, with its public review period opening 2026-04-16) builds on CVSS v4.0 and uses an amplification model in which 10 Agentic AI Risk Factors uplift the CVSS baseline up to a 10.0 ceiling, then a mitigation factor scales the result. Tachi uses CVSS 3.1 and a weighted-sum composite across four operational dimensions (CVSS, Exploitability, Reachability, Scalability). The two formulas produce measurably different scores on the same finding — see [ADR-024](../../../docs/architecture/02_ADRs/ADR-024-owasp-aivss-evaluation.md) for the three-surface comparison (dimensions, formula, severity bands), the worked examples that quantify the divergence, and the re-evaluation trigger tied to AIVSS reaching stable v1.0 with at least one external adopter case study. Severity bands are aligned (Surface C overlap), so downstream consumers (governance, SLA, color coding) behave identically across the two frameworks' outputs.

## Baseline-Aware Scoring Rules

### Score Inheritance

When a finding has `delta_status: UNCHANGED`, all scoring fields are inherited verbatim from the baseline run:

| Field | Treatment | Rationale |
|-------|-----------|-----------|
| `cvss_base` | Copy verbatim | Zero drift guarantee |
| `cvss_vector` | Copy verbatim | Audit consistency |
| `exploitability` | Copy verbatim | Assessment unchanged |
| `scalability` | Copy verbatim | Assessment unchanged |
| `reachability` | Copy verbatim | Architecture unchanged |
| `composite_score` | Copy verbatim | Derived from unchanged inputs |
| `severity_band` | Copy verbatim | Derived from unchanged composite |

**When to inherit**: Only when `delta_status` is `UNCHANGED`. The finding's component, threat, likelihood, and impact must all match the baseline exactly.

**When NOT to inherit**: `UPDATED` findings are re-scored fresh using the full 4-dimensional model. `NEW` findings are scored fresh. `RESOLVED` findings retain last-known scores but are not actively scored.

### Score Source Field

Every scored finding includes `score_source` (per `schemas/risk-scoring.yaml` v1.1):

- `"inherited"` — Scores copied from baseline (UNCHANGED, RESOLVED)
- `"fresh"` — Scores computed this run (NEW, UPDATED)

### Bounded Scoring for NEW Findings

When scoring `NEW` findings from Phase 2 isolated discovery, the CVSS base score is constrained within ±1.0 of the category default. This prevents score drift from LLM non-determinism while still allowing meaningful differentiation between findings in the same category.

**Formula**: `clamped_score = clamp(assessed_score, category_default - 1.0, category_default + 1.0)`, where `clamp(v, min, max)` returns `min` if `v < min`, `max` if `v > max`, and `v` otherwise. The outer bounds are always [0.0, 10.0].

**Applicability**:

| Delta Status | Bounding Applied? | Rationale |
|-------------|-------------------|-----------|
| `NEW` | Yes | No established context — bound to category default to prevent outlier scores |
| `UPDATED` | No | Re-scored fresh with full context — established finding with history |
| `UNCHANGED` | No | Scores inherited verbatim — no scoring occurs |
| `RESOLVED` | No | Scores retained from baseline — no scoring occurs |

**Edge cases at CVSS extremes**:
- Category default 9.5 → bounded range 8.5–10.0 (CVSS ceiling caps upper bound)
- Category default 1.0 → bounded range 0.0–2.0 (CVSS floor caps lower bound)
- Category default 0.5 → bounded range 0.0–1.5 (floor applies)

**When no baseline is present**: Bounding does not apply. All findings are scored without constraints using the standard 4-dimensional model.

### First Run Behavior

When no baseline is present, all findings receive `score_source: "fresh"` and are scored using the standard 4-dimensional model. No behavioral change from pre-baseline pipeline.

### Governance Field Persistence

When scoring findings with `delta_status` from a baseline-aware run, governance fields follow carry-forward rules to preserve human-assigned values across pipeline runs.

**Core principle**: `risk_owner` is a human-assigned field and is **never** auto-overwritten by the scoring pipeline. SLA and disposition are only recalculated when the severity band changes.

**Carry-forward by delta status**:

| Delta Status | risk_owner | remediation_sla | risk_disposition | review_date |
|-------------|-----------|-----------------|-----------------|-------------|
| `UNCHANGED` | Preserve from baseline | Preserve from baseline | Preserve from baseline | Preserve from baseline |
| `UPDATED` (same band) | Preserve from baseline | Preserve from baseline | Preserve from baseline | Preserve from baseline |
| `UPDATED` (band changed) | Preserve from baseline | Recalculate per new band | Recalculate per new band | Today + new SLA |
| `NEW` | `"Unassigned"` | Per severity mapping | Per severity mapping | Today + SLA |
| `RESOLVED` | Preserve from baseline | Preserve from baseline | Preserve from baseline | Preserve from baseline |

**SLA recalculation trigger**: Compare the baseline severity band to the current severity band. If different, recalculate `remediation_sla` and `review_date` using the new band's mappings. The `risk_disposition` threshold is: Critical/High → `"Mitigate"`, Medium/Low → `"Review"`.

**Baseline governance detection**: Parse the baseline `risk-scores.md` governance fields by matching on finding ID. If baseline `risk-scores.md` is unavailable, assign fresh governance fields for all findings (graceful degradation).

## Loading Table

Reference files are loaded on-demand by the risk-scorer agent at specific workflow phases using the Read tool (per ADR-002).

| Reference | File | Load When |
|-----------|------|-----------|
| Scoring Dimensions | `references/scoring-dimensions.md` | Entering exploitability or scalability assessment phases (Sections 4-5) |
| CVSS Vectors | `references/cvss-vectors.md` | Entering CVSS 3.1 base scoring phase (Section 3) |
| Severity Bands | `references/severity-bands.md` | Entering composite calculation or governance field generation phases (Sections 7-8) |
| Trust Zones | `references/trust-zones.md` | Entering trust zone extraction phase (Section 2) |
| Reachability Analysis | `references/reachability-analysis.md` | Entering reachability assessment phase (Section 6) |
| Output Formatting | `references/output-formatting.md` | Entering markdown output generation phase (Section 9) |

Related Skills

tachi-threat-reporting

9
from davidmatousek/tachi

Domain knowledge for narrative threat report generation — executive summary structure, architecture overview patterns, per-category narrative templates, attack tree construction rules with Mermaid syntax, and reference attack tree examples. Consumed by the threat-report agent during report generation.

tachi-shared

9
from davidmatousek/tachi

Shared reference files consumed by multiple tachi agents. Contains canonical definitions for severity bands, STRIDE+AI categories, and finding format that serve as the single source of truth across the pipeline. Agents Read individual reference files on-demand rather than maintaining inline copies.

tachi-report-assembly

9
from davidmatousek/tachi

Domain knowledge for PDF security report assembly — artifact detection patterns with tier selection rules, Typst data variable contract with type specifications and image path resolution, and brand asset handling with logo location and fallback rules. Consumed by the report-assembler agent during report generation.

tachi-orchestration

9
from davidmatousek/tachi

Domain knowledge for the tachi orchestrator agent: input format detection, DFD classification, trust boundary notation, STRIDE-per-Element dispatch rules, coverage requirements per component type, coverage matrix model, SARIF 2.1.0 generation specification, output schema tables for threats.md, baseline correlation, structural validation checklist, and error handling templates. Loaded on-demand by the orchestrator during specific pipeline phases.

tachi-infographics

9
from davidmatousek/tachi

Domain knowledge for threat infographic generation — infographic specification formats, template-specific section layouts (Baseball Card, System Architecture, Risk Funnel), Gemini API prompt construction rules, and visual design system tokens. Consumed by the threat-infographic agent during specification and image generation.

tachi-control-analysis

9
from davidmatousek/tachi

Domain knowledge for compensating controls analysis — control category definitions with detection patterns, evidence criteria with effectiveness classification, and residual risk calculation with recommendation generation. Loaded on-demand by the control-analyzer agent during codebase scanning and risk assessment phases.

~aod-status

9
from davidmatousek/tachi

On-demand backlog snapshot and lifecycle stage summary. Regenerates BACKLOG.md from GitHub Issues and displays item counts per stage. Use this skill when you need to check backlog status, view stage counts, regenerate BACKLOG.md, or get a lifecycle overview.

~aod-spec

9
from davidmatousek/tachi

Validates specification completeness and quality by checking for mandatory sections, [NEEDS CLARIFICATION] markers, testable criteria, and clear scope boundaries. Use this skill when you need to check if spec is complete, validate specifications, review spec.md, or check specification quality. Ensures specifications are ready for architecture and implementation phases.

~aod-score

9
from davidmatousek/tachi

Re-score an existing idea's ICE rating when circumstances change. Use this skill when you need to re-evaluate ideas, update ICE scores, change idea priority, or re-assess deferred ideas.

~aod-run

9
from davidmatousek/tachi

Full lifecycle orchestrator that chains all 6 AOD stages (Discover, Define, Plan, Build, Deliver, Document) with disk-persisted state for session resilience and governance gates at every boundary. Use this skill when you need to run the full lifecycle, orchestrate stages, resume orchestration, or check orchestration status.

~aod-project-plan

9
from davidmatousek/tachi

Validates architecture documentation completeness by checking for technology stack, API specifications, database schema, security architecture, and alignment with feature specification. Use this skill when you need to check if plan.md is complete before implementation, validate architecture documentation, or review technical plans for completeness.

~aod-plan

9
from davidmatousek/tachi

Plan stage orchestrator that runs all three Plan sub-steps (spec → project-plan → tasks) in sequence with governance gates. Stops on rejection, continues through approvals. Use this skill when you need to run the full Plan stage, navigate planning sub-steps, or resume after a rejection.