Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
クラウド環境で起きるセキュリティインシデントの多くは、ゼロデイ脆弱性やマルウェアではなく、「ありふれた構成ミス」から始まります。S3バケットの公開設定、IAMロールの過剰権限、セキュリティグループの全開放——いずれもクラウドコンソール上では「正常稼働中」と表示されますが、攻撃者の視点で見れば格好の入口になります。
この記事は、クラウドアカウントの増加に伴う構成管理の煩雑化に課題を感じているセキュリティ担当者・CISO、および DevSecOps を推進する SRE／プラットフォームエンジニアを主な読者と想定し、こうした構成ミスを継続的に検知・是正する CSPM（Cloud Security Posture Management）の役割と限界、KSPM／CWPP／CDR との関係、さらに Sysdig Secure による実装像までを、Plan 段階の入口として体系的に整理します。特に「大量のアラートに埋もれて CSPM が形骸化する」「コンプライアンス対応が年1回の儀式になっている」「構成ベースラインが本番のドリフトに追いつかない」といった、多くの組織が直面する運用上の難題に対し、Sysdig ならではの現実的な解決アプローチを提示します。
CSPMとは何か — 定義と背景
まず、CSPM が「何を見るカテゴリ」なのか、そしてなぜ独立した製品カテゴリとして成立してきたのかを整理します。
クラウド「構成管理」というセキュリティカテゴリ
CSPM（Cloud Security Posture Management）は、IaaS／PaaS のクラウドアカウントに対して、リソースの構成情報・IAM 設定・ネットワーク設定・暗号化設定などを継続的にスキャンし、ベストプラクティスやコンプライアンス基準からの逸脱（=ポスチャ違反）を検出するセキュリティカテゴリです。スキャン対象はワークロードの中身（プロセス・通信・ファイル変更）ではなく、あくまで「クラウドプロバイダーの設定面」に限定されます。
CSPM が見ているのは、AWS／Azure／GCP の API から取得できる構成情報そのものです。S3バケットのパブリックアクセス可否、EC2 に紐づくセキュリティグループ、IAM ポリシーの Allow/Deny、KMS キーのローテーション設定、CloudTrail の有効化状態——こうした構成項目を、ベンチマーク（CIS Benchmarks など）の数百〜数千ルールに照らして合否判定していきます。
IaaS／PaaS／SaaSの境界と責任共有モデル
CSPM が成立する前提には、クラウドの責任共有モデルがあります。IaaS／PaaS 領域では「クラウドの中（ワークロード・アプリ）」はユーザー責任、「クラウドそのもの（物理層・ハイパーバイザ）」はプロバイダー責任という線引きが標準ですが、構成設定はそのほぼ全てがユーザー責任側に属します。CSPM は、このユーザー責任の「構成面」をプログラム的に検査する仕組みと言えます。
責任共有モデルの詳細はクラウドセキュリティとは？責任共有モデルで実現する可視性駆動の保護を参照してください。本記事では「構成は完全にユーザー側責任」という前提だけを押さえて先に進みます。
CSPMが生まれた背景
2010年代後半、クラウド事故の大半が「悪意ある侵入」ではなく「自社の設定ミス」を原因とすることが明らかになってきました。Capital One の AWS WAF 設定不備による情報漏洩、複数の S3 バケット公開事故、IAM 過剰権限を悪用した内部不正——いずれも従来の境界型セキュリティ（FW／IDS／EDR）では検知のしようがありません。なぜなら、攻撃者は「正規の API 呼び出し」しか行っていないからです。
Gartner が CSPM をカテゴリとして定義したのは2018〜2019年頃で、その後すぐに CNAPP（Cloud-Native Application Protection Platform）の主要構成要素として位置付けられるようになりました。CSPM 単体製品から、CWPP（Cloud Workload Protection Platform）／CIEM（Cloud Infrastructure Entitlement Management）／CDR（Cloud Detection and Response）を統合した CNAPP へという潮流については、CNAPPとは何か？で詳しく解説しています。
なぜ今 CSPM が必要か — クラウド構成ミスのインシデント実例
次に、CSPM が対処すべき典型的な構成ミスを、具体例ベースで整理します。
S3バケットの公開設定／IAMの過剰権限／セキュリティグループ全開放
代表的な「構成起因インシデント」は、概ね次の3パターンに集約されます。
- オブジェクトストレージの公開設定ミス：S3／GCS／Blob Storage のバケットを「Public Read」のまま放置し、本来社内限定のはずの顧客データやログがインターネット越しに取得可能になるケースです。過去には大手企業の顧客情報数百万件が、認証なしの GET リクエストで取得可能だった事例が複数報告されています。
- IAM の過剰権限：開発時に付与した Administrator ロールをそのまま本番運用に流用、*:* の Allow ポリシー、退職者・退役サービスに紐づくキーの残置などにより、1つのアクセスキー漏洩で全リソース掌握まで到達してしまう構造です。
- セキュリティグループ／ファイアウォール全開放：踏み台 EC2 や検証用 RDS で 0.0.0.0/0 の SSH／3306 開放を一時的に許可し、そのまま忘れられているケースです。インターネット側から SSH ブルートフォースの標的になりやすい構成と言えます。
これらに加えて、コンテナレジストリ（ECR／GCR）のパブリック設定、Secrets Manager に格納すべきクレデンシャルが平文で環境変数にハードコードされているケース、KMS で暗号化されていない EBS／RDS ボリューム——いずれも CSPM のスキャン対象に含まれます。
マルチクラウド時代の「構成のスケール問題」
リソースが100個程度であれば、月次のスポット監査でも構成ミスは追えます。しかし実際のエンタープライズ環境では、AWS／Azure／GCP の3クラウド×複数アカウント×数万リソースが標準になりつつあります。手作業の点検は、母数が増えるほど見落としが指数関数的に増えていきます。
加えて、IaC（Infrastructure as Code、Terraform／CloudFormation）と手動オペレーションが混在する現場では「IaC では正しく書かれているが、本番環境で『ドリフト（意図しない設定の乖離）』が発生している」という状態が常態化します。CSPM が継続スキャンを行う最大の意義は、この「規模 × ドリフト」の問題を機械的に押さえられる点にあります。
コンプライアンスの自動化要求
PCI-DSS／HIPAA／SOC2／ISMAP／FISC など、業界・地域別のコンプライアンス要件の多くは「クラウド構成」に直接マッピングできます。たとえば PCI-DSS 4.0 の「保存データの暗号化」は、AWS であれば EBS／S3／RDS の暗号化設定として検査可能であり、CIS AWS Foundations Benchmark の各項目はそのまま CSPM ルールとして実装されています。
監査対応における CSPM の価値は、「年1回の監査スナップショット」ではなく「日次の継続的なコンプライアンス証跡」を自動生成できる点にあります。これは監査人にとっても運用側にとっても、大きな省力化要素となります。
CSPMの主要機能
ここでは、CSPM 製品が共通して備える主要機能を、機能カテゴリの軸で整理します。
以下、それぞれの機能カテゴリについて、設計上のポイントを順に見ていきます。
構成スキャン（インベントリ収集とドリフト検知）
CSPM の出発点は、対象クラウドアカウントの全リソースを継続的に列挙し、正規化されたインベントリとして保持することにあります。スキャンは数十分〜数時間周期で繰り返され、前回スナップショットとの差分を取ることで「いつ・誰が・何を変更したか」というドリフトを可視化できます。
IaC で宣言したベースラインからの逸脱を CSPM 側でフラグできるようになると、Terraform で private と定義したバケットが手動で public-read に変更されたケースなどを、変更直後に検知できるようになります。
コンプライアンスチェック
CSPM のコンプライアンス機能は、「ベンチマーク（CIS／NIST）」と「業界規格（PCI-DSS／HIPAA／ISMAP）」の2層で提供されることが多いです。各規格の管理要件は CSPM 内部のルールセットに翻訳され、ルールごとに合否・該当リソース・修正手順がレポート化されます。
日本市場では、業界・業態ごとに異なる規格対応が求められます。政府系では ISMAP（政府情報システムのためのセキュリティ評価制度）、金融系では FISC 安全対策基準、自動車・製造業では JAMA／JAPIA サイバーセキュリティガイドラインや IATF 16949、医療系では3省2ガイドライン、重要インフラ系では各業界の所管ガイドラインや JNSA／IPA の提言——いずれの場合も、CIS Benchmarks や PCI-DSS と重複する管理要件を整理しつつマッピングを揃えておくと、監査側の照合工数を大きく削減できます。グローバルで運用する組織であれば、SOC2／NIST 800-53／ISO 27017 と国内規格のクロスマッピングを Plan 段階で確定させておくと、後工程の認証取得が滑らかに進みます。なお、これら国内外の多様なコンプライアンス要件を、手動ではなく自動で継続監査する具体的な仕組みについては、本記事第8章「Sysdig Secure の CSPM 機能」で後述します。
IAM分析と過剰権限の可視化
IAM は CSPM の中でも特に難易度の高い領域です。単一ポリシーの記述ミスだけでなく、「複数ポリシーの合成結果」「ロール継承の連鎖」「サービスごとのアクション粒度」「リソースベースポリシーとの相互作用」を踏まえた到達可能性分析が必要になります。
代表的なチェック項目としては、*:* を含むポリシー、AdministratorAccess を本番運用ロールに付与したもの、90日以上未使用のアクセスキー、MFA 未設定のルートアカウント、サービスアカウントへの過剰な iam:PassRole などが挙げられます。これらは CIEM と重なる領域でもあり、CNAPP 製品では CSPM と CIEM が統合提供されることが一般的になっています。
ネットワーク・暗号化の構成検証
ネットワーク層では、0.0.0.0/0 開放の有無、ALB／NLB の TLS バージョンとサイファースイート、API Gateway の認証必須化、VPC Flow Logs の有効化、PrivateLink 経由ではなくインターネット越しに公開されている内部 API などを検査します。
暗号化層では、保存データの暗号化（EBS／S3／RDS／DynamoDB／EFS）、通信路の TLS バージョン、KMS キーのローテーション設定、CMK／AWS マネージドキーの使い分けなどがチェック対象になります。
自動修復（Auto Remediation）と手動承認のバランス
CSPM の自動修復は強力な機能ですが、本番運用では「全自動」と「全手動」の中間設計が現実的です。たとえば公開 S3 バケットの非公開化は自動、SG ルールの削除は手動承認、IAM ポリシーの変更はチケット駆動——のように、検出ルールごとに修復モードを切り替えるのが定石となります。
ここで重要なのは、修復アクションが業務影響を持つ可能性があるという点です。意図して公開していた静的サイトホスティング用のバケットを誤って非公開化すれば、サービス停止に直結します。CSPM の運用設計では「修復の前に、所有者・用途のメタデータが揃っているか」が成否を分ける鍵となります。
CSPMが扱うスコープと限界 — 「構成は見えるがランタイムは見えない」
CSPM がカバーする範囲と、そこから先に必要になる Run 段階の検知の役割分担を明確化していきます。
構成検査だけでは検知できない攻撃
CSPM は強力ですが、見えるのは「設定」までです。次のような攻撃は、構成スキャンだけでは検知できません。
- 正規権限内での悪用：漏洩したアクセスキーで s3:GetObject を行う攻撃。IAM ポリシー上は許可されているため、CSPM はアラートを上げません。CloudTrail のログだけ見ても「正常なアクセス」と区別がつかないケースが多いと言えます。
- ワークロード内部の不正挙動：コンテナ内でクリプトマイナーが起動した、シェルが生成された、/etc/passwd が読み取られた——いずれも構成ミスではなくランタイムイベントに該当します。
- ライブラリ脆弱性の悪用（exploit-in-the-wild）：脆弱性が CVE として既知でも、それが「実際に攻撃に使われているか」「該当プロセスが実際にロードされているか」は構成情報だけでは判別できません。
- データ持ち出しの実態：誰が、いつ、どのデータに、どの程度アクセスしたか——構成は「アクセスできる状態か」を示すだけで、「アクセスが行われたか」までは示しません。
これらは Run 段階の検知（CWPP／CDR）が担う領域です。Syscall・eBPF を用いたランタイム検知の仕組みはコンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組みに集約していますので、Run 段階の設計はそちらを参照してください。
CSPM単体運用のアンチパターン
CSPM だけで運用しようとすると、次のようなアンチパターンに陥りやすくなります。
- アラート疲れ：CSPM の検出ルールは数百〜千を超えるため、優先度付けなしに全件をチケット化すると、開発・運用チームが対応しきれずに形骸化します。
- 「設定上は安全」の罠：CSPM 上ですべて緑になっていても、実際に侵害が起きていないことの証明にはなりません。ランタイム検知がなければ、攻撃の成立は被害発生後にしかわかりません。
- コンプライアンス報告だけの存在化：CSPM が監査資料生成ツールに矮小化され、セキュリティ運用に組み込まれない状態です。これは特に、CSPM 単体製品を導入し、CDR／CWPP と接続しなかった現場で起こりやすいと言えます。
CSPM は Plan 段階の入口として必須ですが、それ単体で「クラウドセキュリティの全体」を担うことはできません。Plan・Build・Run・Respond を貫く設計が必要であり、その全体像はクラウドセキュリティ完全ガイド｜構成ミスからランタイム脅威まで「Code to Runtime」で守るにはで扱っています。
KSPM（Kubernetes Security Posture Management）との関係
CSPM と並列で語られることの多い KSPM の役割と、両者の住み分けを整理します。
K8sマニフェスト・RBAC・Network Policyの構成検査
KSPM は、Kubernetes クラスタの構成面に特化した CSPM の派生カテゴリです。検査対象は次のようにレイヤが異なります。
EKS／AKS／GKE のマネージド K8s では、「外側（クラウドAPI経由の設定）」と「内側（K8sマニフェスト）」が連動して攻撃経路を構成します。下図は、CSPM が見る外殻と、KSPM が見るクラスタ内部のレイヤ関係を概念化したものです。
flowchart TB
subgraph CSPM["CSPM が見る領域（クラウドプロバイダー API）"]
direction LR
A1["IAMロール / ポリシー"]
A2["VPC / SG / Public Endpoint"]
A3["KMS / S3 / EBS 暗号化"]
A4["EKS クラスタ構成<br/>(Control Plane 公開範囲)"]
end
subgraph KSPM["KSPM が見る領域（Kubernetes API）"]
direction LR
B1["Pod / Deployment<br/>(特権 / hostNetwork)"]
B2["RBAC / ServiceAccount"]
B3["NetworkPolicy / PSA"]
B4["Secrets / ConfigMap"]
end
A4 -. "kube-apiserver 公開" .-> B1
A1 -. "IRSA / Workload Identity" .-> B2
A2 -. "Pod Egress / Ingress" .-> B3
A3 -. "暗号化キー利用" .-> B4
classDef cspm fill:#E3F2FD,stroke:#1976D2,color:#0D47A1
classDef kspm fill:#E8F5E9,stroke:#388E3C,color:#1B5E20
class A1,A2,A3,A4 cspm
class B1,B2,B3,B4 kspmCSPM が「クラウドの外殻」を見るカテゴリだとすれば、KSPM は「クラスタの内側」を見るカテゴリと言えます。EKS／AKS／GKE のマネージド K8s であっても、コントロールプレーンの一部設定はクラウドプロバイダー側（=CSPM 領域）、ワークロード定義は K8s 側（=KSPM 領域）と二段構造になります。点線は両レイヤをまたぐ典型的な連動関係（IRSA／Workload Identity、kube-apiserver 公開、Egress 制御、暗号化キー連携）を示しており、片側だけのポスチャ管理ではこの連鎖を捕捉できません。
CSPMとKSPMはどう統合すべきか
実運用上、CSPM と KSPM を別々の製品で運用すると、アラートの重複・抜け漏れ・優先度ロジックの不整合が起こりやすくなります。たとえば「EKS クラスタが Public Endpoint で公開されている（CSPM 検出）」と「特定 Pod が hostNetwork: true で動作している（KSPM 検出）」は、本来一連の攻撃経路として評価すべきものですが、別ツールでは別アラートとして扱われてしまいます。
CNAPP の文脈では、CSPM／KSPM は同一プラットフォーム上で統合され、さらに CWPP（ランタイム）／CIEM（権限）／CDR（検知）と相関させることで「攻撃経路ベースの優先度付け」が可能になります。Plan 段階の設計時点で「CSPM と KSPM を別管理にしない」ことを決めておくと、後の運用負荷を大きく減らせます。
CSPMとCNAPPの関係 — Plan段階の入口
この章では、CSPM が CNAPP 全体の中でどの位置にいるかを整理します。
CNAPPの構成要素としてのCSPM／CWPP／CIEM／CDR
CNAPP は単一の機能ではなく、Plan から Respond までを横断的に支える複合カテゴリです。主な構成要素は次のとおりです。
CNAPP プラットフォーム全体の解説はCNAPPとは何か？、CWPP はCWPPとは？、CDR はCDRとは？、CTEM（Continuous Threat Exposure Management、露出管理）はCTEMとは何かを参照してください。
Plan→Build→Run→Respond の各段階で CSPM が果たす役割
CSPM の役割は Plan 段階に集中しますが、他段階とのインターフェースを持つことで効果が最大化されます。
- Plan：構成ベースラインの定義、コンプライアンス目標の設定、CSPM ルールセットの選定
- Build：CSPM ルールを IaC スキャンに転写し、Terraform／CloudFormation 段階で同等チェックを行う（シフトレフト）
- Run：ランタイム検知の結果を CSPM の優先度付けに還流する（後述）
- Respond：CSPM 検出がインシデント分析時のコンテキストとして使われる（侵害された IAM ロール、その権限範囲、影響リソースの特定）
シフトレフトの具体はシフトレフト（Shift Left）とは？コンテナセキュリティをCI/CDに組み込む実践ガイドで扱っています。
CSPMだけ・CWPPだけ・CDRだけの「点導入」が抱える限界
実務でよく見かけるのが、「CSPM だけ先に入れた」「ランタイム検知ツールだけ入れた」「ログ SIEM だけ入れた」という点導入のパターンです。これらが失敗する理由は概ね共通しています。
- 構成情報（CSPM）と実行情報（CWPP／CDR）が紐づかず、優先度判定の根拠が弱くなる
- 同一資産に対して別々のチケットが発行され、対応工数が重複する
- 共通の脆弱性・露出ビューが存在せず、経営報告でも個別ツールのスコアを並べることしかできない
CSPM は CNAPP の入口ですが、「入口だけで止まらない」ことを最初の設計時点で決めておくことが、Plan 段階の最重要決定事項の一つになります。
CSPMの導入・運用設計
この章では、CSPM の導入を「ツール導入」ではなく「運用設計」として組み立てる手順を示します。
導入の3ステップ（スキャン → 優先度付け → 修正フロー設計）
初回スキャンでは数千件単位の検出が出るのが普通です。重要なのは件数そのものではなく、「公開かつ機密データを含むか」「侵害された場合の影響範囲はどこまでか」という軸でトリアージする視点になります。
開発チームへのフィードバック（IaCのシフトレフト連携）
CSPM の検出を本番だけで潰しても、同種のミスは IaC テンプレート由来で再発します。CSPM ルールを IaC スキャンに展開し、PR の段階でブロック・警告に格上げすることで、根本対処につながります。Terraform であれば tfsec／checkov、Helm Chart であれば kubesec／kube-linter といった OSS と CSPM ルールセットを揃えておくと、Plan と Code の境界で同じ判定基準が働きます。
シフトレフトの設計指針と CI/CD への組み込み方は、シフトレフト（Shift Left）とは？コンテナセキュリティをCI/CDに組み込む実践ガイドに詳しくまとめています。
役割分担とSLA
CSPM 検出の所有者は、リソースのオーナーチーム（開発／プラットフォーム／データ）であって、セキュリティチームではありません。セキュリティチームの役割は、ルールセットの定義・優先度判定・例外承認・横断レポートであり、修正そのものは「リソースを作った人」が行う設計にするのがポイントです。
SLA は重大度・露出度ごとに段階を設けるのが定石で、たとえば「インターネット公開＋機密データ含むはX営業日以内」「内部のみのSGミスはY営業日以内」のような階段設計になります。Critical 件のランタイム連動 SLA や RACI の具体設計はDevSecOpsとコンテナセキュリティで個別に扱っていますので、運用設計を詰める段階ではそちらと併読してください。
Sysdig SecureのCSPM機能
ここでは、Sysdig Secure が CSPM カテゴリでどのように実装しているかを概観します。
構成スキャン・コンプライアンス自動化・Risk Spotlight
Sysdig Secure の CSPM 機能は、主要クラウド（AWS／Azure／GCP／OCI）と K8s（EKS／AKS／GKE／OpenShift／オンプレ）を統一ビューで扱い、CIS Benchmarks／PCI-DSS／HIPAA／SOC2／ISMAP／NIST 800-53 などのコンプライアンスパックを標準提供します。検出されたリスクは、リソースの公開度・データ機密度・脆弱性の同時保有状況に基づいて優先度が付与されます。
特徴的なのが Risk Spotlight に代表される「リスクの集約ビュー」です。CSPM が見つけた構成リスクと、CWPP が見つけたランタイムリスク（脆弱性・実行中プロセス・通信）が、同一アセット単位で統合表示されます。これにより、たとえば「公開された S3 バケット × 該当 IAM ロールが侵害された経路 × ロールを使う実行中ワークロード」というクロスドメインの攻撃経路が、一画面で評価できるようになります。
アラート疲れを解消する — Run（ランタイム）の知見をCSPMに還流するSysdigの設計思想
Sysdig のアプローチで重要なのは、Plan で見つけた構成リスクを Run の情報で「重み付け」する点です。たとえば、IAM ポリシーで広範な権限が付与されていても、その権限が実際に使われていなければ優先度は下がります。逆に、構成上は妥当に見えても、ランタイムで該当ロールが普段と異なる API を叩き始めれば優先度が跳ね上がる、という仕組みです。
このランタイム由来の優先度付けの中核には、Falco をベースにした eBPF／Syscall レベルの観測があります。実運用上のビジネスインパクトとしても、たとえば数千件規模で検出される「Critical」アラートの中から、「実際に実行中で、かつ外部から攻撃経路が存在する」真に対応が必要なごく数％（数十件オーダー）へとノイズを劇的に絞り込むことが可能になります。これにより、セキュリティチームのトリアージ時間と開発チームの修正工数を桁違いに圧縮し、「Critical が大量に並んでいるが、誰も対応しきれない」という典型的なアラート疲れの状況から脱出することが可能になります。具体的な削減率の実測値・メカニズム・お客様事例は、Runtime Insights のカノニカル記事であるコンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組みに集約していますので、CISO や経営層向けに ROI を説明したい場合はそちらを併せて参照してください。CSPM 単独では実現できない「Plan ↔ Run の往復」を、CNAPP プラットフォーム上で閉じることが Sysdig の設計思想です。
まとめ — Plan段階の防衛線として CSPM を組み立てる
CSPM は、クラウド構成のミスを継続的に検知する Plan 段階の入口カテゴリです。S3 公開、IAM 過剰権限、SG 全開放、暗号化漏れといった典型的な構成リスクを、CIS Benchmarks や各種コンプライアンス規格と突き合わせて自動評価します。日次レベルの監査証跡が機械的に生成できる点は、コンプライアンス対応の省力化として非常に大きな価値があります。
一方で CSPM は、構成は見えてもランタイムの異常挙動・正規権限の悪用・攻撃の成立可否までは見えません。これらは CWPP／CDR が担う領域であり、CSPM 単体での運用は「設定上は安全」という錯覚を生みかねないものです。Plan 段階の設計では、CSPM／KSPM を CNAPP の構成要素として位置付け、Build／Run／Respond と接続することが前提となります。
導入においては、ツール選定よりも「優先度付けの基準」「所有者と SLA」「IaC へのシフトレフト連携」を先に決めることが、CSPM の形骸化を防ぐ最大のポイントになります。Plan 段階で組み上げた構成ベースラインを、Run の知見でアップデートし続ける——この往復こそが、CSPM をコンプライアンスレポートツールに矮小化させず、クラウドセキュリティの実効的な防衛線として機能させる鍵となります。
関連記事
- CNAPPとは何か？クラウドネイティブ時代に求められるセキュリティの新常識
- CWPP（Cloud Workload Protection Platform）とは？クラウドワークロードを守る最新セキュリティ基盤
- CDR（Cloud Detection and Response）とは｜クラウドを守るリアルタイム防御とSysdigのアプローチ
- CTEMとは何か｜攻撃者視点でクラウドの弱点を可視化する新しいセキュリティ戦略
- シフトレフト（Shift Left）とは？コンテナセキュリティをCI/CDに組み込む実践ガイド
- コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み
- DevSecOpsとコンテナセキュリティ｜SREが知っておくべき運用設計の考え方
- AI時代のクラウドセキュリティ