GH GambleHub

脆弱性スキャンとパッチ

簡単な要約

脆弱性管理は継続的なサイクルです：検出→リスク評価→排除（パッチ/移行/構成）→検証→レポート。スキャン技術（SCA/SAST/DAST/IAST/Cloud/Container）はシグナルを与え、コンテキスト（露出、特権、データ、EPSS、エクスプロイト）が優先順位を決定します。目標は、自動化、カナリア計算、および明確なSLOを使用して、ビジネスダウンタイムなしにリアルリスクを削減することです。

タクソノミのスキャン

SCA（ソフトウェア構成解析）：依存性/ライセンス解析；ライブラリでのCVE検出、SBOM。
アセンブリ前のネイティブコードのSAST静的解析。
DAST：ダイナミックブラックボックスとランニングサービス。
IAST：アプリ内センサー（テスト中）-FPが少なく、より深いコンテキスト。
コンテナ/OSスキャン：イメージ（ベースイメージ、パッケージ）、ホスト（カーネル/パッケージ/configs）、 CISベンチマーク。
Cloud/Infra （CSPM/KSPM）： cloud/K8s misconfigs （IAM、ネットワーク、暗号化、パブリックバケット）。
Secretsスキャン：リポジトリと画像のキー/トークンのリーク。
バイナリ/アーティファクトスキャン：収集されたアーティファクト（署名、脆弱性）の検証。

リスクモデルと優先順位付け

スコア=CVSS v3。x（ベース）× EPSS（搾取の確率）×コンテキスト（露出、データ、特権、補償措置）。

コンテキストファクター：
  • インターネット/内部の露出、WAF/mTLS/isolationの存在。
  • データ：PII/財務/秘密。
  • プロセス/ノード権限、横方向の移動可能性。
  • 公的搾取/大量攻撃、コンプライアンス要件の可用性。

例CVSSベクトル：'CVSS： 3。1/AV： N/AC： L/PR： N/UI： N/S： U/C： H/I： H/A： H'→批判；サービスが公共であり、補償措置なしの場合-P1。

SLOしきい値（例）：
  • P1（クリティカル、操作）：修正≤ 48時間。
  • P2（高い）：7日≤固定して下さい。
  • P3（平均）：30日≤修正します。
  • P4 （low/inform）： 計画/backlog。

脆弱性管理ライフサイクル

1.アセットインベントリ：サービス、イメージ、クラスタ、OS、パッケージ、依存関係、バージョン。
2.スケジュールとイベントスキャン：コミット、ビルド、ダンプ、毎日/毎週のウィンドウ。
3.Triage：重複排除、正規化（CVE→Ticket）、所有者へのマッピング。
4.コンテキスト別の優先順位付け：CVSS/EPSS+露出/データ。
5.修復：patch/dependency update/config hardnening/virtual patch （WAF）。
6.検証：再スキャン、テスト、カナリア。
7.レポート：クロージャメトリクス、脆弱性の年齢、SLO準拠。
8.レッスン：テンプレートで修正（基本イメージ、ヘルムチャート）、将来のポリシー。

CI/CDへの統合

ステップPRで：SAST+SCA+秘密スキャン；P1/P2またはアプリケーション要件による"break build'。
ビルドステージ：イメージスキャン、SBOM生成（CycloneDX/SPDX）、アーティファクト署名（cosign）。
配布時：アドミッションポリシーステージ-「クリティカル/ハイ」の脆弱性と符号なし/SBOMを持つ画像を禁止します。
ポストステージ：ステージングおよび部分的な生産に対するDAST/IAST（安全なプロファイル）。

例： リノベート/Dependabot（フラグメント）

json
{
"extends": ["config:recommended"],
"vulnerabilityAlerts": { "enabled": true },
"packageRules": [
{ "matchUpdateTypes": ["minor","patch"], "automerge": true },
{ "matchManagers": ["dockerfile"], "enabled": true }
]
}

入場ポリシー（Kubernetes、 OPA/Gatekeeper-簡略化）

rego package policy.vuln

deny[msg] {
input.image.vuln.critical > 0 msg:= sprintf("Image %s has critical vulns", [input.image.name])
}

deny[msg] {
input.image.sbom == false msg:= sprintf("Image %s without SBOM", [input.image.name])
}

パッチ管理（固定資産、コンテナ、K8s）

ОA （Linux/Windows）

パッチウィンドウ：通常のウィンドウ+P1用の緊急時の特別なウィンドウ。
戦略：最初にカナリア5-10％ノード、次に波。
自動デプロイメント：Ansible/WSUS/Intune/SSM；制約チェックとロールバック。
カーネルライブパッチ（可能な場合）ダウンタイムを最小限に抑える。
サービスの再起動：K8sノードの管理ドレイン/コードン、グレースフルなシャットダウン。

コンテナ

不変のアプローチ：ランタイムでは「apt upgrade」ではありません。更新されたベースでイメージを再構築します。
基本画像：定期的にゴールデンイメージ（アルパイン/Debian/ディストロレス）を更新し、バージョンを修正します（ダイジェスト）。

マルチステージアセンブリ： サーフェスの最小化（ビルドツールの削除）

「プリデプロイスキャン」（Pre-Deploy Scan）-重要なCVEを使用して画像をブロックします。

Kubernetes/Service Mesh

コントロールプレーン：タイムリーなマイナーリリース、CVE k8s/etcd/containerdを閉じます。
Node OS/Containerランタイム：スケジュールされた更新、バージョン互換性。
Mesh/Ingress： Envoy/Istio/NGINXバージョンは重要です（多くの場合、パーサ/NTTR3ではCVE）。
入場ポリシー：ban'：latest'、署名要件、脆弱性限界。

仮想パッチと補償措置

パッチがすぐに不可能な場合：
  • WAF/WAAP：特定のエンドポイントの署名/正モデル。
  • Feature Flags：脆弱性の機能を無効にします。
  • ネットワークACL/mTLS/IP allow-list：脆弱なサービスへのアクセスを制限します。
  • Config hardnening：権利の低下、サンドボックス、読み取り専用FS、危険モジュールの無効化。
  • TTLトークン/キーの削減、秘密の回転。

リスクの受け入れ

正当化、補償措置、排除のためのSLA、改訂日。
「一時的なリスク受容」として報告し、毎月のレビューに含める。

観測可能性と指標

技術的な：
  • Mean Time To Patch （MTTP） P1/P2/P3。
  • スキャンによってカバーされる資産のシェア（％）。
  • オープンな脆弱性の時代（p50/p90）、 backlogバーンダウン。
  • SBOMと署名を持つ画像の割合。
ビジネス/SLO：
  • 終了日によるSLOの完了（例：95％ P1 ≥ ≤ 48時間）
  • 稼働時間（パッチインシデントの数）への影響。
  • 同じCVEの繰り返し検出（テンプレートの品質を修正）。

プレイブック（略称）

P1： 公共サービスにおける重要なRCE

1.WAF ルール/wirthパッチを有効にします。
2.許可されていないソースへのアクセスをブロックします（該当する場合）。
3.緊急のイメージの再構築/OSのパッチ、→wave canary。
4.繰り返しDAST/テレメトリチェック、エラー監視。
5.事後：ベースイメージ/ヘルムチャートの修正を修正し、CIにテストを追加します。

秘密漏洩（認可）：

1.秘密/キーの即時回転、トークンの失効。

2.使用の痕跡を見つけ、エンドポイントを制限します。

3.秘密のためのリポジトリ/イメージのスキャン、プリコミットスキャナの実装。

アーティファクトの例

1）ホット脆弱性に関するSQLレポート

sql
SELECT service, cve, cvss, epss, exposed, has_exploit, created_at,
PRIORITY(exposed, has_exploit, cvss, epss) AS prio
FROM vuln_findings
WHERE status = 'open' AND (cvss >= 8.0 OR has_exploit = true)
ORDER BY prio DESC, created_at ASC;

2）アドミッションポリシー（Kyverno、脆弱性ブロック）

yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata:
name: block-critical-vulns spec:
validationFailureAction: Enforce rules:
- name: image-must-have-no-critical match: { resources: { kinds: ["Pod"] } }
validate:
message: "Image contains critical vulnerabilities"
pattern:
metadata:
annotations:
vuln.scanner/critical: "0"

3） SBOM生成と署名（Makefile fragment）

make sbom:
cyclonedx create --output sbom.json sign:
cosign sign --key cosign.key $(IMAGE_DIGEST)

iGaming/Fintechの特異性

ハイリスク領域：支払いゲートウェイ、支払いバックフィックス、不正防止、PII/PAN処理-P1/P2優先パッチ。
サービスウィンドウ：トーナメント/プロモーション、プリウォームキャッシュ、ローロード地域のカナリアとの調整。
規制（PCI DSS/GDPR）：脆弱性を修正するためのタイムライン、証拠（スクリーンショット/レポート）、CHDゾーンのセグメンテーション、暗号化。
パートナーインテグレーション：バージョン管理されたSDK/クライアント、必須のSCA、およびWebhook上のHMAC/mTLSが必要です。

よくある間違い

「すべてをスキャン-何も修正」：所有者とSLOはありません。
コンテキスト（露出、EPSS、データ）のないCVSSのみに焦点を当てます。
イメージを再構築する代わりにコンテナランタイムにパッチを適用します。
カナリア/ロールバック計画の欠如。
cloud/K8sのミスコンフィグ（しばしばCVEよりも重要）を無視します。
SBOM/署名なし-サプライチェーン。

実装ロードマップ

1.資産および所有者の在庫;サービス/画像の統一レジスタ。
2.スキャナスタック：SCA/SAST/DAST/Container/Cloud+secret-scan；CI/CDへの統合。
3.SLOと優先順位付けポリシー：CVSS+EPSS+コンテキスト；チケットテンプレート。
4.Admission/Policy-as-Code：重大な脆弱性の禁止、SBOM/署名要件。
5.パッチプロセス：窓、カナリア、ロールバック；マイナーバージョン/パッチバージョンのオートパイロット。
6.レポートとメトリクス：MTTP、カバレッジ、年齢；毎週のリスクレビュー。
7.通常の演習：重要なCVEのシミュレーション、プレイブックの検証、ロールバック。

［結果］

成熟した脆弱性管理は1回限りの「クリーンアップ」ではなく、自動検出、コンテキストの優先順位付け、カナリア/ロールバックによるスムーズなパッチ、Prodの入り口にあるpolicy-as-code、および透明な実行メトリクスです。ベースイメージとパターンのロックを固定することで、反復のリスクを低減し、攻撃面を安定した制御下に保ちます。

Contact

お問い合わせ

ご質問やサポートが必要な場合はお気軽にご連絡ください。いつでもお手伝いします！

統合を開始

Email は 必須。Telegram または WhatsApp は 任意。

お名前 任意
Email 任意
件名 任意
メッセージ 任意
Telegram 任意
@
Telegram を入力いただいた場合、Email に加えてそちらにもご連絡します。
WhatsApp 任意
形式：+国番号と電話番号（例：+81XXXXXXXXX）。

ボタンを押すことで、データ処理に同意したものとみなされます。