You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment in the enrichment process we use weak links to look up the CVEs associated to vulnerability that involve searching the name and description for “CVE-*” like strings. This data is typically explicitly referenced in OVAL DB (and is usually strongly linked in the other data sources Clair uses), so Clair should be able to represent this relationship in a more concrete way. This reference data doesn’t only contain CVE type references but also vendor specific advisories (RHSAs in the case of Red Hat) and in the future we could be seeing Github security advisories. All this information would be useful.
Another issue that we need to solve is the ability to ignore certain CVEs/RHSAs/etc, either in an interpretation layer native to Clair itself or an external parser used by a client. Currently this is possible but it could lead to false negatives and positives depending on how vendors compose their advisory descriptions/titles.
Proposal
As Clair ingests vulnerabilities we should create a relationship between the vulnerability and its references. References should be created if they don’t already exist. For this we should create a new table for storing references, references and vulns share a many to many relationship:
reference
id: BIGSERIAL PRIMARY KEY
ref_id: TEXT
kind: TEXT
Clair also needs to create a relationship table and insert as we ingest: vuln_ref
ref_id: bigint REFERENCES reference (id) ON DELETE CASCADE
vuln_id bigint REFERENCES vuln (id) ON DELETE CASCADE
The enrichment table can then be seen as adornment data for entries in the reference table of kind CVE.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Problem
At the moment in the enrichment process we use weak links to look up the CVEs associated to vulnerability that involve searching the name and description for “CVE-*” like strings. This data is typically explicitly referenced in OVAL DB (and is usually strongly linked in the other data sources Clair uses), so Clair should be able to represent this relationship in a more concrete way. This reference data doesn’t only contain CVE type references but also vendor specific advisories (RHSAs in the case of Red Hat) and in the future we could be seeing Github security advisories. All this information would be useful.
Another issue that we need to solve is the ability to ignore certain CVEs/RHSAs/etc, either in an interpretation layer native to Clair itself or an external parser used by a client. Currently this is possible but it could lead to false negatives and positives depending on how vendors compose their advisory descriptions/titles.
Proposal
As Clair ingests vulnerabilities we should create a relationship between the vulnerability and its references. References should be created if they don’t already exist. For this we should create a new table for storing references, references and vulns share a many to many relationship:
reference
id: BIGSERIAL PRIMARY KEY
ref_id: TEXT
kind: TEXT
Clair also needs to create a relationship table and insert as we ingest:
vuln_ref
ref_id: bigint REFERENCES reference (id) ON DELETE CASCADE
vuln_id bigint REFERENCES vuln (id) ON DELETE CASCADE
The enrichment table can then be seen as adornment data for entries in the reference table of kind CVE.
Considerations
Beta Was this translation helpful? Give feedback.
All reactions