目的
CaseBender はセキュリティチームが利用する製品であるため、製品セキュリティを一度限りのチェックリストではなく、リリース要件として扱っています。セキュリティ保証プログラムは、保護された開発ワークフロー、自動セキュリティテスト、コンテナおよび依存関係の統制、リリースのプロベナンス、文書化された例外、ならびに独立評価の計画を組み合わせたものです。 このセクションでは、以下について説明します。- 自動的に実行される統制
- 変更またはリリースをブロックする検出結果
- 各統制が生成する証拠
- 例外の管理方法
- お客様が独自に検証できる事項
- 自動保証の限界
保証の概要
保護された変更（英語）
保護対象ブランチへのプルリクエストは、マージ前に集約されたセキュリティゲートを通過します。
多層的なテスト
シークレット、ソースコード、依存関係、ライセンス、インフラストラクチャ、およびすべてのサービスイメージを、独立したツールで検査します。
リリースの完全性（英語）
リリースワークフローは、SBOM、プロベナンス、不変ダイジェスト、および暗号署名を生成します。
お客様向け証拠
お客様は、コミット、イメージダイジェスト、またはリリースに関連付けられた証拠を特定できます。
セキュアな変更ライフサイクル
提案されたすべての変更は、次の共通の上位レベルのライフサイクルに従います。統制が実行されるタイミング
正確なトリガーとツール構成に関する最終的な技術情報源は、このページではなくワークフロー定義です。リポジトリへのアクセス権を持つ承認済みレビュー担当者は Security Scan workflow を確認できます。アクセス権を持たないお客様は、セキュリティ証跡ガイドに記載されたリリース固有の証跡をご利用ください。
マージをブロックするセキュリティゲート
集約された Security Gate では、プルリクエストおよびプッシュ時に、以下のジョブが成功する必要があります。
GitHub Code Security のライセンスがない場合、スキャナー結果のアップロードはベストエフォートとなることがありますが、基盤となるローカルスキャンは引き続きブロック要件です。また、ゲートが SARIF の取り込みに依存しないよう、レポートはワークフロー成果物としても保存されます。
動的セキュリティテスト
週次 DAST ジョブは、専用のステージング環境に対して OWASP ZAP を使用します。アクティブテストを開始する前に、CI は以下を検証します。- ターゲットがプレースホルダー、localhost、またはループバックアドレスではないこと
- レスポンスが CaseBender Web のデプロイメントであることを示していること
- 設定されたテスト用 ID により認証済みセッションが生成されること
- 認証ヘッダーがマスクされたリポジトリシークレットを通じて提供されること
コンテナ保証
CaseBender は現在、7 つのサービスイメージを生成します。各本番用 Dockerfile は、マルチステージビルドと非 root のランタイムユーザーを使用します。コンテナ保証のプロセスには、以下が含まれます。- Dockerfile の lint
- 本番環境用依存関係の削減
- 公開前の脆弱性スキャン
- イメージスキャンによる埋め込みシークレットの検出
- 公開後の不変ダイジェストの選択
- GitHub の OIDC ID を使用したキーレス Cosign 署名
- 公開された正確なダイジェストに対する署名検証
latest のような可変タグのみに依存せず、お客様が取得するダイジェストに署名します。
ソフトウェアサプライチェーンの証拠
リリースワークフローは、相互に補完する複数の記録を生成します。- CycloneDX SBOM — 依存関係分析のためのパッケージおよびコンポーネントのインベントリ
- BuildKit SBOM and provenance — コンテナビルド時に出力されるビルドメタデータ
- Cosign signature — 不変のイメージダイジェストに紐付けられた暗号学的 ID
- SBOM attestation — イメージとそのコンポーネントインベントリとの署名済みの関連付け
- SLSA-format provenance document — ソースリビジョン、ワークフロー ID、および呼び出しメタデータ
- Scanner reports — 該当するワークフローによって保持される SARIF または JSON 出力
subject は空であるため、7 つのイメージダイジェストに暗号学的に紐付けられておらず、成果物レベルのプロベナンスまたは独立した SLSA 認証として示してはなりません。
脆弱性への対応
検出結果は、severity、悪用可能性、影響を受けるデプロイモード、公開範囲、およびパッチ提供状況に従ってトリアージされます。プロジェクトが文書化しているデフォルトの修正目標は以下のとおりです。
これらは社内の修正目標であり、顧客契約に組み込まれていない限り、契約上のサービスレベルではありません。
即時の修正が不可能な場合、例外は範囲が限定され、レビュー可能でなければなりません。現在の Trivy IaC の例外は
.trivyignore.yaml に保存され、検出結果、影響を受けるパス、正当な理由、および有効期限が記載されています。ライセンス例外はパッケージ固有であり、ポリシーによってライセンス識別子全体がグローバルに除外されることはありません。このリポジトリファイルを、受容された製品リスクの全カテゴリーを網羅する完全な台帳として解釈しないでください。
ツールとワークフローの完全性
統制自体も保護されています。- サードパーティの GitHub Actions は、不変のコミット SHA に固定
- 重要なスキャナーバイナリおよびコンテナイメージは、バージョンまたはダイジェストに固定
- ロックファイルに基づくインストールでは
--frozen-lockfileを使用 - セキュリティのネガティブコントロールにより、スキャナーが既知の不正な入力を予期せず拒否しなくなった場合に検出
- 現在の GitHub ブランチ保護設定では、必須ステータスチェックが生成されていない直接更新を拒否。このポリシーはソースリポジトリ外で管理
- 必須のセキュリティジョブが失敗、キャンセル、または予期せずスキップされた場合、集約ジョブは失敗
補助的なマルウェアヒューリスティック
別のマージ後ワークフローが、main 上の Next.js および PostCSS 構成ファイルへの変更を監視し、既知の悪意ある npm サプライチェーンパターンを検出すると、自動リバートを作成できます。これは、範囲を限定したパターンベースの復旧統制です。プルリクエストゲート、アンチウイルスエンジン、EDR 統制、または包括的なマルウェアスキャンではありません。
お客様の責任
CaseBender は、お客様が管理するインフラストラクチャにデプロイできます。製品保証は、その環境のセキュアな運用に代わるものではありません。お客様は引き続き、以下について責任を負います。- TLS 証明書、ingress、ファイアウォール、およびネットワークセグメンテーション
- ID プロバイダー、MFA、およびロールの構成
- データベース、Redis、オブジェクトストレージ、および検索サービスのハードニング
- シークレットのローテーションおよびデプロイ認証情報へのアクセス
- バックアップ、監視、保持、およびインシデント対応
- サポート対象の更新の適用およびリリースノートの確認
- お客様の規制環境および脅威環境に対する統制の検証
現在の保証範囲と限界
2026 年 7 月時点：- 自動化された SAST、SCA、シークレット、ライセンス、IaC、コンテナ、SBOM、署名、およびプロベナンスの各ワークフローを実装済み
- 認証済みステージング DAST は CI で構成済みだが、維持管理されたステージングターゲットおよびテスト用 ID に依存
- GitHub がホストする SARIF および Dependency Review の機能はリポジトリのライセンスに依存する一方、ローカルの Trivy およびパッケージ監査ゲートは引き続き利用可能
- 完了済みの第三者ペネトレーションテストレポートまたは修正後の再テスト書簡があるとは表明していない
- コンプライアンスマッピングは統制との整合性を示すものであり、独立した認証ではない
関連ドキュメント
- Code Security（英語） — スキャナー構成、DAST、ライセンス、および脆弱性管理
- Supply Chain Security（英語） — 依存関係、イメージ、SBOM、署名、およびプロベナンス
- セキュリティ証拠ガイド — 証拠の種類とその解釈方法
- Security Architecture（英語） — アプリケーションおよびデプロイメントのセキュリティ設計
- Independent Penetration Test Scope（英語） — 計画中の手動評価の対象範囲