> ## Documentation Index > Fetch the complete documentation index at: https://docs.casebender.com/llms.txt > Use this file to discover all available pages before exploring further. # セキュリティ保証プログラム > CaseBender が変更をテストし、セキュリティのリグレッションを阻止し、リリース成果物を保護し、保証に関する証拠をお客様に提供する方法について説明します。 ## 目的 CaseBender はセキュリティチームが利用する製品であるため、製品セキュリティを一度限りのチェックリストではなく、リリース要件として扱っています。セキュリティ保証プログラムは、保護された開発ワークフロー、自動セキュリティテスト、コンテナおよび依存関係の統制、リリースのプロベナンス、文書化された例外、ならびに独立評価の計画を組み合わせたものです。 このセクションでは、以下について説明します。 * 自動的に実行される統制 * 変更またはリリースをブロックする検出結果 * 各統制が生成する証拠 * 例外の管理方法 * お客様が独自に検証できる事項 * 自動保証の限界 セキュリティ保証はリスクを低減しますが、ソフトウェアに脆弱性がないことを証明するものではありません。ワークフローのバッジ、スキャナーレポート、SBOM、署名は、特定の統制に関する証拠であり、セキュリティ認証でも、独立したペネトレーションテストの代替でもありません。 ## 保証の概要 保護対象ブランチへのプルリクエストは、マージ前に集約されたセキュリティゲートを通過します。 シークレット、ソースコード、依存関係、ライセンス、インフラストラクチャ、およびすべてのサービスイメージを、独立したツールで検査します。 リリースワークフローは、SBOM、プロベナンス、不変ダイジェスト、および暗号署名を生成します。 お客様は、コミット、イメージダイジェスト、またはリリースに関連付けられた証拠を特定できます。 ## セキュアな変更ライフサイクル 提案されたすべての変更は、次の共通の上位レベルのライフサイクルに従います。 ```text theme={null} Developer change → Pull request → Build and functional checks → Parallel security controls → Aggregate Security Gate → Protected-branch review and merge → Pre-publish image scan → Digest-based publication and signing → Deployment readiness verification → Scheduled reassessment ``` 統制は意図的に多層化されています。たとえば、依存関係のリスクはパッケージマネージャーのアドバイザリーデータベースと Trivy の両方で評価され、コンテナイメージはビルド後にスキャンされます。また、決定論的なネガティブコントロールにより、シークレットスキャナーと SAST スキャナーが既知の不正なフィクスチャを引き続き拒否することを検証します。 ## 統制が実行されるタイミング | イベント | 保証アクティビティ | | --------------------------------- | ------------------------------------------------------------------------ | | `main` または `production` へのプルリクエスト | ソース、依存関係、ライセンス、IaC、Dockerfile、および 7 つのイメージを対象とした完全なセキュリティゲート | | `main` へのプッシュ | セキュリティゲート、SBOM 生成、およびメインブランチ成果物のワークフロー | | 公開されるコンテナのビルド | 公開前の脆弱性スキャン、不変ダイジェストの取得、署名の作成、および署名の検証 | | 週次スケジュール | 必要なターゲットとテスト用 ID が設定されている場合の、完全なセキュリティワークフローおよび認証済み OWASP ZAP ステージングスキャン | | 依存関係の更新 | 同一のプルリクエストゲートを適用。リポジトリのライセンスで利用可能な場合は、GitHub Dependency Review も追加で強制 | 正確なトリガーとツール構成に関する最終的な技術情報源は、このページではなくワークフロー定義です。リポジトリへのアクセス権を持つ承認済みレビュー担当者は [Security Scan workflow](https://github.com/casebender/webapp/actions/workflows/security-scan.yml) を確認できます。アクセス権を持たないお客様は、[セキュリティ証跡ガイド](/ja/security/security-evidence)に記載されたリリース固有の証跡をご利用ください。 ## マージをブロックするセキュリティゲート 集約された Security Gate では、プルリクエストおよびプッシュ時に、以下のジョブが成功する必要があります。 | 統制 | 対象範囲 | ブロック条件 | | ------------------------ | --------------------------------------------------------------------------------- | ---------------------------------------------- | | Gitleaks | 現在のソースおよび Git 履歴全体 | シークレットパターンを検出 | | Trivy filesystem scan | リポジトリおよび依存関係マニフェスト | 修正が提供されている、許容されていない HIGH または CRITICAL の脆弱性 | | Trivy container scan | Web、API、ingestion、worker、workflow processor、MISP processor、および search sync の各イメージ | 修正が提供されている、許容されていない HIGH または CRITICAL のイメージ脆弱性 | | Hadolint | 7 つすべての Dockerfile | Dockerfile ポリシー違反 | | Trivy IaC scan | Dockerfile および Kubernetes 構成 | HIGH または CRITICAL のセキュリティ設定不備 | | ESLint security rules | Web の TypeScript および JavaScript | セキュリティルールエラー | | Semgrep | TypeScript、Next.js、OWASP、インジェクション、XSS、シークレット、および security-audit ルール | ERROR severity の検出結果またはスキャナー障害 | | License policy | リポジトリの依存関係 | 未承認のブロック対象ライセンス、または不正形式／空のレポート | | `pnpm audit` | 本番環境の依存関係 | HIGH または CRITICAL のアドバイザリ | | SBOM generation | ワークスペース全体 | CycloneDX の生成失敗 | | Security control tests | 生成されたシークレットおよび安全でないコードのフィクスチャ | スキャナーが既知の不正なフィクスチャを拒否できない | | GitHub Dependency Review | ライセンスで利用可能な場合の、プルリクエストによる依存関係の差分 | 新規の HIGH/CRITICAL 脆弱性または拒否対象ライセンス | GitHub Code Security のライセンスがない場合、スキャナー結果のアップロードはベストエフォートとなることがありますが、基盤となるローカルスキャンは引き続きブロック要件です。また、ゲートが SARIF の取り込みに依存しないよう、レポートはワークフロー成果物としても保存されます。 ## 動的セキュリティテスト 週次 DAST ジョブは、専用のステージング環境に対して OWASP ZAP を使用します。アクティブテストを開始する前に、CI は以下を検証します。 1. ターゲットがプレースホルダー、localhost、またはループバックアドレスではないこと 2. レスポンスが CaseBender Web のデプロイメントであることを示していること 3. 設定されたテスト用 ID により認証済みセッションが生成されること 4. 認証ヘッダーがマスクされたリポジトリシークレットを通じて提供されること スキャンは認証済みのアクティブテストを実行し、レポートを保存します。ターゲットまたは認証情報が不足している場合、無関係なページを黙ってスキャンするのではなく、DAST ジョブが失敗します。 DAST の対象範囲は、テスト用 ID から到達可能なルートおよび状態に制限されます。手動による認可、テナント分離、ワークフロー悪用、パーサー、または統合のテストに代わるものではありません。 ## コンテナ保証 CaseBender は現在、7 つのサービスイメージを生成します。各本番用 Dockerfile は、マルチステージビルドと非 root のランタイムユーザーを使用します。コンテナ保証のプロセスには、以下が含まれます。 * Dockerfile の lint * 本番環境用依存関係の削減 * 公開前の脆弱性スキャン * イメージスキャンによる埋め込みシークレットの検出 * 公開後の不変ダイジェストの選択 * GitHub の OIDC ID を使用したキーレス Cosign 署名 * 公開された正確なダイジェストに対する署名検証 Docker Hub および GitHub Container Registry のワークフローは、`latest` のような可変タグのみに依存せず、お客様が取得するダイジェストに署名します。 ## ソフトウェアサプライチェーンの証拠 リリースワークフローは、相互に補完する複数の記録を生成します。 * **CycloneDX SBOM** — 依存関係分析のためのパッケージおよびコンポーネントのインベントリ * **BuildKit SBOM and provenance** — コンテナビルド時に出力されるビルドメタデータ * **Cosign signature** — 不変のイメージダイジェストに紐付けられた暗号学的 ID * **SBOM attestation** — イメージとそのコンポーネントインベントリとの署名済みの関連付け * **SLSA-format provenance document** — ソースリビジョン、ワークフロー ID、および呼び出しメタデータ * **Scanner reports** — 該当するワークフローによって保持される SARIF または JSON 出力 単独の SLSA-format document は署名済みのビルドメタデータです。現在の `subject` は空であるため、7 つのイメージダイジェストに暗号学的に紐付けられておらず、成果物レベルのプロベナンスまたは独立した SLSA 認証として示してはなりません。 ## 脆弱性への対応 検出結果は、severity、悪用可能性、影響を受けるデプロイモード、公開範囲、およびパッチ提供状況に従ってトリアージされます。プロジェクトが文書化しているデフォルトの修正目標は以下のとおりです。 | Severity | 目標 | | -------- | ----- | | Critical | 24 時間 | | High | 7 日 | | Medium | 30 日 | | Low | 90 日 | これらは社内の修正目標であり、顧客契約に組み込まれていない限り、契約上のサービスレベルではありません。 即時の修正が不可能な場合、例外は範囲が限定され、レビュー可能でなければなりません。現在の Trivy IaC の例外は `.trivyignore.yaml` に保存され、検出結果、影響を受けるパス、正当な理由、および有効期限が記載されています。ライセンス例外はパッケージ固有であり、ポリシーによってライセンス識別子全体がグローバルに除外されることはありません。このリポジトリファイルを、受容された製品リスクの全カテゴリーを網羅する完全な台帳として解釈しないでください。 ## ツールとワークフローの完全性 統制自体も保護されています。 * サードパーティの GitHub Actions は、不変のコミット SHA に固定 * 重要なスキャナーバイナリおよびコンテナイメージは、バージョンまたはダイジェストに固定 * ロックファイルに基づくインストールでは `--frozen-lockfile` を使用 * セキュリティのネガティブコントロールにより、スキャナーが既知の不正な入力を予期せず拒否しなくなった場合に検出 * 現在の GitHub ブランチ保護設定では、必須ステータスチェックが生成されていない直接更新を拒否。このポリシーはソースリポジトリ外で管理 * 必須のセキュリティジョブが失敗、キャンセル、または予期せずスキップされた場合、集約ジョブは失敗 ### 補助的なマルウェアヒューリスティック 別のマージ後ワークフローが、`main` 上の Next.js および PostCSS 構成ファイルへの変更を監視し、既知の悪意ある npm サプライチェーンパターンを検出すると、自動リバートを作成できます。これは、範囲を限定したパターンベースの復旧統制です。プルリクエストゲート、アンチウイルスエンジン、EDR 統制、または包括的なマルウェアスキャンではありません。 ## お客様の責任 CaseBender は、お客様が管理するインフラストラクチャにデプロイできます。製品保証は、その環境のセキュアな運用に代わるものではありません。お客様は引き続き、以下について責任を負います。 * TLS 証明書、ingress、ファイアウォール、およびネットワークセグメンテーション * ID プロバイダー、MFA、およびロールの構成 * データベース、Redis、オブジェクトストレージ、および検索サービスのハードニング * シークレットのローテーションおよびデプロイ認証情報へのアクセス * バックアップ、監視、保持、およびインシデント対応 * サポート対象の更新の適用およびリリースノートの確認 * お客様の規制環境および脅威環境に対する統制の検証 運用上の推奨事項については、[Deployment Hardening Guide（英語）](/en/security/hardening-guide) を参照してください。 ## 現在の保証範囲と限界 2026 年 7 月時点： * 自動化された SAST、SCA、シークレット、ライセンス、IaC、コンテナ、SBOM、署名、およびプロベナンスの各ワークフローを実装済み * 認証済みステージング DAST は CI で構成済みだが、維持管理されたステージングターゲットおよびテスト用 ID に依存 * GitHub がホストする SARIF および Dependency Review の機能はリポジトリのライセンスに依存する一方、ローカルの Trivy およびパッケージ監査ゲートは引き続き利用可能 * 完了済みの第三者ペネトレーションテストレポートまたは修正後の再テスト書簡があるとは表明していない * コンプライアンスマッピングは統制との整合性を示すものであり、独立した認証ではない 提案されている独立評価の範囲は、[Independent Penetration Test Scope（英語）](/en/security/penetration-test-scope) に記載されています。 ## 関連ドキュメント * [Code Security（英語）](/en/security/code-security) — スキャナー構成、DAST、ライセンス、および脆弱性管理 * [Supply Chain Security（英語）](/en/security/supply-chain) — 依存関係、イメージ、SBOM、署名、およびプロベナンス * [セキュリティ証拠ガイド](/ja/security/security-evidence) — 証拠の種類とその解釈方法 * [Security Architecture（英語）](/en/security/architecture) — アプリケーションおよびデプロイメントのセキュリティ設計 * [Independent Penetration Test Scope（英語）](/en/security/penetration-test-scope) — 計画中の手動評価の対象範囲