chore: generate AWS compliance specs based on checks

[nikpivkin]

The generation of compliance specifications will avoid errors when updating check metadata, as changes can only be made in checks.

Related PRs:

• fix: add missing platform and type to spec trivy#7149

[simar7]

I think this is good! I have a couple of comments:

1. We should verify the generated spec each time and if any changes are observed, fail the CI. You already have the verification part of this in the makefile, just need to add it as part of the CI workflow. This will be similar to running make docs.
2. The first time we generate a compliance spec, we'll need to verify it manually as there might be checks which don't have the spec control metadata field in them which associates them with a particular compliance spec.

[nikpivkin]

1. We should verify the generated spec each time and if any changes are observed, fail the CI. You already have the verification part of this in the makefile, just need to add it as part of the CI workflow. This will be similar to running make docs.

Already added: https://github.com/aquasecurity/trivy-checks/pull/179/files#diff-d5c4c7c89806a5612ec9c3f57d1e659caf1bea380d7eea560a322a2028447fbcR1-R21

2. The first time we generate a compliance spec, we'll need to verify it manually as there might be checks which don't have the spec control metadata field in them which associates them with a particular compliance spec.

Agreed, the diff will make it easy to notice if any control goes missing.

[nikpivkin]

@simar7 Generating the remaining specifications will require a little more effort:

• The remaining checks do not reference specifications, so their metadata needs to be updated.
• For Kubernetes checks, commands need to be added to their metadata.

Should this be done in another PR?

[simar7]

@simar7 Generating the remaining specifications will require a little more effort:

• The remaining checks do not reference specifications, so their metadata needs to be updated.
• For Kubernetes checks, commands need to be added to their metadata.

Should this be done in another PR?

Yeah I think we can do it in a separate PR.

[simar7]

Let's merge this once the ID PRs have stabilized.