fix: adds ignore rules for kernel-headers indirect matches

[zhill]

Adds ignoring of kernel-headers indirect matches on kernel vulns since the kernel-headers package does not have the kernel code in it that kernel vulns are actually referring to.

Adds a config value to control this ignore behavior that defaults to enabling the ignore rules.

Fixes: #1762

• Adds ignore rule support for match types and upstream package names.
• Adds default ignore rules for kernel-headers indirect matches on kernel for rpms.

[zhill]

Opening as a draft for initial feedback. I'll address any concerns in UX, testing, etc and then move it to ready for review

[spiffcs]

Thanks for the PR @zhill - I took a look and like this approach of using the built in ignore rules as the hook for this option.

I'll take a look this afternoon at what unit tests should look like for this feature.

I also noted that the quality gate is now failing with this PR so will examine to see how I can help fix that for you as well.

[kzantow]

Overall this looks pretty good to me

[zhill]

Thanks for the PR @zhill - I took a look and like this approach of using the built in ignore rules as the hook for this option.

I'll take a look this afternoon at what unit tests should look like for this feature.

I also noted that the quality gate is now failing with this PR so will examine to see how I can help fix that for you as well.

Ack, yes I knew the quality gate would need work once i get 👍 on the approach. Happy to resolve that once we're good on the things like option naming and rule details.

[zhill]

I've added tests and I have a pr for the quality tests: anchore/vulnerability-match-labels#132

What's the process for getting the quality to pass? Do I wait for that to merge and then update the submodule to that commit in main?

[willmurphyscode]

@zhill I've approved anchore/vulnerability-match-labels#132.

What's the process for getting the quality to pass? Do I wait for that to merge and then update the submodule to that commit in main?

I'd recommend updating the submodule in this branch. It's also fine to update the submodule in main in a separate PR, and merge/rebase that change into this PR, but in the case where the set of expected matches changes, like in this case, it's possible that a PR to main that changes labels will fail, because it's missing the logic in this PR. Does that make sense?

[kzantow]

LGTM 👍