Uploaded image for project: 'Project Quay'
  1. Project Quay
  2. PROJQUAY-4023

Clair interprets scan results instead of just delivering them

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • None
    • Clair Report Interpretation
    • False
    • None
    • False
    • Not Selected
    • To Do
    • 0

      Epic Goal

      • Add additional interpretation layers of vulnerability reports generated by Clair in order to reduce false positives

      Why is this important?

      • Today Clair is purely focused on vulnerability reporting depending on the configured matchers, the user is expected to interpret results for a full assessment of the security status of a certain image
      • Customers expect a security assessment to come right out of Clair rather than having to do their own analysis on top of it and thus Clair is not meeting customer expectations today
      • Clair strictly reports matches vulnerabilities against the content that is indexed as a simple aggregation of individual matching results from different vulnerability feed providers but doesn't apply any additional analysis on the full report
      • Lack of report processing leads to reports contain duplicate vulnerability matches and contradicting statements

      Scenarios

      1. A vulnerable package is available from more than one repository and thus creates duplicate vulnerability matches in the report
      2. A vulnerability in Python is fixed by a back-ported RPM and consequently not reported as vulnerable by the RPM scanner, however the Python scanner does not take this into account and reports the Python package delivered via the RPM as vulnerable, creating a false positive

      Acceptance Criteria

      • Clair should de-duplicate reports
      • Clair should allow the user to specify preferences / weights when it comes to disambiguating the vulnerability reports of the same package from different scanners

      Open questions::

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

            Unassigned Unassigned
            DanielMesser Daniel Messer
            Votes:
            4 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: