We need to introduce a screening component. It will get the data we now have about a CVE, the PURLs of packages this CVE is related to and the Debian Security Tracker entry for the CVE.
With this information the screening component has to decide if a CVE is relevant for GL in general. For example currently CVE for the X window manger are not relevant for GL, but relevant for Debian. Moreover, we should filter out all CVEs not related to a Linux operating system (e.g. Microsoft products, we do not ship).
We can use the Debian Security Tracker "not for us"-data to create a baseline for this decision, which we can then extend to filter specifically for GL. Store this baseline and overwrites also transparently via the audit component inside the repository.
The screening service should store its decisions for a CVE inside the assessment record of the CVE.
We need to introduce a screening component. It will get the data we now have about a CVE, the PURLs of packages this CVE is related to and the Debian Security Tracker entry for the CVE.
With this information the screening component has to decide if a CVE is relevant for GL in general. For example currently CVE for the X window manger are not relevant for GL, but relevant for Debian. Moreover, we should filter out all CVEs not related to a Linux operating system (e.g. Microsoft products, we do not ship).
We can use the Debian Security Tracker "not for us"-data to create a baseline for this decision, which we can then extend to filter specifically for GL. Store this baseline and overwrites also transparently via the audit component inside the repository.
The screening service should store its decisions for a CVE inside the assessment record of the CVE.