feat(misconf): add fingerprint support for findings #9668
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR introduces a stable fingerprint mechanism for findings (misconfigurations) to ensure reliable suppression across scans.
Fingerprint
Each fingerprint consists of:
Hash– computed SHA256 hash of theFindingID.FindingID– a stable identifier constructed from the file path, rule ID, and logical cause path.Example:
FindingID
The
FindingIDis constructed as:filePath– path to the file (CloudFormation, Terraform, Dockerfile, etc.)CheckID– check identifierCausePath– logical path from the top-level resource/block down to the attribute or sub-block that triggered the findingThis ensures each finding is uniquely identified within a file and rule.
Stability and Behavior
Stable across structural changes:
Moving, adding, or removing child blocks or attributes does not change the fingerprint. This ensures that suppression remains valid even if the structure is modified or new blocks/attributes are added.
Disambiguation of repeated blocks:
For blocks of the same type (e.g., multiple egress blocks in Terraform), each block is assigned a stable index based on its order of appearance and the total count of blocks of that type.
This allows distinguishing between repeated blocks while keeping fingerprints consistent when unrelated parts of the configuration change.
Example:
In this case, there are two egress blocks. Each one gets a unique FindingID derived from:
If one of the blocks is removed or a new one is added, the total count changes, which means the FindingID for the remaining blocks will also change.
Limitation:
If blocks of the same type are swapped, the fingerprint remains the same. This may be a limitation in rare cases where positional uniqueness is important.
Related issues
Related PRs:
TODO:
Checklist