We may want to ignore individual findings because:

1. It's a false positive (bug)
2. The dependency is "unused", but it's providing a transitive dependency.
   1. example: a :core:android module which provides an Androidx dependency without actually being used itself.
      1. This sort of finding could also be excluded at the root project level via the alwaysIgnore property in the extension
3. ??

@Suppress("some-finding") // suppress any finding of a given type
dependencies {

  @Suppress("UNUSED") // don't comment out or delete this dependency
  api(project(":unused-lib"))

  @Suppress("mustBeApi") // don't switch this to an api config
  implementation(project(":leaked"))

  @Suppress("inherited") // don't add dependencies which are inherited from this fat jar
  implementation(project(":fat-and-leaky"))
  
}

Annotating a block (plugins { ... }, android { ... }, or dependencies { ... }) should disable any finding of that type for the entire block, or possibly just the entire build file?

@Suppress or @SuppressWarnings works in .kts files. Groovy requires //noinspection [...] for statements.

Discoverability

Console reporting and any build output reporting should include the problemName of the finding, and that problemName should be what's used to suppress the finding.

Any time a MC task fails or has to auto-correct, it should print something like To ignore any of these findings, annotate the dependency with @Suppress("<the name of the finding>").

Edge cases

This doesn't address the case of dependency declarations which can't be found, because they're part of something like a convention plugin.

In some cases, like the unused kapt plugin, it would be fine to just annotate the plugins { ... } block. That rule is so targeted, it won't accidentally ignore any other issue.

In the case of an unused dependency which is provided via a convention plugin, suppressing all "unused" may be too broad a brush. Putting dependencies in a convention plugin hopefully only happens with very low-level "core" dependencies. And since it's a convention plugin, it's probably used frequently in the project. This would be a good use-case for the alwaysIgnore property in the extension.