[Contextual Security][CNVM] change vulnerability.published_date field type from keyword to date

[alexreal1314]

This is a BREAKING CHANGE that updates the field mapping that aligns cnvm with other integrations - tenable_io, m365 etc.

Summary

This PR updates the vulnerability.published_date field mapping from keyword to date type in the Cloud Native Vulnerability Management (CNVM) integration. The change includes:

1. modifying the field definition in fields/vulnerability.yml to use the date type
2. adding a date processor to the ingest pipeline (default.yml) that parses the published_date field using ISO8601 format with proper error handling.
3. bumping the package version from 3.1.1 to 4.0.0 following semantic versioning for breaking changes
4. documenting the breaking change in changelog.yml. The ingest pipeline processor includes conditional logic to only parse the field when it exists and is not empty, with on_failure handling to append error messages without breaking the entire pipeline.

change was made to address this issue.

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

Breaking Change Impact

⚠️ Important: This is a breaking change that will result in mapping conflicts within the data stream during the upgrade process:

• Existing indices will retain the old keyword mapping for vulnerability.published_date
• New indices (created after rollover) will use the new date mapping
• Multiple backing indices with different mappings will coexist under the same logs-cloud_security_posture.vulnerabilities-* data stream

User Impact:

• Queries spanning both old and new indices may produce inconsistent results or errors due to field type conflicts
• Sorting by vulnerability.published_date will work correctly only for data in new indices
• Data views and dashboards may show mapping conflicts

Author's Checklist

• [ ]

How to test this PR locally

Related issues

https://github.com/elastic/sdh-security-team/issues/1477

Screenshots

Screenshots

Screen recording
https://github.com/user-attachments/assets/75a01ab4-c48a-4e5e-8fdb-c85b260eb229

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

Package cloud_security_posture 👍(1) 💚(0) 💔(1)

Expand to view

Data stream	Previous EPS	New EPS	Diff (%)	Result
findings	58823.53	50000	-8823.53 (-15%)	👍
vulnerabilities	125000	83333.33	-41666.67 (-33.33%)	💔

[alexreal1314]

/test benchmark fullreport

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: e8fd142

History

• 💚 Build #33455 succeeded e8fd142

cc @alexreal1314

[maxcold]

From the discussion in Slack:
The main concern is that this breaking change forces users to manually recreate the latest index (and reindex data?). This might be too much to ask from our customers, and they may end up with mapping conflicts. If we are to do that, we need to agree on the strategy and make the trade-offs clear for the product folks.
An alternative is to implement first the approach we have for misconfigurations - have the destination index versioned and add an alias that won't change with breaking changes. Maybe doing that first would make the mapping change smoother

[botelastic]

Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!

[botelastic]

Hi! This PR has been stale for a while and we're going to close it as part of our cleanup procedure. We appreciate your contribution and would like to apologize if we have not been able to review it, due to the current heavy load of the team. Feel free to re-open this PR if you think it should stay open and is worth rebasing. Thank you for your contribution!