Add the ability to pass start/end line values as configuration options in Misconfiguration ignorefile config

[michael-a-shelton]

Description

The proposal is to add the ability to define the start/end lines as optional config fields in the ignore file.
Currently:

  - id: KSV048
    paths:
      - templates/test-template.yaml

Proposed:

  - id: KSV048
    startLine: 9
    endLine: 11
    paths:
      - templates/test-template.yaml

This is a relatively non-invasive small change, adding two fields to the IgnoreFinding struct, passing the values from the calling functions into the Match method, where a conditional then does the line comparsions. The value add here is to allow more granular control over the explicit rules being ignored, instead of ignoring the rule across the entire rendered output, but over specific lines in the output.

I've made the change in a private fork and have it working and would like to propose pushing the change upstream.

Target

None

Scanner

Misconfiguration

[itaysk]

can you use filtering by rego for this? https://aquasecurity.github.io/trivy/v0.54/docs/configuration/filtering/#by-rego
basically the raw result (with line numbers) is passed to your rule, and you can specify the conditions for filtering it

[michael-a-shelton]

We could, however I am looking to use this across dozens of repos with 45+ engineers. A config yaml is far easier to maintain and is a pretty standard approach for other scanners/linters. It is a pretty non-invasive change as the end/start line data is already in the CauseMetadata so it's just passing that down the stack to the Match method.

[simar7]

@michael-a-shelton - that's interesting. Besides what @itaysk mentioned, I think it doesn't hurt to add this in.

Although IMHO, keeping granular details closer to the source is better as it's easier to reference what's being cited. In this case, granular line number info is better kept closer to the source (IaC code itself) than elsewhere.

[michael-a-shelton]

The specific scenario we're working with is looking at misconfigurations of rendered helm charts. Simply stating 'ignore ID 123' on the entire helm chart is problematic, as rendered chart outputs tend to have multiple manifests that may or may not violate the same rule in different places. We may want to ignore it in one spot, but not others, if that makes sense.

This is strictly for cli use cases in pipelines on top of our chart repos to ensure hardened config.

[michael-a-shelton]

I submitted a PR: #7339 - This is on behalf of JPMorgan - We would prefer to do this via CCLA if possible. @brooklynrob

[nikpivkin]

@michael-a-shelton I'm just curious. How are you going to keep the ignore rules up to date with configuration changes?

[michael-a-shelton]

I would expect to maintain the ignorefile similar to any linter config, a unit test, etc. If a configuration change happens, I would expect a full re-evaluation of the configuration and for it to fail should it no longer meet acceptance criteria. It would need to be updated along side the config/change that caused it to fail.

These are entirely optional fields, so it wouldn't impact the existing way the misconf ignorefile operates today, only enhancing it for additional granular control.