ultrasec

ultrasec — 推測ではなく根拠に基づく、ファイル横断型セキュリティ監査

エンジンの根拠とカバレッジの制限については、engine-evidenceをお読みください。

ultrasecは、信頼できないデータが関数やファイル間をどのように移動するかを推論し、その後コードと照合して各候補を検証することで、脆弱性を見つけます。決定論的で依存関係ゼロのエンジンが担うのは、リンクグラフ、候補となるsource→sinkパス、スキャナーの実行、証拠パケットといった機械的な作業です。セキュリティ上の推論、つまりどのフローが実在し悪用可能かを判断し、ツールが見落とす巧妙なバグを見つけ、検証するのは、あなたです。

基本ルール：

1. 記憶ではなく、証拠に基づいて推論してください。 dossierに示された実際のコードから各検出事項を判断し、指定の引用形式で[file:line]と記載してください。引用した場所が解決できない検出事項は、checkでREJECTされます。行番号を捏造しないでください。
2. エンジンが見つけるのは候補です。判断するのはあなたです。 列挙される汚染パスは決定論的で、再現率を重視しているため、設計上、多くの誤検知を含みます。バグと判断する前に、到達可能性と悪用可能性を確認してください：references/adjudication.md。
3. 保守的に判断してください。 高またはクリティカルの検出事項をdismissするのは、根拠を明示して確実に反証できる場合に限ります：references/dismissal-brocards.md。確信が持てない場合はneeds-humanとします。積極的な自動抑制は、実際のバグを見逃すことになります。
4. ツールを使い、その先まで調べてください。 インストール済みのスキャナー（tools）を実行して出力をトリアージし、意味的な推論によってのみ見つかる問題（認可／IDOR、ビジネスロジック、認証、暗号、競合状態）を追加してください：references/attack-classes.md。個人データについては、どこへ送られ、どのくらいの期間保持されるかという別の問いを検討します：references/privacy-and-data-protection.md。
5. 悪用できるものだけを報告してください。 すべての検出事項には、具体的な攻撃者のシナリオ（誰が・何を送るか・何を得るか）が必要です。「潜在的に」では不十分です。別のレイヤーがすでに防いでいる問題は、検出事項ではなく強化に関する注記です：references/severity-and-discipline.md。
6. コードはREADし、CVEはTRIAGEします。 アドバイザリは優先順位付きの一覧です。リスクの高い順に対応し、基準に達したら止め、残りはopenのままにします。コード候補はファイルを開いてのみ判断できるため、自分のコードにHIGH／CRITICALの未判定項目がある状態では、決してrenderしないでください。renderするとレポートにDRAFTの印が付きます。--surface codeで分けてください。

エンジンの実行

scan --require-tools a,bでスキャナーを必須にします（autoに追加されます。対象を絞ったスキャンでは、そのスキャナーのみが対象です）。完了ポリシーを参照してください。実行に成功しても、安全性が証明されるわけではありません。

コミット済みの、依存関係のない単一バンドルです。npm installもAPIキーも必要ありません。

絶対パスを使用してください。 <skill-dir>/scripts/ultrasec.mjsを一度解決し、サブエージェントにも絶対パスを渡してください。インストール済みスキルはプロジェクトの外にあり、サブエージェントのcwdが異なる場合があります。以下では、ultrasecはそのパスを指します。

ULTRASEC="<skill-dir>/scripts/ultrasec.mjs"     # then: node "$ULTRASEC" <command>

--helpにはすべてのコマンドが表示されます。ほとんどのコマンドは--jsonを受け付けます。終了コードは統一されています。0 成功 · 1 ゲート失敗 · 2 使用法／実行時エラー。すべてのフラグ、デフォルト値、成果物については、references/commands.mdを参照してください。

チートシート

ultrasec audit   --repo . --out .ultrasec       # ONE command → .ultrasec/REPORT.md, nothing else kept
  # --html (REPORT.html) · --full (exhaustive annexes) · --keep-work (keep the JSON worklists)
  # --powered <cli> / --council "<reviewer:model,…>" (opt-in agent calls) · scan flags pass through
ultrasec tools                                  # which scanners are installed (+ --upgrade)
ultrasec map     --repo . --out .ultrasec       # cheap attack-surface recon; no taint, no network
ultrasec context --repo . --out .ultrasec       # scaffold → you author .ultrasec/CONTEXT.md
ultrasec scan    --repo . --out .ultrasec       # graph + cross-file taint + tools → the dossier
  # focus:  --scope <dir> --include/--exclude <glob> --max-files N --gitignore
  #         --include-vendored (audit node_modules/.venv/dist too — pruned by default)
  # budget: --budget quick|standard|thorough  --max-candidates N  --max-depth N
  # again:  --diff origin/main --merge --resume        # incremental, folds into one run
  # recall: --sinks (orphan sinks: calls AND assignments)  --log-hygiene  --blame
  #         --no-env-sources (drop env-rooted flows)  --strict-scope (drop cross-function-in-file)
  # net:    --offline / --no-enrich (no EPSS/KEV)      --docker (scanners without installing)
ultrasec paths   --run .ultrasec                # the candidate chains  (--kind sql --min-severity high)
  # --surface code|supply|deps|code+supply|all  # YOUR code · secrets+CI/IaC · advisories  (also triage/verify/orchestrate)
ultrasec dossier <id> --run .ultrasec           # ONE finding: enclosing function, callers, route, guards, sanitizers
  # --brief; a,b,c                              # compact packet; a comma list = one family
ultrasec graph   <file|symbol> --run .ultrasec  # cross-file links into/out of a node
ultrasec assumptions --run .ultrasec            # what each unit trusts that NOTHING enforces (--apply)
ultrasec triage  --run .ultrasec                # cheap noise|keep fast-lane, low/medium only (--apply TRIAGE.json)
ultrasec guards  --run .ultrasec                # entry point × auth guard — the MISSING check (--apply)
  # --lens throttle                             # …and the MISSING rate limit
ultrasec investigate --run .ultrasec            # hunt authz/logic  (--apply INVESTIGATE.json)
ultrasec verify  --run .ultrasec                # adversarial worklist → write verdicts.json
ultrasec verify  --apply verdicts.json --run .ultrasec       # a file, comma-list, DIRECTORY, or -
  # any --apply: refused rows are listed with their reason; --strict exits 1 on any
ultrasec revalidate --run .ultrasec             # git-history FP cut  (--apply REVALIDATE.json)
ultrasec variants   --run .ultrasec             # where ELSE this root cause appears (--apply)
ultrasec coverage --run .ultrasec               # what was NOT looked at: counts (--full matrix, --write)
  # standard: --standard asvs|owasp-top10|owasp-api-top10|masvs|cwe-top25   (default asvs)
ultrasec check   --run .ultrasec --semantic     # THE GATE: grounded + adjudicated; advisories never block
ultrasec narrative --run .ultrasec              # → you author NARRATIVE.json
ultrasec render  --run .ultrasec                # THE report: REPORT.md (--html), folds NARRATIVE.json
  # an unread HIGH/CRITICAL CODE candidate ⇒ DRAFT banner; exit 0, --strict exits 1
ultrasec implement --run .ultrasec              # remediation-PRD draft → the `to-prd` skill
ultrasec run     --repo . --out .ultrasec       # sequence every stage (ZERO external calls)
ultrasec orchestrate --run .ultrasec --phase verify   # multi-agent fan-out: families, ≤12 agents
ultrasec council --run .ultrasec                # other model families review a HEAD snapshot (--models, --apply)
ultrasec logs    ./var/log --out .ultrasec-logs # blue team: forensics over EXISTING log files
  # detections: --sigma → ultrasec-logs.sigma.yml (SIEM pack, like variants→semgrep)
  # anywhere: --report out.md|html|json (archive this output)  --no-journal  --md (worklist briefs)
ultrasec import  findings.json --run .ultrasec  # ingest a deepsec export as candidates
ultrasec clean   --run .ultrasec                # keeps REPORT, findings, manifest, CONTEXT, NARRATIVE
ultrasec probe   https://you-own-this --i-own-this   # DYNAMIC live-site posture → PROBE.json (isolated)
  # probe: --allow-private (localhost)  --graphql  --deep (exposed files)  --timeout ms  --strict
ultrasec route   app.apk | ./bin/x.so | https://host # OUT-OF-SCOPE triage → methodology + tools (advisory)
  # route: URL → probe · source/dir → scan · else → jadx/radare2/wireshark/… (--write ROUTE.md)

状況別のルート

1. 「このリポジトリを監査して」 — audit --keep-work を実行し、JSON の作業リストを判定してから、render、clean を実行します。 1 つの REPORT.md を作成します。references/audit-playbook.md。
2. 「徹底的に」／高い保証水準が必要 — クラスとエントリーポイントごとに分解し、アナライザーと懐疑的なサブエージェントに作業を振り分け、問題がなくなるまでループします。 references/deep-audit-playbook.md。
3. 「プラットフォーム全体を監査して」／スキャンするには大きすぎるリポジトリ — まず map を実行し、次に予算内で対象ごとに詳細を調べ、1 つの実行に統合します。CI で増分 --diff 再監査を行う場合も、同じループを使います。 references/scale-audit-playbook.md。
4. 「これは本物？」／「誤検知に見える」 — FP の分類、反証の基準、エクスプロイトの証明の書き方、具体例： references/adjudication.md。
5. 「ほかに何を調べるべき？」 — taint 解析では到達できないクラスを、メカニズムのレベルで確認します： references/attack-classes.md。スタックのどこに潜むか： references/frameworks.md。最初に適用する観点： references/hunting-heuristics.md。
6. 「依存関係／シークレット／CI を確認して」 — トリアージの手順、シークレットへの対応、GitHub Actions、IaC： references/supply-chain.md。スキャナー一式： references/tools.md。コーディングエージェントにリポジトリ独自のイベントデータを渡すワークフローは、それ自体が独自のクラスであり、scan で監査します： references/agentic-ci.md。 6b. 「このライブラリ／SDK／API を監査して」 — 問いが変わります。脆弱なのかではなく、この設計によって、安全な使い方より安全でない使い方が容易になっていないかを確認します。 investigate --lens sharp-edges · references/sharp-edges.md。
7. 「これはどれくらい深刻？」 — 具体的な比較ペアで調整する深刻度の基準： references/severity-and-discipline.md。
8. 「アクセス／認証ログを分析して」／「誰かに攻撃された？」 — ブルーチーム向け、読み取り専用、専用の調査資料： references/log-forensics-playbook.md。
9. 「自律的に実行して」 — 外部エージェント CLI に作業リストを埋めてもらいます（オプトイン方式で、キーはその CLI に保存されます）： references/powered-mode.md。
10. 「セカンドオピニオン」／ほかのモデル — council を使います。スナップショットをブラインドレビューした後、悪魔の代弁者が確認します。--apply によって引用が必須になります： references/deep-audit-playbook.md。

ワークフロー（標準的な監査）

根拠と引用を示した監査結果を返します。実行途中で制御を返してはいけません。各ステージは追加で実行する形式なので、タスクに必要なものを選んで使います。どのステージも同じ流れです。エンジンが作業リストを出力し、それを記入してから、--apply で保守的なルールに基づいて結果を取り込みます。各作業リストの正確な JSON 形式： references/schemas.md。

1. コンテキストを整える (最も効果が大きい)。context --repo <dir> --out <run> を実行し、次に <run>/CONTEXT.md を作成します。目的、信頼モデル、認証方式、フレームワークによる保護、深刻度の調整に使う比較対象アプリを記載します。Exposure: と Criticality: を追加します（リスクスコアの算出に使われます）。各信頼境界に対して STRIDE／LINDDUN 分析を行います。これにより、ツールに任せるのではなく、何を調べるかを決定します： references/threat-modeling.md。 references/context-playbook.md。

2. スキャンする。 scan --repo <dir> --out <run> を実行します。より広くカバーするため、先に tools を実行してください（最も効果が大きいのは Trivy です）。ユーザーの同意を得たうえで tools --upgrade を実行します（--dry-run でプレビューできます）。

3. 実行が実際に行われたことを確認します — 検出結果を1つでも読む前に、<run>/manifest.json を開きます。

   • extraction.ast: false ⇒ tree-sitter を利用できず、regex 抽出器が実行されています — クロスファイルフローの半分にも満たない範囲です。文法を用意して再実行するか、その旨を明記します。
   • truncation が 0 以外 ⇒ 上限に達しています。--max-candidates を増やすか、--scope を絞り込みます。
   • toolStatus ⇒ 実行されたスキャナー、スキップされたスキャナー（カバレッジの欠落）、失敗したスキャナーが分かります。
   • weaknessClasses ⇒ degraded／not-covered のセルは、investigate が調査するギャップです。 resolutionGaps ⇒ 追跡されなかったインポートです。

   劣化した実行を、完全な実行として報告してはいけません。

4. データではなくインデックスを読みます。 <run>/DOSSIER.md には、候補ごとに順位付けされた1行が記載されています。findings.json や .work/graph.json を全体読み込みしてはいけません。代わりに、paths、dossier <id> --brief を使い、*.todo.json の作業リストを直接埋めます（--md は、ほかの誰も必要としない人間向けの概要を追加します）。

5. トリアージ（任意）。 triage --run <run> で noise|keep をマークし、triage --apply を実行します。low／medium／info のみを一覧表示します。high／critical はそのまま検証に進みます。

6. 証拠に基づいて判定します — まず CODE。 全体の open ティアではなく、paths --surface code を調査します。依存関係の半分は、CVE ごとのドシエではなく、リストとしてトリアージします（references/supply-chain.md）。dossier <id> では、両端の関数全体と 到達できる主体 が分かります — 対象範囲内のルートファイル、呼び出し元、認証とレート制限のマーカー、パス付近のサニタイザーです。次を確認します。SOURCE は攻撃者が制御できますか？値はすべてのホップを通じて変更されずに SINK に到達しますか？サニタイザーや認可ガードはありますか？到達した値で SINK を悪用できますか — PoC を書けますか？ 検出結果ごとではなく、ファミリーごとに時間を割り当てます。1回の確認で、折りたたまれた候補全体を判断できます（元になった実行では、242件の候補が62件でした）。references/adjudication.md。

6b. 前提をマッピングします (ハンティングの前に)。assumptions --run <run> — ユニットごとに、保証すること（引用付き）と、依存しているものの何によっても強制されていないことを確認します。nothing-found は、どこにも記録されていない何かを信頼しているコードを示します。危険な呼び出しがなく、単一画面では問題が見つからず、エンジンにも見えません。--apply で手掛かりを investigate に渡します。 references/assumptions-playbook.md。

6c. 欠落しているガードを列挙します。 guards --run <run> は、対象範囲内に認証マーカーがない状態でリクエストデータを読み取るすべてのハンドラーを一覧表示します — チェックが存在しなければ追跡する行もないため、クラス taint では到達できない対象です。マーカーはあくまで 候補 です。ハンドラーを読み、オブジェクトに触れる前に認可をガードしていることを確認します。--apply で unguarded を引用付きの検出結果に変換します。もう一度 --lens throttle を付けて実行すると、もう一方の欠落、つまりレート制限のないハンドラーが一覧表示されます。認証ルートには別のフラグが付きます。どちらのレンズでも、どこにもマーカーがないことは N 件の検出結果ではなく、アーキテクチャ上の1つの事実です。CONTEXT.md に一度だけ回答として記録します — プロジェクトのガードヘルパーも同様です。例：Auth markers: assertServerSession。 references/hunting-heuristics.md。

7. エンジンが列挙できないものをハントします。 investigate --run <run> は攻撃対象領域をリージョンごとにグループ化します。アクセス制御の不備／IDOR、ビジネスロジック、認証／セッション／JWT、暗号、競合状態、機能の悪用、攻撃の連鎖を見つけ、根拠に基づく Discovery[] を出力します — 取り込み前に引用を検証するため、過剰な報告をしても問題ありません。hunt: 項目は、フレームワークについてどのパックもカバーしていないマトリックスのセルです。ディスカバリー、認識した idioms（危険なものとガードの両方）、および hunted で回答します。 references/investigate-playbook.md。

8. 検証します。 verify --run <run> → 作業リスト。メモを添えて supported|partial|unsupported|refuted を記録し、supported の場合は exploitPath も記録します。その後、verify --apply を実行します。懐疑的な姿勢を保ちますが、実際に反証できない high-severity の検出結果を反証してはいけません。

9. Git 履歴に照らして再検証します。 verify --apply の後で（対象範囲が confirmed／needs-human と確認され、以前の作業リストが空の場合）、次のいずれかを判定します：still-valid|fixed|false-positive|uncertain。 references/revalidate-playbook.md。

9b. 類似パターンを探します。 variants --run <run> — 根本原因からインスタンスがちょうど 1 つだけ生じることは、ほとんどありません。理由を示し、一度に 1 つの観点を一般化して、同じ問題群が再発しないよう Semgrep ルールを出力します：references/variant-analysis.md。

10. ゲートを実行します。 check --run <run> --semantic。未解決の引用を修正し、残っているものをすべて判定して、コードと矛盾する CONTEXT.md 内の否定表現を調整します。あるクラスが存在しないという記述があると、そのクラスは調査されなくなります。

10b. カバレッジを明示します。 coverage --run <run> — この監査で確認した点と確認していない点を示す ASVS マトリックスです。短いレポートでは、「確認した範囲では何もなかった」という意味が「何もなかった」と読まれてしまいます。このマトリックスで両者を区別します。自動的に REPORT.md に反映されます。

11. 文章化してレンダリングします。 narrative --run <run> を実行し、<run>/NARRATIVE.json（summary、effort を含む fixes、chains、root causes、hardeningNotes）を作成してから、render --run <run> を実行します。出力される REPORT.md は 1 つです（--html）。重要度と領域ごとに、シナリオ・修正・優先度を含む指摘、パッケージごとに 1 行の依存関係、P0～P3 の計画をまとめます。却下した内容は要約されます（すべて表示するには --full）。HIGH／CRITICAL のコード候補が未読の場合、レポートは DRAFT です（終了コード 0、--strict では終了コード 1）。ステップ 6 に戻るか、その旨を明記してください。その後、clean を実行します。レポートのパス、確認済みの指摘、needs-human の一覧を提示してください。references/narrative-playbook.md。

12. 修正を計画します（任意）。 implement --run <run> → 根本原因ごとにまとめた修正 PRD のドラフト IMPLEMENT.md を出力します。これを to-prd スキルまたは実装担当者に渡してください。 references/implement-playbook.md。

オーケストレーション — 実行環境に応じた振り分け

判定段階は並列に分割できます。findings.json の未処理候補（判定対象）、VERIFY.todo.json、REVALIDATE.todo.json、INVESTIGATE.todo.json は、それぞれ項目ごとに独立した作業リストです。orchestrate は現在の作業リストから並列処理を生成します。項目を丸ごとまとめて最大 12 エージェントに割り当て、各プロンプトに対象項目を含めます。

ultrasec orchestrate --run <dir> [--phase adjudicate|verify|revalidate|investigate] [--eco] [--list]

実行環境	各判定フェーズの実行方法
Claude Code で Workflow を利用できる	orchestrate --run <run> --phase <p> を実行し、続けて Workflow({ scriptPath: "<run>/.work/orchestration/<p>.workflow.mjs" }) を実行します。サブエージェントは判定／発見事項の断片を返します。それらを自分で 1 つの適用ファイルに統合し、ワークフローの最後に示される --apply の取り込み処理を実行してください。
Codex／その他のホストでサブエージェントを利用できる	同じ orchestrate を実行し、<run>/.work/orchestration/agents/<role>.md に従って、バッチごとに 1 つのサブエージェントに処理を割り当てます（ワークフロースクリプトにバッチとプロンプトが表示されます）。書き込み担当は 1 人です。自分で統合して取り込みます。
エコモード、またはサブエージェントを利用できない	orchestrate --run <run> --eco を実行し、<run>/.work/orchestration/RUNBOOK.md に順番に従って、自分で各役割を担当します。正確性は同じで、異なるのは経過時間だけです。

並列処理は最適化のためのものであり、必須ではありません。すべてのフェーズに、同一の成果物を生成する逐次実行の代替手段があります。サブエージェントは書き込みを行いません。契約では 1 人だけが書き込むルール（読み取り専用コマンドのみ）を定めており、--apply もあなたが実行するため、判定担当者が誰であっても、不確かな高重要度の指摘は needs-human のまま残ります。作業リストが変わるたびに orchestrate を再実行してください（生成は冪等です）。作業リストがまだない状態で --phase <p> を実行すると失敗し、その作業リストを生成するコマンドが表示されます。

実行結果がおかしい場合

症状	対処方法
scan で候補が 0 件見つかった	manifest.extraction.ast（正規表現の階層か？）と languages を確認してください。サポート対象外のスタックではグラフが生成されません。--sinks を試し、investigate で手動調査してください。
予想より候補がかなり少ない	同様に、truncation（上限に達したか）と、--scope／--gitignore によって想定以上に絞り込まれていないか確認してください。
toolStatus ですべてがスキップと表示される	スキャナーがインストールされていません。ヒントを得るには tools を使うか、scan --docker を実行してください。
check が失敗し続ける	引用された [file:line] が解決できません。ファイルが移動した、行番号が範囲外、または捏造された可能性があります。dossier <id> を再度開き、引用を修正するか、検出結果を削除してください。
check --semantic が失敗する	HIGH／CRITICAL のコードまたは設定の候補がまだ open です（アドバイザリはブロックしません）。判定してください。
--apply が終了コード 2 で終了する	フェイルクローズです。ファイルの形式が不正か、ファイル内にドシエと一致する ID がありません（古い断片です）。作業リストを再生成して、内容を再入力してください。
ディレクトリからの --apply で何も取り込まれなかった	断片の名前はステージのパターンと一致する必要があります。commands.md に一覧があります。
investigate --apply で検出結果が拒否された	[file:line] が解決できない場合があります。アンチハルシネーションゲートが機能しています。実際の行を調べて再送信してください。または、フィールドの値が許可された語彙に含まれていません。理由にはフィールド名と値が示されます。クラス名（xss、dos、disclosure など）は拒否されず、category に取り込まれます。
初回実行が遅い／ネットワークに接続する	初回は一度だけ、クリーンなマシンで約 22 MB の tree-sitter 文法をダウンロードします（--offline でも抑制されません）。事前にウォームアップするか、CODEINDEX_GRAMMARS_DIR を設定してください。
スコープを指定した再スキャンで検出結果が失われたように見える	--merge を使ってください。以前の判定を保持し、スコープ外の検出結果も残せます。

よくある間違い

1. 相対パスでエンジンを実行する。 スキルディレクトリ以外の cwd からは失敗します。絶対パス <skill-dir>/scripts/ultrasec.mjs を使い、サブエージェントにも同じパスを指定してください。
2. 劣化した実行結果を完了として報告する。 まず extraction／truncation／toolStatus を確認してください。
3. コードを読まずに候補を昇格させる。 候補は意図的に再現率を重視しています。作業の単位は dossier を読むことです。
4. 確認できないだけのものを反証する。 証明できないことは反証したことにはなりません。それは needs-human です。
5. 多層防御を HIGH と評価する。 別のレイヤーが防いでいる場合は、強化に関する注記にとどめてください。
6. LOW を水増しする。 理論上の LOW が 10 件あるより、実際の MEDIUM が 3 件あるほうが有益です。
7. スキャナーだけで調査を終える。 スキャナーが対象とするのは既知のパターンです。認可、ビジネスロジック、競合状態こそ、手動調査の価値が発揮される領域です。
8. context を省略する。 信頼モデルがなければ、抽象的な評価にしかなりません。
9. エンジンが列挙したものだけを調べる。 エンジンが見つけるのはパターンであり、不在ではありません。両方の観点から guards を実行してください。スキャナーの FAILED も同じ落とし穴です。空の結果に見える穴が潜んでいます。
10. ダンプをそのまま提出する、または監査の手間を CVE リストに費やす。 ある実行では候補が 882 件出力されましたが、判定されたものはなく、「確認済みの問題なし」とされていました。誰も確認していなかったのです。アドバイザリは順位付けされていますが、フローはそうではありません。まずコードを読んでください。DRAFT のバナーは納品物ではありません。

禁止事項

• findings.json を手動で編集しないでください。 引用ゲートを迂回し、再スキャンや --merge の冪等性を保証する、コンテンツ由来の id を壊します。investigate --apply を使ってください。
• サブエージェントに --apply または verify --shards を実行させないでください。 どちらも実行ディレクトリに書き込みます。書き込みを行うのはオーケストレーターだけです。
• 確実に反証できない HIGH／CRITICAL の検出結果を自動で却下しないでください。
• [file:line] を捏造しないでください。 dossier、graph、または rg -n から取得してください。
• 損害を与える、またはデータを外部に持ち出すエクスプロイトを実行しないでください。 無害なマーカーで制御を証明してください。例：sleep(5)、<b> タグ、カナリア文字列。

対象範囲に関する注意事項

• 決定論的なコアと任意のツール。 変更されていないリポジトリを2回スキャンすると、同じ抽出レベルで同じ汚染候補が得られます。外部ツールの結果はインストール状況に依存し、ネットワークに接続することもあります（アドバイザリデータベース）。外部ツールは必須ではありません。
• リスクの順位付けと相関分析は決定論的です。 複数のツールが検出した1つの問題は、各検出元を示す sources[] と、EPSS／KEV／CVSS を組み合わせた risk で順位付けされた1件の検出結果になります。フィードはキャッシュされます（TTLは1日）。計算はオフラインで行われます。--offline では重大度のみで順位付けします。
• 約15言語に対応したリンクグラフ（JS/TS、Python、Go、Java、Ruby、PHP、Rust、C/C++、C#、Kotlin、Swift、Scala、shell、Lua、Elixir）を提供します。カタログが最も充実しているのはWebスタックです — references/catalog.md。
• 対応していないこと： DAST、ファジング、認証付きクロール、ランタイムテストは行いません。references/attack-classes.md の各クラスは手動で確認する必要があります。また、1回のパスで読み取るのは、調査対象として開いたパスのみです。--merge を使った再実行を推奨します。
• 測定済みです。 OWASP Benchmark におけるCWEごとのスコア： references/BENCHMARK.md。未対応部分も含みます — インジェクションには強い一方、ソースからシンクへの形を取らないものは検出ゼロです。どの範囲をカバーしているかは coverage で確認できます。
• 判断に代わるものではありません。 ultrasec は巨大なリポジトリを、根拠に裏付けられた少数の候補に絞り込み、単純な部分を機械的に検証します。セキュリティ上の判断はご自身で行ってください。

参考資料

手法 — adjudication.md（誤検知の分類、PoCの評価基準、具体例） · severity-and-discipline.md（評価基準とキャリブレーション用のペア） · citation-format.md（根拠付けの要件） · schemas.md（すべての作業リストJSON）。

セキュリティ知識 — attack-classes.md（汚染解析では到達できないクラス） · access-control.md（IDOR/BOLA/BFLA、--lens access-control） · privacy-and-data-protection.md（転送、保持、仮名化） · frameworks.md（スタックごとの見落とされやすい箇所） · hunting-heuristics.md（攻撃者の視点と偵察コマンド） · supply-chain.md（依存関係、シークレット、CI、IaC） · catalog.md（エンジンが列挙する対象）。

プレイブック — audit-playbook.md（標準） · deep-audit-playbook.md（詳細） · scale-audit-playbook.md（巨大なリポジトリ、CI） · context-playbook.md · investigate-playbook.md · revalidate-playbook.md · narrative-playbook.md · implement-playbook.md · log-forensics-playbook.md（ブルーチーム） · probe-playbook.md（稼働中のサイトの動的なセキュリティ状況を隔離環境で確認） · route-playbook.md（対象範囲外のターゲットをツールに振り分け） · powered-mode.md（自律性）。

エンジン — commands.md（CLIの全機能） · tools.md（スキャナー群） · tooling-internals.md。