tenable_io: replace scan details endpoint and remap schema

[chemamartinez]

Proposed commit message

tenable_io/data_stream/scan: fix scan details endpoint and remap schema

The scan data stream's CEL program fetched per-scan details via
GET /was/v2/scans/{id} (Web Application Scanning API) [1] instead of
the correct GET /scans/{id} (Vulnerability Management API) [2].
Because VM scan IDs are not valid in the WAS namespace, every Phase 2
request returned 404. The CEL 404 branch emitted a want_more stub that
the ingest pipeline dropped, so no scan documents were ever produced.
The bug was introduced in #16222; it escaped CI because the system
test mock was hand-authored to return 200 for the WAS path.

This change fixes the endpoint and rebuilds all schema-dependent
artifacts around the standard VM scan-details response:

- CEL program: /was/v2/scans/{id} → /scans/{id}.
- Fields: replace the WAS scan_details group with the full VM schema —
  info (+ acls[]), hosts, comphosts, vulnerabilities, compliance,
  history, notes, remediations, progress.
- Ingest pipeline: replace WAS ISO8601 date processors with UNIX
  processors for info timestamps and foreach processors for history[]
  dates; drop the UI-only filters[] array.
- Mock service: update test routes to /scans/{id} with standard-schema
  bodies so system tests exercise the real endpoint shape.
- Pipeline test fixture and sample event: updated to standard schema.
- Docs: update Phase 2 API reference link to scans-details.

[1] https://developer.tenable.com/reference/was-v2-scans-details
[2] https://developer.tenable.com/reference/scans-details

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Related issues

• Closes [Tenable IO] Fix scan data stream endpoint for scan details #20340

[github-actions]

✅ Elastic Docs Style Checker (Vale)

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[elastic-vault-github-plugin-prod]

✅ All changelog entries have the correct PR link.

[vera-review-bot]

No issues across the latest commits 7f25523.

A new commit triggers another review — at most once every 15 minutes. I skip the PR while it's approved or has merge conflicts.

🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills

⚠️ Automated review — verify suggestions before applying.

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: 7f25523

cc @chemamartinez

[mohitjha-elastic]

Why are both fields defined as keyword? Based on their descriptions, they appear to represent dates, so they should be mapped as date fields, with appropriate date processors on them.

[mohitjha-elastic]

The changelog entry is marked as type: bugfix under 4.13.0 (minor), but this change removes the published WAS scan_details.* fields and replaces them with the VM schema. Since it introduces a breaking schema change, it should be classified as a breaking-change and released as a major version.

If it's truly a bugfix, it should be a patch release (e.g., 4.12.1). As it stands, 4.13.0 with type: bugfix is inconsistent.

[mohitjha-elastic]

VM schema adds hosts[].hostname and info.targets that often hold IPs. Other streams in this CDR package append to related.ip; can we also them to realted.ip?

[mohitjha-elastic]

The comphosts object is missing descriptions for its leaf fields. To keep the schema consistent, could we mirror the field descriptions from hosts (if not available for comphosts) onto the corresponding comphosts leaf fields?