脆弱性を公開 issue に書かないでください。 修正の前に脆弱性を公開することになり、報告者の善意がそのまま利用者への危険に変わります。

報告は GitHub の非公開の脆弱性報告を使ってください。

https://github.com/ambi/idmagic/security/advisories/new

受領を確認したうえで返信します。レスポンスまでの日数は約束しません。 守れない期限を書くことは、期限を書かないことより誠実でないと考えるためです。

報告に次が含まれていると確認が早くなります。

• 影響する経路。エンドポイント、画面、実行単位のいずれか。
• 再現手順、または再現する最小の構成。
• 想定される影響。誰が、何に、どこまで到達できるか。
• 確認したコミットハッシュ。

IdMagic はまだリリースを行っていません。対象は main の最新のコミットだけであり、過去のコミットに対する修正は提供しません。

IdMagic は ID プロバイダーなので、次の境界が破れることを問題として扱います。境界の正本は Authorization Design です。

• テナント境界の越境。 別テナントのリソース、識別子、件数のいずれかへの到達。
• 認証の回避。 資格情報の検証、セッション、多要素認証、ログインスロットルのいずれかの迂回。
• 認可の回避。 スコープ、ロール、対話セッション限定の制約の迂回。
• 鍵素材の露出。 署名鍵、データ暗号鍵、クライアントシークレットの取得。
• フェイルクローズの破れ。 判断に必要な情報が得られないときに、拒否ではなく許可へ倒れる経路。
• トークンの偽造、再送、意図しない主体への発行。

• 開発用のデフォルト値を本番で使った場合の問題。 DATA_KEY_PROVIDER を設定しないときのプロセス内の平文鍵セット、PERSISTENCE=memory、デモ用にシードしたアカウントは、いずれも開発専用であることを README.md と CONFIGURATION.md が明示しています。
• 設定で有効化できる防御を無効にしたままの構成。 TLS を終端しないデプロイ先での HSTS 無効、信頼できないプロキシの背後での REQUEST_ID_TRUST_INBOUND=true などが該当します。
• 実際の到達経路を示さない、スキャナーの出力そのもの。

分類は上の「セキュリティ上の問題として扱うもの」がそのまま使います。ここで別の分類表を作ると、同じことを違う語で二度書くことになり、どちらが正本か分からなくなります。

同じ欠陥が複数の項目に当たるときは、次の順で重く扱います。修正の順序を決めるためのものであり、報告者へのレスポンス期限を意味しません。

1. 鍵素材の露出。 署名鍵とデータ暗号鍵の露出は、そこから他のすべてが導けるので最も重く扱います。
2. 認証の回避、およびトークンの偽造、再送、意図しない主体への発行。任意の主体になれます。
3. テナント境界の越境。別テナントのデータに到達できます。
4. 認可の回避、およびフェイルクローズの破れ。与えられた権限を超えられます。
5. 可用性の喪失。増幅、資源の枯渇、意図しない再帰。

破れる境界そのものの定義は Authorization Design が持ちます。攻撃者と資産の対応は Threat Model にありますが、あちらは STRIDE の分類で書かれており、この順序とは別の切り口です。

1. 受領。 報告を確認し、再現の可否を返します。再現できないときは、何が足りないかを具体的に返します。
2. 分類。 上の表で分類し、影響を受ける経路を特定します。
3. 修正。 main に対して修正を作り、その欠陥を捉える回帰検査を同じ変更に含めます。拒否を検査するときは、返した状態符号だけでなく、拒否が何を起こさせなかったかも検査します。
4. 公開。 GitHub Security Advisory を発行します。報告者が希望する場合は謝辞に名前を載せます。

公開の時期は報告者と相談して決めます (調整開示)。既に悪用が観測されている場合は、修正の完了を待たずに回避策を先に公開することがあります。レスポンスまでの日数は約束しません。 この文書の冒頭に書いたとおり、守れない期限を書くことは、期限を書かないことより誠実でないと考えるためです。

依存の既知脆弱性は CI が毎 Pull Request で検査します。手元でも同じ検査を実行できます。

mise run audit-dependencies      # go.mod / frontend/bun.lock / tools/bun.lock の既知脆弱性
mise run audit-go-reachability   # そのうち Go のコードが実際に呼ぶもの

audit-dependencies は抑止されていない検出が 1 件でもあれば失敗します。深刻度による絞り込みは行いません。OSV のレコードには深刻度を持たないものがあり、閾値を置くと既知脆弱性を黙って通すためです。開発ツールの依存 (tools/bun.lock) も対象に含めます。開発ツールはソース、資格情報、生成物へ到達できるので、実行時のプロダクトに届かないことは対象から外す理由になりません。

修正済みのバージョンが無い、到達不能である、互換性の問題で今は上げられない、といった事情で検出を通す必要があるときは、リポジトリ直下の osv-scanner.toml に記録します。reason と ignoreUntil の両方が必須です。

[[IgnoredVulns]]
id = "GO-0000-0000"
ignoreUntil = 2026-11-28
reason = "何が到達しないのか、あるいはなぜ今は上げられないのかを、経路を名指しして書く。"

mise run check-vulnerability-suppressions が、理由の欠落、期限の欠落、期限切れをそれぞれ拒否します。OSV-Scanner 自身は両方を任意として扱い、期限の無い項目を無期限に無視するので、必須化はこの検査が持ちます。期限が来たら、抑止を延長するか、修正するか、判断をやり直します。無期限の抑止は作れません。

抑止の入口は 2 つあり、検査は両方を見ます。[[IgnoredVulns]] が脆弱性 1 件を通し、[[PackageOverrides]] の ignore はパッケージごと走査から外します。後者は期限を effectiveUntil に書きますが、要求は同じです。片方だけを検査すると、同じ強さの抑止がもう片方から理由も期限も無しに作れてしまいます。

この文書が扱うのは検知です。私たちが配る依存に既知の脆弱性が無いことを、繰り返し確かめる運転を指します。

配った成果物が本当に私たちの作ったものかという真正性 (SBOM、署名、provenance) は別の面です。両方が要ります。真正性を証明できても、その中身に既知の脆弱性が入っていれば検知の失敗です。逆に、検知が緑でも、配布経路で差し替えられていれば真正性の失敗です。

真正性の方針はまだ書かれていません。Deployment Architecture が置き場になりますが、現時点では署名鍵の取り扱いしかありません。SBOM の生成、cosign 署名、SLSA provenance は未着手です。