feat: Consider including defsec scanner schema in bundle

[simar7]

Description

Today defsec scanners have a schema which they need in order to register services. This currently lives here https://github.com/aquasecurity/defsec/blob/d9947704afbd97ed19ab9f34903b33c545621e85/pkg/rego/scanner.go#L122-L131

When new services are added into defsec (via adapters), that requires change to the appropriate schema. For example PR: aquasecurity/defsec#1153 added a new AWS service adapter that required the need for updating the corresponding cloud.json schema for AWS.

When the schema is updated (brand new services added) and a new bundle based on that is released, it makes the bundle backwards incompatible, if they use the same MAJOR version. This is the case today as older versions of Trivy will not be aware of the newer services which were added as part of the new bundle.

This causes issues like this: #4124

Solution

Short term

When new services are added to defsec, we can update the MAJOR policy version as there is now a significant change (new services being added). This will keep things backwards compatible as older versions of Trivy will not break because of a new policy/service getting added into defsec. The version of defsec policy bundle is pinned here: https://github.com/aquasecurity/trivy/blob/main/pkg/policy/policy.go#L21-L22

This however should only be done less frequently as otherwise (as @knqyf263 pointed out), it will require many Trivy users to frequently update their Trivy version to get the latest updates.

Long term

Schema should be treated the same as a policy and should be part of the policy bundle. This will allow Trivy to read the schema of every service from the bundle (if available). We will need to account for cases when bundle is not available (offline mode). For such cases we can consider the same approach we have today for policies, that is to use embedded policies if newer ones are not available, either on intentionally or otherwise.

cc @knqyf263 @itaysk

[itaysk]

Conceptually there are these two phases:

1. Trivy reads target configuration from API or file, and Adapter adapts it to defsec common schema.
2. Rego rules are evaluated with that common schema as input.

step1 is shipped with Trivy, step2 is shipped with defsec. Different lifecycles.
The input.schema sits in between these two steps, as it describes the output of step1 for step2.
Your suggestion is to couple the schema with step2, and I just want to verify it doesn't have a dependency with step1.