This wide scope makes for a messy demarcation between ASPM and other security tool categories, further complicating the buying decision process. Caleb Sima wrote about this problem in 2024, stating that figuring out the risk of a particular asset isn’t simple: “To properly answer this, you’d need to gather information from various tools such as CSPM [cloud security posture management], DSPM [data security posture management], ASPM, and IAM [identity and access management]. You’d have to generate reports from each of these products because they don’t communicate with each other. An asset can be an application, contain data, reside in the cloud, and have associated privileges. It’s a painful process to collect data from separate products, mash it up, and present it to someone for review.”
IDC’s Norton offers a more succinct way of looking at ASPMs: “They should do three things: data ingestion, prioritization, and remediation of the necessary applications.”
Two approaches to ASPM
Part of the problem in understanding the scope of any ASPM is because vendors approach the task from two different directions: code-first or cloud-first. The former reflects a more DevOps environment, beginning with an emphasis on software development and code pipeline testing. The latter starts with the cloud estate — and any on-premises applications — and works back to the specific applications. In either case, a massive amount of data is collected to document and fix potential security violations, set up policies for compliance, ensure that various digital secrets are managed properly, and other tasks. Examples of the former include Cycode, and the latter include Wiz.
