リスク例外を申請・承認

すぐに修正しない合理的な理由がある脆弱性は、リスク例外として申請します。Abyssの例外は無期限の除外ではなく、理由・有効期限・承認者を記録する期限付きワークフローです。

書き込み権限のユーザーが申請し、組織管理者が承認・却下します。

2種類の例外

種類	選ぶ基準	例
リスク受容	問題は存在するが、影響と対策コストを踏まえて期限付きで受け入れる	OS要件により暫定的に古い暗号方式を残す
誤検知	検出根拠はあるが、実際の実装・配布条件では問題が成立しない	テスト用文字列が本番ビルドでは参照されない

迷う場合は「誤検知」に寄せず、問題の存在を認めたうえで「リスク受容」とし、修正・再評価の期限を設定します。

申請する

書き込み権限を持つユーザーが、脆弱性詳細の「リスク例外」から申請します。

1. 「リスク受容」または「誤検知」を選ぶ
2. 将来の日付を有効期限に設定する
3. 修正しない理由を入力する
4. 「例外を申請」を選ぶ

理由には最低限、次を含めてください。

• 判断の根拠
• 悪用に必要な条件と想定影響
• 代替コントロール（サーバー側制御、監視、配布制限など）
• 再評価の契機（期限、OS移行、ライブラリ更新など）
• 関連するチケットや決定記録

本番APIではサーバー側の送信元制限と短時間トークンを適用済み。
現バージョンでのSDK更新は決済フローへ影響するため、次回メジャー更新で修正する。
関連: SEC-142。2026-10-31までに再評価する。

同じ脆弱性に「承認待ち」または「承認済み」の例外がある間は、新しい例外を重ねて申請できません。

承認・却下する

組織管理者が申請内容と脆弱性の根拠を確認します。

• 承認: 脆弱性の状態が「リスク受容」または「誤検知」になる
• 却下: 脆弱性の状態は変わらない
• 取消: 承認済み例外を取り消し、脆弱性を「未対応」に戻す

申請・承認・却下・取消はトリアージ履歴に記録されます。申請者と承認者を分けると、より明確なレビューになります。

期限が切れたら

承認済み例外は、有効期限を過ぎると期限切れになります。対象の脆弱性は「未対応」に戻り、期限切れ例外を評価するセキュリティポリシーでは、次回スキャンの警告または失敗理由になります。

期限を延長したい場合も、既存判断を無期限に延命せず、現在の根拠を再確認して新しく申請してください。

注意

例外は検出を削除しません。脆弱性の根拠・検出履歴・監査履歴は残り、次のスキャンでも検出結果に応じて追跡されます。