Netskope CSPM, SSPM & DSPM — Cloud & SaaS Posture

① Why posture exists — out-of-band, not inline

Everything in this series so far has been inline: traffic is steered to Netskope, the engine decrypts it, a policy decides allow or block, all in real time. Inline is brilliant at one thing — stopping a bad action as it happens. But it has a blind spot the size of your whole cloud estate.

Think about what inline can never see. A developer at TCS leaves an S3 bucket public on Tuesday. Nobody uploads anything through Netskope — the bucket just sits there, exposed, until a scanner finds it on Friday. A Salesforce admin at Flipkart switches off a security setting. A team spins up a database full of customer PII that IT never knew existed. None of this is traffic. It is configuration and data at rest — and that is what posture management watches.

CSPM, SSPM and DSPM are out-of-band and API-driven. They do not sit in the traffic path. Instead they connect to your cloud and SaaS providers’ APIs on a schedule, read the configuration (and, for DSPM, the data), score it against compliance frameworks, and raise findings for you to fix. Same Netskope One console, completely different engine.

Four terms before we go deeper

Tap each — these recur through the whole lesson.

② The four engines — CSPM, SSPM, DSPM, CIEM

People lump “posture” into one word, but there are really four engines, and the interview-grade distinction is what each one scans.

CSPM scans your public-cloud configuration — AWS, Azure, GCP — looking for misconfigurations: a public bucket, an open security group, an unencrypted volume, an over-broad IAM policy. It scores everything against frameworks like CIS, NIST and PCI. Netskope calls the scan loop Continuous Security Assessment (CSA), and you can even write custom rules in a DSL.

SSPM does the same idea but for SaaS tenant settings — the M365 stack (Entra ID, Defender, Exchange, SharePoint, Teams, Intune), plus Salesforce, Google Workspace, GitHub, Okta, Box, Slack, ServiceNow, Workday and more. It checks against benchmarks like CIS, CISA SCuBA, GDPR, HIPAA, ISO 27002 and PCI-DSS 4.0, and offers Guided Remediation to walk you through the fix.

DSPM is the different one. It does not check settings — it goes inside the stores and finds the actual sensitive data at rest. It discovers data stores, schemas, tables, fields and files (including shadow data stores nobody knew existed), classifies the data, and even profiles which users have over-privileged access to it. CIEM is the identity angle: it walks your cloud entitlements and flags over-permissioned identities so you can enforce least privilege.

That comparison is the single most important idea in this lesson. CSPM and SSPM check the settings; DSPM checks the data. A bucket can be encrypted, private and versioned — CSPM gives it a green tick — and still be stuffed with 42,000 unclassified Aadhaar numbers that DSPM flags as high risk. Run config-posture and data-posture; neither alone is the full picture.

③ Onboarding — AWS for CSPM, Salesforce for SSPM

Posture engines see nothing until you onboard the target. Onboarding = granting Netskope read access to the provider’s API. The exact console path differs by engine, and mixing them up is the most common newbie mistake — so learn both paths precisely.

CSPM — onboard an AWS account

For public-cloud CSPM the path is Settings → Configure App Access → Classic → IaaS → Setup. Note the words Classic and IaaS — this is the CSPM lane. The onboarding flow is Continuous Security Assessment (CSA) and runs in two phases the console literally labels “Step 1/2: Configure AWS Accounts & Services for CSA” and “Step 2/2: Configure AWS Permissions for CSA.” Before you start, prep a list of AWS Account numbers, Account names and optional email addresses; in step 2 you download Netskope’s CloudFormation Template (CFT, aws-instance-setup.yml) and run it in the AWS console (CloudFormation → Create stack) to create a cross-account IAM role Netskope assumes to read the config. Finish with Add Accounts to land them on the Classic → IaaS page.

SSPM — onboard a Salesforce tenant

For SaaS SSPM the path is different: Settings → Configure App Access → Next Gen → Security Posture. Note Next Gen and Security Posture — this is the SSPM/DSPM lane, not Classic/IaaS. Click the Salesforce icon → Setup Security Posture Instance and fill the form: Site Domain (e.g. sample.my.salesforce.com), Administrator Email, Security Scan Interval, and optional Instance Name. Then Grant Access → authenticate → Allow → Close, and refresh the browser.

④ DSPM scanners, the three gotchas & SkopeAI

DSPM onboards differently because it has its own Netskope One DSPM application (separate from the SSE console’s Configure App Access menus) and has to reach inside the stores. The flow is: Administration → Infrastructure Connections → Add Infrastructure (select AWS / Azure / GCP / OCI → Add Account/Organization — typically via a CloudFormation, Terraform or Helm deploy that grants discovery IAM roles), enable Auto-Discover New Data Stores, then deploy a scanner (sidecar) — administered under Platform Settings → Sidecar — so sensitive data never leaves your environment to be classified. From there the left-nav gives you Data Stores (inventory), Classification & Tagging, Policies & Alerts, and Risk / User Assessment dashboards & reports.

Gotcha 1 — Azure multi-subscription needs per-subscription Event Grid

When you onboard a whole Azure Management Group for CSPM, you create one Azure AD App (recording its Directory ID, Application ID and Authentication Key) and assign a custom role at the group level. But teams hit a wall: data only shows for some subscriptions. The cause is that Microsoft Event Grid registration is per-subscription and cannot be done group-wide in one shot. Register Event Grid on every subscription individually, and reuse the same Azure AD App — do not mint a new Authentication Key per sub, which breaks the existing binding.

Gotcha 2 — CSPM does not auto-remediate

New engineers expect CSPM to fix what it finds. It does not. Netskope CSPM surfaces findings; remediation is manual — or a framework you build. The community pattern for AWS auto-remediation is a Lambda + CloudFormation StackSets setup that polls the Netskope API, deployed per region in the delegated security account (not the Org management account), with cross-account IAM roles. The function re-checks compliance before acting, so it does not “fix” a false positive.

GET /api/v2/posture/findings?status=open&severity=high
Host: tenant.goskope.com
Authorization: Bearer 

{
  "finding_id": "csa-aws-1182",
  "account": "482915736204",
  "rule": "S3 bucket must block public access",
  "framework": "CIS AWS Foundations",
  "resource": "s3://payroll-export-prod",
  "status": "open",
  "auto_remediated": false   <-- CSPM never sets this; your StackSets Lambda must
}

Gotcha 3 — posture is scan-interval driven, not instant

Because posture is out-of-band, a finding lags the change that caused it by up to one scan cycle. “The compliance score looks stale / a new misconfig isn’t flagged yet” almost always means the scan hasn’t run since the change. Tighten the Security Scan Interval if you need fresher data — but never expect inline-DLP immediacy from a posture engine. They answer different questions.

The 2025 angle — DSPM meets AI (SkopeAI)

The newest reason posture matters: AI. In April 2025 Netskope shipped Netskope One DSPM innovations under the SkopeAI brand that use DSPM’s data classification to stop sensitive or regulated data feeding LLMs — whether by direct input, RAG, or fine-tuning — with policy-driven AI governance. This ties DSPM to AI-SPM: you cannot govern what an AI is allowed to ingest unless you first know where your sensitive data is. That is DSPM’s job.