Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finding's score should not depend on sh-filter #123

Open
pedrofenix19 opened this issue Jun 12, 2024 · 0 comments
Open

Finding's score should not depend on sh-filter #123

pedrofenix19 opened this issue Jun 12, 2024 · 0 comments

Comments

@pedrofenix19
Copy link

Hi

Currently, the findings score (calculated by the get_findings_score method of the Findings class) returns different scores depending on whether the used --sh-filters includes one or more findings of the same resource, which I think doesn't make sense. Let me give you an example:

Let's say I have a resource with ID resourceA, which has 5 findings: 2 CRITICAL, 2 HIGH, and 1 INFORMATIONAL.

If Metahub is executed using --sh-filters Id="", the get_findings_score method will return 0 (the math is 0/4) as findings_severity_value["INFORMATIONAL"] is 0.

However, if Metahub is executed using --sh-filters ResourceId="resourceA", the get_findings_score method will return 1 (the math is (4/4)+(4/4)+(3/4)+(3/4)+(0/4) which equals 3.5 and is capped to 1).

This value is then used in the generate_impact_scoring method of the Impact class to calculate the criticality score.

The goal of this example is to show that currently, Metahub's calculated criticality of a finding is heavily dependent on how Metahub is executed, which has nothing to do with the AWS environment in which it is executed or the finding context. This has some unwanted (at least from my point of view) consequences such as:

  • An INFORMATIONAL finding will have the same criticality as a CRITICAL if Metahub is executed filtering by resource ID.
  • If Metahub is executed with a broad filter (or no filter at all) it will generate higher criticality values than if it is executed filtering by finding ID.
    Has this case been evaluated? I would like to know if anything is wrong with my analysis or if there is a way to mitigate this behavior.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant