CNAPP & Cloud-Native Runtime Security Roadmap

Start from assets, trust boundaries, attackers, and response questions. A tool inventory is not a security inventory, and a scanner queue is not a risk model.

• Read NIST SP 800-190 and map image, registry, orchestrator, container, host, and operational risks
• Use the CNCF Cloud Native Security Whitepaper to connect build, distribution, deployment, and runtime
• Define provider, operator, platform, application, security, and incident responsibilities
• Identify public exposure, shared kernel, control-plane, runtime socket, identity, registry, telemetry, and evidence boundaries
• Create stable provider, account, cluster UID, namespace, workload UID, container, digest, owner, and lifecycle keys
• Represent pass, fail, excepted, unknown, and stale evidence separately
• Record collector, audit, sensor, policy, vulnerability database, and rule freshness
• Prioritize using business criticality, exposure, privilege, artifact, behavior, and compensating controls

Establish exact artifact identity before applying trust. Presence of a scan, signature, or attestation is not enough; policy must verify the intended subject and producer.

• Build once and promote an immutable digest instead of rebuilding or trusting mutable tags
• Generate an SBOM and associate it cryptographically or operationally with the exact digest
• Record scanner, database, timestamp, coverage, severity, fix, reachability, and exploit preconditions
• Use OpenSSF guidance as signals and practices, not proof that software is secure
• Generate SLSA provenance describing subject, source, builder, workflow, and relevant parameters
• Sign with Sigstore or another reviewed model and verify expected identity, issuer or trust root, and digest
• Deny unknown source, builder, workflow, signer, altered attestation, and subject mismatch
• Create exact-digest, owner-approved, expiring vulnerability exceptions with re-evaluation triggers

Layer fast review feedback with enforcement on the final mutated object. Reduce blast radius so one application exploit does not become a cluster or cloud incident.

• Understand authentication, authorization, mutation, validation, persistence, and audit as distinct stages
• Use Pod Security Baseline and Restricted deliberately, pin versions, and test namespace labels and exemptions
• Run non-root, disable privilege escalation, apply RuntimeDefault seccomp, drop capabilities, and avoid host access
• Review RBAC wildcard, bind, escalate, impersonate, nodes/proxy, CSR, token, webhook, and workload-create paths
• Disable ServiceAccount token automount when unused and prefer short-lived audience-bound identity
• Use default-deny ingress and egress with explicit DNS and required paths on an enforcing network plugin
• Encrypt Secrets at rest, restrict get/list/watch, isolate mounts, rotate, redact, and avoid source control
• Test webhook timeout, failure policy, certificate expiry, policy regression, bypass, and recovery

Move from assigned roles to effective access. A principal with no direct Secret read can still reach Secrets through workload creation or another service account.

• Build a graph of users, groups, service accounts, roles, bindings, verbs, resources, subresources, and namespaces
• Model workload creation, mountable resources, namespace service accounts, admission, and Pod Security constraints
• Add synthetic workload-identity bindings to external cloud roles and record subject and audience policy
• Separate observed use from approved need and test staged least-privilege changes
• Normalize provider, account, trust domain, cluster UID, namespace, principal, and workload identity
• Map the public CIS Kubernetes Benchmark overview to the exact cluster or managed distribution version
• Record provider-managed, customer-managed, unavailable, manual, and exception states
• Alert on ownerless assets, stale collectors, expiring exceptions, broad bindings, and cross-cluster collisions

Learn what a runtime sensor can observe, what privileges it needs, where it can lose data, and how to create rules that survive legitimate operations.

• Understand eBPF program types, hooks, contexts, helpers, maps, buffers, loader capabilities, and verifier scope
• Threat-model the sensor, BPF filesystem, host mounts, kernel compatibility, BTF or CO-RE, and node placement
• Learn Falco event sources, rule fields, conditions, macros, lists, priorities, tags, outputs, and metrics
• Detect unexpected shell ancestry, executable writes, sensitive file access, package tools, privilege and egress
• Correlate Pod UID, container ID, image digest, parent process, user, service account, node, and revision
• Create positive synthetic fixtures, representative benign fixtures, and output or sensor failure tests
• Tune with narrow workload context, owner, expiry, and residual-coverage tests
• Monitor rule loading, driver health, captured events, dropped syscalls, output queues, delivery, and stale nodes

Turn events into behavior chains and response decisions. Preserve evidence before ephemeral workloads disappear, while avoiding destructive automation from uncertain alerts.

• Correlate shell, token-path read, new executable, unexpected egress, identity use, and audit change into a chain
• Define alert priority, confidence, asset criticality, owner, runbook, case threshold, and safe fields
• Use human-approved egress isolation, identity revocation, scaling, or node isolation according to scenario
• Capture Pod UID and owner, node, image and container IDs, processes, files, network, audit, identity, and sensor health
• Separate confirmed facts, hypotheses, unknowns, and evidence gaps in the incident timeline
• Investigate equivalent images, identities, entitlement paths, persistence, desired-state changes, and sibling workloads
• Replace suspected nodes from trusted state and rotate exposed authority rather than only deleting a Pod
• Validate service recovery, trusted state, absence of known persistence, detection health, and regression tests

Security telemetry is itself a sensitive, costly system. Design for data minimization, bounded failure, explainable coverage, and measurable outcomes.

• Use Kubernetes audit levels intentionally and avoid Secret or sensitive request bodies by default
• Retain source and ingestion timestamps, source record IDs, clock-skew and delivery-delay evidence
• Use per-environment short-lived integration identity, protected transport, minimum write access, rotation, and revocation
• Bound buffers, retries, cardinality, payload sizes, duplicates, retention, and outage behavior
• Prefer metadata, hashes, field allowlists, and redaction; escalate sensitive capture only under procedure
• Track coverage freshness, true and benign dispositions, duplicates, triage and containment time, recurrence, and test health
• Track node overhead, event volume, ingestion, storage, egress, retention, analyst time, and exception backlog
• Give every exception owner, approval, scope, rationale, compensating controls, expiry, revocation, and review evidence

Complete all three projects. The goal is not a perfect dashboard; it is defensible evidence that controls, detections, coverage, response, recovery, economics, privacy, and cleanup work together.

• Build a digest-pinned pipeline with SBOM, vulnerability evidence, Sigstore verification, SLSA provenance, and admission
• Deploy Falco, generate safe synthetic behaviors, tune maintenance noise, test dropped events, and run approved containment
• Normalize three clusters into an inventory, posture, entitlement, runtime, audit, exception, freshness, and cost dashboard
• Inject artifact tampering, webhook outage, policy drift, collector loss, event pressure, output outage, and cross-cluster collisions
• Run a tabletop from overprivileged workload identity and runtime chain through containment and recovery
• Complete all 50 checks and explain why every wrong option fails
• Publish sanitized architecture, source traceability, test matrices, metrics, incident timeline, limitations, and cleanup proof
• Revoke authority first, remove workloads and sensors, delete evidence and clusters, and verify ports, processes, credentials, and cost