feat(soc-cortex-xpanse-posture): add Cortex Xpanse vendor pack (posture lifecycle)

[sha-x-ai]

Summary

First Cortex Xpanse vendor pack for the SOC Framework. Routes attack-surface issues from the unified issues dataset through the soc-framework-posture lifecycle under the Posture category. First-vendor consumer for the posture lifecycle.

Architecture

The Cortex Xpanse-XSIAM native integration writes attack-surface issues directly into the unified issues dataset with XDM normalization applied at platform ingestion. There is no cortex_xpanse_*_raw dataset analogous to wiz_generic_alert_raw (verified by XQL autocomplete in x5supreme — no cortex_xpanse_* datasets exposed).

This pack reads from data_source: issues filtered by xdm.issue.detection.method = "XPANSE". This is the first vendor pack to consume issues directly; all existing packs use vendor-specific raw datasets. Pattern ratification needed — see open questions below.

The platform itself stamps every Cortex Xpanse issue with xdm.issue.domain = "POSTURE" and original_tags = ["DOM:Posture", "DS:PANW/ASM"] at ingestion. SOCProductCategoryMap_V3 entry added: ds_panw_asm: Posture.

Verified in x5supreme dev tenant

• Schema validates against tools/generate_vendor_content.py validate
• tools/new_vendor_pack.py emits modeling rule + correlation rule + schema.json cleanly
• IP extraction from xdm.issue.normalized_fields confirmed via bracket-quote JSONPath: "$['xdm.target.host.ipv4_addresses'][0]"
• Pack metadata installs cleanly in tenant
• Dependency chain resolves (soc-framework-posture v1.0.1 uploaded successfully)
• SOCProductCategoryMap_V3 update (ds_panw_asm: Posture) accepted; soc-optimization-unified v3.10.13 installed
• Bare-pack install (metadata only, no content rules) succeeds in tenant

Known blocker

Full pack install fails with error code 101704 at the correlation rule artifact.

Isolation tests run in x5supreme:

Pack contents	Result
Modeling rule + Correlation rule + Metadata	FAIL 101704
Correlation rule + Metadata only	FAIL 101704
Modeling rule + Metadata only	(not tested, but bare-pack baseline succeeds)
Metadata only (no content rules)	SUCCESS

Rejection is isolated to the correlation rule .yml. XSIAM returns 101704 (generic install-failed) with no detailed error message available via the SDK or the tenant install history UI. Would appreciate framework-owner read on the generated correlation rule yml at Packs/soc-cortex-xpanse-posture/CorrelationRules/SOC Cortex Xpanse Posture Finding.yml.

Open questions for ratification

1. data_source: issues precedent. First pack to use this. Should unified-platform-native sources (Cortex Xpanse, AI-SPM, CIEM, future Cortex Cloud sources) adopt this pattern, or fit a different one?

2. Posture category routing value in SOCProductCategoryMap_V3. Used Posture (string). Confirm vs posture_misconfig or other convention.

3. VULNERABILITY-class Cortex Xpanse findings (xdm.finding.type_id = 140000000, CVE-bearing) currently route to posture_misconfig in v1.0.0. v1.1.0 candidate to split to posture_compliance if that aligns with intent. CVE/CVSS/EPSS data lives in joined findings dataset, not on issue row.

4. SOC_Misconfig_{Plan,Execute,Verify} phases are lifecycle-internal seeded stubs (soc-framework-posture). Production phase logic out of scope for this pack.

Parallel variant (not in this PR)

Cloud-routed variant exists at schemas/vendors/cortex-xpanse/cortex-xpanse-cloud.yaml (separate branch, not included in this PR). Mirrors soc-wiz-cloud convention; routes via Cloud category through NIST IR lifecycle. Available if framework-owner prefers Cloud routing over Posture.

Limitations (v1.0.0)

• cloud_provider/cloud_account/cloud_region are null on the issue row. Cortex Xpanse does not expose CSP attribution directly on issues. Future enhancement: enrich via asset_inventory join on xdm.issue.asset_ids[0].
• MITRE tactics not populated (Cortex Xpanse does not natively map findings to ATT&CK).
• Pack does not currently emit DS:Cortex Xpanse tag (only platform-supplied DS:PANW/ASM is used for routing). v1.0.1 candidate.

[sha-x-ai]

Known blocker - architectural

Full pack install fails with error code 101704. Isolation tests in x5supreme dev tenant:

Pack contents	Result
Modeling + Correlation + Metadata	FAIL 101704
Correlation + Metadata only	FAIL 101704
Modeling + Metadata only	FAIL 101704
Metadata only (bare pack)	SUCCESS

Both content rule types fail independently. Common factor: data_source: issues.

The platform appears to reject content rules that target the unified issues dataset at install time. issues is a derived dataset (populated by correlation rules and platform integrations) rather than a raw ingestion target. Modeling rules conventionally run at ingest on raw datasets; correlation rules conventionally read XDM-shaped raw data. Neither pattern fits data_source: issues.

For unified-platform-native vendors like Cortex Xpanse, where the integration writes directly to issues and there is no raw dataset to read from, the framework's standard vendor pack pattern doesn't apply.

Open architectural question

What pattern should unified-platform-native vendors (Cortex Xpanse, AI-SPM, CIEM, future Cortex Cloud sources) use, given that:

• No raw vendor dataset exists to write a modeling rule against
• The platform rejects content rules targeting issues directly
• The data is already XDM-normalized at ingestion (no modeling rule semantically needed)
• The lifecycle dispatch still needs a trigger to invoke EP_Posture

Possibilities to discuss:

1. Automation Rule (instead of correlation rule) - fires playbook directly on issues matching filter, no new alert created
2. Issue Trigger - XSIAM may support trigger-on-issue patterns I haven't found
3. Schema spec extension - data_source: native mode that emits only routing metadata, no content rules
4. Different lifecycle entry - bypass EP_Posture and dispatch via a different mechanism