feat: add a examples field to check metadata

[nikpivkin]

Description

Previously, examples for checks were stored in separate files for each provider. For example, the examples for Terraform <name> checks were in the <name>.tf.go file, and the examples for CloudFormation were in <name>.cf.go. With the discontinuation of support for Go checks, there is no longer a need to store examples in Go files as it makes them harder to retrieve. Therefore, the examples for each check have been moved from Go to YAML with a new schema:

cloudformation:
  good:
    - |-
       ...
  bad:
    - |-
       ...
terraform:
  good:
    - |-
       ...
  bad:
    - |-
       ...

Currently, the check metadata includes fields for each provider with the same structure:

#   terraform:
#     good_examples: checks/cloud/aws/s3/enable_bucket_logging.yaml
#     links:
#       - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket
#   cloud_formation:
#     good_examples: checks/cloud/aws/s3/enable_bucket_logging.yaml

I have an idea to convert test data for Dockerfile and Kubernetes into examples for integration testing and display on a website. (draft PR). However, the current approach when adding a new provider requires the following steps:

1. Add support for the new provider to the metadata in the Trivy repository.
2. Add a new provider to the metadata of each check.

This process is awkward and inflexible. To simplify it, I propose to introduce a new examples field, which will contain the path to the file with examples to check, replacing the current fields with providers:

#   examples: checks/cloud/aws/s3/enable_bucket_logging.yaml

Along with this, the structure of the example file can be updated to make it more flexible:

providers:
  cloudformation:
    examples:
      good:
        - code: |-
            ...
      bad:
        - code: |-
            ...
  terraform:
    links:
      - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket
    examples:
      good:
        - code: |-
            ...

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[nikpivkin]

@aquasecurity/trivy WDYT?

[simar7]

I think this is a nice idea, it'll simplify the metadata annotation and the example file as well.

But we have to consider the changes the consumer of the examples and metadata will need. I know AVD is one of them but there might be others.

[nikpivkin]

AVD only uses markdown documentation that is generated within trivy-checks. As far as I know, there are no more consumers, so the examples are only used inside trivy-checks.

[simar7]

AVD only uses markdown documentation that is generated within trivy-checks. As far as I know, there are no more consumers, so the examples are only used inside trivy-checks.

@tamirkiviti13 as a consumer of trivy checks, do you use the checks metadata in anyway?

[DmitriyLewen]

I don't see any problems that could affect Trivy users (except for a small increase in the size of the folder with checks, but the size will increase so insignificantly that it can be neglected)

[simar7]

OK we can merge it in for now since we haven't heard any other objections.