Hi, On Wed, Sep 13, 2023 at 01:52:19PM +0200, Marta Rybczynska wrote: > Hello, > I've been working recently on collecting what works and what doesn't > in YP security processes. The goal is to go forward and define an > actionable strategy! > > Today, I'd like to share with you the summary of what I have heard as > needs from several people (those in Cc:). > > I want the community to comment and tell us what you find important > and what you'd like to see added or changed from this list.
Since most users take poky reference distro and combine it with a number of open source and closed source BSP and other meta layers and build systems to produce SW for products, they also need documentation and tooling so that they can replicate the Yocto Project security processes and use the available tools. In the best case downstream users are on poky master branch or one of the maintained LTS branches, but they can also be stuck on a non-LTS branch due to BSP or other technical, contractual or even purely political reasons. Having a description of the processes and tools and best practices helps, and if needed they can for example backport the needed tooling changes to their version to help or kick off in the maintenance effort, just like how upstream LTS branches are managed. I think most of the documentation around the tools and processes is in place already. Having maintained and shipped from a non-maintained poky branch, I can just say thank you to all who participated in the upstream work to get security vulnerability detection and fixing possible! poky seems well maintained and serves as an example to everyone wether open source or not. That being said, extending the CVE scanning and status tracking work to include more open source layers would be nice both for the maintainers and for the users of those layers. Using some random old branch of meta-foo may not be so safe. Maybe add this data to layer-index? Cheers, -Mikko > * 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. > > * 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 > > * 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. > > * Private security communication > > A way to send a notification of a non-public security issue. For > researchers, other projects etc. > The security alias exists, but only some people know about its existence. > > * Visibility of the security work of the YP > > There is much work on security in the YP, but it lacks visibility. > > * Documentation > > Related to visibility. We need easy-to-find documentation of subjects > like submitting a CVE fix, > reporting a private issue, and how our processes work... This > documentation should address people who are not regular contributors. > > * 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. > > * Architecture work > > Security if more than CVE fixes. We also have what is happening in > meta-security: hardening, compiler option, > secure package configuration, use of code coverage tools, and so on > > * SRTool > > We might decide to use it again. It allows one to do much but requires > constant commitment. > > * 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. > > Kind regards, > Marta > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187588): https://lists.openembedded.org/g/openembedded-core/message/187588 Mute This Topic: https://lists.openembedded.org/mt/101335537/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
