Hello Richard, Could you please take a look on the latest revision a make a decision there? There are still bunch of unclear statements. So please make a final design and we will try to implement it.
Thank you, Andrej On Mon, 2023-05-22 at 10:57 +0300, Mikko Rapeli wrote: > Hi, > > On Fri, May 19, 2023 at 03:11:57PM +0200, Marta Rybczynska wrote: > > I'm missing a status to cover the situation when the NVD (or any other > > database) has an incorrect entry. We have quite many of those. This might > > be a temporary situation, but not always. > > > > SPDX (the 3.0 draft) has some other possible reasons > > https://github.com/spdx/spdx-spec/blob/vulnerability-profile/chapters/profile-vulnerabilities.md > > What looks like interesting ideas are: > > * "Can't fix" / "Will not fix" > > * "Not applicable" (SPDX language: Ineffective) when the code is not used > > * "Invalid match" (this is our NVD mismatch case) > > * "Mitigated" measures taken so that it cannot be exploited > > * "Workarounded" > > To me the SPDX details don't seem very usable when actually maintaining > a linux distro for a long time. Anyone from major Linux distro > stable/security teams participating in the work? > > So I'd rather compare to Debian security tracker CVE status data and ask > what our LTS and master branch maintainers and those in the community > who maintain yocto based SW stacks need. Do the maintainers want to read > SPDX output, for example? What common statuses do the maintainers want to > encode for each CVE? > > Debian security tracker https://security-team.debian.org/security_tracker.html > shows states: > > * vulnerable: binary package with specified version in their distro > version is vulnerable to the issue > > * fixed: binary package in their distro version has fixed the issue > > * undetermined: it is not yet clear if the issue affects Debian and > their version of the packages > > And "vulnerable" has sub states: > > * ignored: the issue does not impact Debian packages > > * postponed: no security patch updates will be provided, e.g. such a > minor issue that update will happen for example via normal package > version updates to next stable version > > There are a lot of additional "standards" and sub states when looking at > CVE data in the tracker (info not public, no upstream fix available, not > supported configuration etc), but those major high level states are enough. > And then there are security relevant bugs without CVEs. > > I've been happy with "Unpatched", "Patched" and "Ignored" states for > each CVE detected by cve-check.bbclass. There could be a few more sub > stated to "Ignored" and the "Patched" state should better reflect reality, > which this patch set helps. But I'm happy with that. > > I'm not so happy with the SPDX states names and meanings. > > Cheers, > > -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181629): https://lists.openembedded.org/g/openembedded-core/message/181629 Mute This Topic: https://lists.openembedded.org/mt/99007092/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
