feat(misconf): Add minimum supported version

[simar7]

Description

Today trivy supports the ability to load any check, regardless of whether or not it has the ability to actually run it. This is the case for those checks where the support for a new service or provider is added.

This leads to situations where an older version of Trivy can download a new check for which it may not have the support for. In such a case today we don't evaluate the check and end up skipping it.

Solution

A more optimized approach in such a case would be to add a metadata annotation to the check itself, which could specify the "minimum trivy version" needed to run that particular check. This would then be used by the Trivy CLI to determine if it makes sense for it to load that particular check or not.

Example

An example of this could look like the following (details omitted for brevity):

# METADATA
# title: "Runtime/Default Seccomp profile not set"
# description: "Some description text"
# scope: package
# minimum_trivy_version: v0.60
# schemas:
# - input: schema["kubernetes"]
# related_resources:
# - https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted

In this case a trivy version semantically higher than v0.60 would be able to load this check. As we only introduce new features in a minor release (not a patch), we can omit checking/specifying for the patch release version.

[nikpivkin]

We discussed this here aquasecurity/trivy-checks#352 . By the way, custom fields should be in the custom field. For example:

# custom:
#   minimum_trivy_version: v0.60

[simar7]

We discussed this here aquasecurity/trivy-checks#352 . By the way, custom fields should be in the custom field. For example:

# custom:
#   minimum_trivy_version: v0.60

Actually I think this field should be required going forwards. That's the only way to ensure that it's specified in new checks or else we will get into situations where it's not specified.

[itaysk]

can you clarify how different scenatios will be handled by this proposal? check foo depends on trivy 0.60. is it compatible with 0.61? probably yes but maybe no. we discussed it long time ago and agreed that checks should depend on schema version (not necessarily same as trivy version). meaning, we bump schema version only if there was an actual change. one thing we discussed then which remained unanswered was granularity of the schema, is it one for all defsec or per provider? (if we changed an AWS service does it bump schema for Azure).

[simar7]

can you clarify how different scenatios will be handled by this proposal? check foo depends on trivy 0.60. is it compatible with 0.61? probably yes but maybe no.

Forward compatibility is always ensured, as if and when a cloud provider decides to sunset a service, we will also deprecate the checks related to it.

Backwards compatibility is what this feature request will help with. If a check wants a minimum trivy version of v0.60, it will not be run on Trivy versions lower than v0.60.

we discussed it long time ago and agreed that checks should depend on schema version (not necessarily same as trivy version). meaning, we bump schema version only if there was an actual change.

I re-thought about this prior to making this issue and I concluded that pinning checks to a schema version while makes sense, it's a bit easier for users to tie it with the trivy version instead as it's more widely known and used. The schema is bundled with Trivy anyway so it is the same release cycle.

one thing we discussed then which remained unanswered was granularity of the schema, is it one for all defsec or per provider? (if we changed an AWS service does it bump schema for Azure).

Today there is a "cloud.json" schema for all clouds. If we tie minimum supported version with the release of Trivy like I propose, this will be a non issue. We could look into splitting cloud.json into various cloud providers but that's unrelated to this issue.

[itaysk]

make sense, thank for clarifying