ASPM vs CNAPP: Application Posture vs Cloud Posture

AppSec opened a ticket: “payments-api, critical SCA, owner team-payments.” Cloud security opened another: “EKS pod in prod, same CVE, internet-facing, instance role can s3:GetObject on arn:aws:s3:::payments-prod/*.” Leadership asked which tool is wrong. Neither. ASPM vs CNAPP is two inventories of the same running process.

This comparison is who catalogs what, and who is on the hook when both fire. Category soup (CSPM vs CNAPP) is the platform-buy question. How you rank the joined ticket is prioritization.

What ASPM inventories

Application Security Posture Management starts above the cloud resource. Typical objects:

• Services and owners — name, repo, deploy pipeline, on-call, language
• APIs — routes, authn (JWT, mTLS, none), public vs internal, rate limits
• Code risk — SAST, SCA, secrets in git, IaC as it appears in the app repo
• SBOM and image IDs the pipeline produced (not necessarily what is running)
• Service-to-service edges as the app team drew them (OpenAPI, mesh catalog, “calls billing”)

ASPM answers: which product is this, who ships the fix in git, and is the API allowed to be called that way? It is a poor source of truth for security groups, org SCPs, or whether a bucket is public. Those are not application objects.

Failure mode: ASPM that treats “Terraform in the app repo” as complete cloud posture. The platform repo, Control Tower, and click-ops in the console never show up.

What CNAPP inventories

A Cloud-Native Application Protection Platform (in practice: CSPM + CWPP + CIEM + sometimes DSPM) starts from accounts and APIs of the cloud:

• Subscriptions, projects, VPCs, clusters, functions, buckets, queues
• IAM roles, trust policies, effective permissions
• Network reachability and internet exposure
• Misconfigurations and (with agents or snapshots) OS/container vulns on the running image
• Data stores and, if DSPM is on, classification of objects

CNAPP answers: is this reachable, what identity does it run as, what can that identity still do? It is a poor service catalog. “eks-prod-payments-74f9c” is not a Jira component.

Open-source CSPM/CNAPP options and OpenSourceOM sit on this side of the line unless you also ingest SBOM and API catalogs.

Shared runtime

The collision is the running artifact.

Git SHA ──► image digest ──► pod / task / function
                │                    │
         ASPM (SCA on SHA)    CNAPP (CWPP on digest,
                               IAM on the task role,
                               SG / NetworkPolicy)

Same CVE, two timestamps: SCA saw it at merge; CWPP saw it after deploy, possibly on a digest the pipeline did not intend (manual tag, cluster cache). Reconcile on digest, not on service nickname.

Runtime also includes calls the app makes. ASPM may say payments-api only talks to the payments DB. CNAPP may show the task role can sts:AssumeRole into a reporting role that reads a warehouse. That is not an ASPM miss; it is IAM the app model never listed. Graph it (attack path analysis, the graph).

A second overlap: secrets. ASPM finds AWS_SECRET_ACCESS_KEY in a repo. CNAPP finds the same key active on an IAM user. Different owners, one incident if the key is live.

A third: unsigned or mutated images. ASPM’s SBOM is the digest the pipeline signed. CNAPP’s runtime scanner sees what the node actually pulled (latest, a sideloaded tag, a cluster cache). If those digests diverge, the SCA ticket is closed and the running CVE is not. Fail the deploy when the running digest is not in the ASPM catalog.

Do not invent a weekly meeting named “runtime alignment” without a join key. Digest + role ARN is enough.

Who owns which queue

Finding class	Default owner	CNAPP’s job	ASPM’s job
Unauthenticated public API	AppSec / service owner	Confirm internet path, WAF/SG	Authn design, OpenAPI, tests
Public bucket, no app	Cloud security	Close exposure	None unless an app writes there
SCA critical, internal batch job	AppSec	Confirm not internet-reachable	Patch / accept
SCA critical + internet + fat role	Joint	Isolate / shrink role	Patch
Over-privileged IRSA unused	Cloud / CIEM	Right-size	Note if the app still “needs *” in docs
Cluster-admin on a deploy SA	Platform + AppSec	Path from pod	Chart/Helm fix (Kubernetes RBAC)

Rules that survive org charts:

1. Cloud security does not close git tickets. They can block a path (SG, IAM, admission) as a compensating control.
2. AppSec does not “ack” public S3 because the app does not use it. Unused public data is still cloud’s queue.
3. Joint means one ticket, two checkboxes (path broken or code shipped), not two SLAs that both wait.

API inventory gaps belong to ASPM even when CNAPP shows the load balancer as “internet-facing.” A public ALB with an unauthenticated /admin route is not a security-group finding; it is a missing authn check. Conversely, a locked-down API on a public NLB with a world-open target SG is cloud’s queue. Argue from the control that is wrong, not from which tool shouted first.

Cloud-native application security is how a single service is built (mTLS, admission, SAs). This page is only the split of inventories and queues. Zero-trust design of the estate is a different falsification loop (zero trust).

Checklist

• ASPM objects: services, owners, APIs, SCA/SAST, repo secrets—not cloud ARNs as the primary key
• CNAPP objects: accounts, IAM, network, running images—not Jira components as the primary key
• Join key documented: image digest (and task/pod role ARN) for overlapping CVE tickets
• Public exposure without an app owner stays on the cloud queue
• Fat IAM on an app role is CIEM/cloud first; AppSec updates the “we need *” README later
• One joint ticket type for “reachable + exploitable package + data access,” not two copies
• No expectation that a CNAPP purchase retires the SCA/API catalog

---