[cloud_security_posture] Adding vulnerability fields

[jeniawhite]

What does this PR do?

Added additional fields to the vulnerability mappings.
Added an ingest upgrade for older vulnerability findings to include type.
This PR is based on changes:

• Enhance CNVM index cloudbeat#1081
• [CNVM] Index updates cloudbeat#1176

Related Issues

• Fixes: [CNVM] Index vulnerable resource fields cloudbeat#983

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.

Related issues

• Relates [CNVM] Index vulnerable resource fields cloudbeat#983
• Requires Enhance CNVM index cloudbeat#1081

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-08-15T12:31:47.166+0000

• Duration: 15 min 43 sec

Test stats 🧪

Test	Results
Failed	0
Passed	4
Skipped	0
Total	4

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[amirbenun]

ECS compliant fields should go to ecs.yml

[jeniawhite]

@amirbenun
Notice that I did not update the ECS fields due to this:

• Enhance CNVM index cloudbeat#1081 (comment)

[amirbenun]

I think that non-ECS fields should also declare type in their mapping, so I thought it will be easier to use ecs.yml instead of declaring all the types.
@kfirpeled am I correct here?

[amirbenun]

You should just bump the version, no need to add another section

[amirbenun]

we might want to have network and security here as well

[kfirpeled]

requested changes to move security to be under cloud_security_posture

[kfirpeled]

💯

[kfirpeled]

consider capitalization for custom fields to avoid future conflicts
see guideline suggestion: https://www.elastic.co/guide/en/ecs/current/ecs-custom-fields-in-ecs.html

[kfirpeled]

lets avoid top-level custom fields (security is not part of ECS)
the current guideline is to move security to be under a field that is named with the plugin name. In our case that is cloud_security_posture.

So the final field here would be cloud_security_posture.security.security_groups

cc: @eyalkraft , @oren-zohar

[kfirpeled]

consider capitalization for custom fields to avoid future conflicts
see guideline suggestion: https://www.elastic.co/guide/en/ecs/current/ecs-custom-fields-in-ecs.html

[kfirpeled]

@amirbenun Notice that I did not update the ECS fields due to this:

• Enhance CNVM index cloudbeat#1081 (comment)

Currently, using the auto-import is blocked and it is not clear if it will be available for 8.10 release.
@jeniawhite I suggest to update ECS fields as well

I think that non-ECS fields should also declare type in their mapping, so I thought it will be easier to use ecs.yml instead of declaring all the types.
@kfirpeled am I correct here?

I would keep the convention of using ecs.yml to declare only ecs fields. And anything else is for custom fields (aka non-ECS).

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (0/0)	💚
Files	100.0% (0/0)	💚
Classes	100.0% (0/0)	💚
Methods	25.0% (2/8)	👎 -59.0
Lines	100.0% (0/0)	💚 12.766
Conditionals	100.0% (0/0)	💚

[kfirpeled]

lgtm