On Wed, Sep 13, 2023 at 6:00 PM Alex Stewart <alex.stew...@ni.com> wrote: > > Thanks for driving this Marta. Internally and externally, it feels like > we're just on the cusp of everyone *suddenly caring* about our security > response strategy. So it's good to see that we're making moves in that > direction. >
Thank you Alex! > > More responses inline. > > On 9/13/23 07:52, Marta Rybczynska via lists.openembedded.org wrote: > > * CVEs: Visibility if YP is vulnerable or not > > > > People want to be able to check/look up a specific CVE; it might be a > > CVE unrelated to YP > > (eg. package not included, Windows issue). The cve-checker result is a > > part of the solution, but people also want to know which CVEs do not > > apply. > > I'm not sure I understand this usecase. Is there a reason those people > can't/won't just lookup the CVE on the NIST site? > Mark's answer is clarifying that. I'll add that this is a requirement I have heard from multiple sources. People might look up CVE/NIST, but that takes time if you are required to look up all CVEs. If we have common data, we avoid duplicate work. > > * CVEs: synchronization of the work on fixes > > > > Currently, there is no synchronization; multiple parties might be > > working on the same fix while nobody is working on another. There > > might be duplication of work. > > Ross has https://wiki.yoctoproject.org/wiki/CVE_Status > > Has there been any discussion of adopting the OpenVEX document standard > that the Chainguard guys are putting together? [1] It seems like the VEX > use-cases align well with our needs around tracking and coordinating CVE > response between YP member and individual developers. > We might decide to use it. However, openVEX a way to output the data we have/will have (the conclusion), not a way to sync up the work. > > > * Triaging of security issues > > > > Related to CVE fixes and includes issues reported directly to the YP. > > Some issues are more likely to be serious for embedded products > > (attack by network), so not all has the same priority. > > I'll note here that some of us are sinners and do actually support > network-attached (and internet-attached) embedded devices. :) > > But the greater point of OS vendors being able to triage and assign > vendor-specific severities to incoming issues is absolutely important to > my use-cases. > This is an important point. YP is generic and YP assesment of severity might be different than the one from a vendor. It means that our process should be flexible enough that a vendor can take the data and assign their own severity. > > > > * Visibility of the security work of the YP > > > > There is much work on security in the YP, but it lacks visibility. > > Is there a common nexus for this work? eg. do most of the folks who are > doing security work tend to congregate on the security sublist? I'd like to know :) This thread is a big cross-post (and sorry for that, but I need to reach the whole audience), for further discussions I'd like to invite all to a dedicate list. > > > * Additional tooling > > > > We could add additional tooling: a template on how to add cve-check to > > the CI (possibly > > a different one than the autobuilder), analyze the result, and extend > > our tooling to their layers... > > It is also related to the "Architecture" topic below. > > Can you expand on what you mean here? Is this usecase about extending > the existing tooling into the generic CI processes that YP members are > using, or about expanding the tooling in the YP's indigenous CI? This is a requirement assembling multiple ones. Many people mentioned that additional tooling would be needed and/or helpful. A CI template is an example here. I'm interested in your list of tooling that would be important or useful to have. Preferably related to processes that are currently done in-house and that we can make more generic and share the work. > > > * Presence on pre-notification lists and receiving information before > > the vulnerability gets public > > > > YP currently depends on public data. Principal distributions receive > > the information before > > a vulnerability becomes public. It requires (in short) private > > reporting, a security team, and a track > > of excellent security record. > > > > * Becoming a CNA (be able to assign CVEs) > > > > Needed if we want to assign CVEs to the software of the YP, like > > autobuilder, Toaster etc. > > I'm also interested in this, as the maintainer of our opkg fork. So far, > I haven't had to respond to a CVE against the project, but that won't > last forever. CVEs against a fork, this is an interesting use-case... Noted :) Cheers, Marta
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187654): https://lists.openembedded.org/g/openembedded-core/message/187654 Mute This Topic: https://lists.openembedded.org/mt/101340097/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
