On Wed, 27 Sept 2023, 12:05 Reyna, David, <david.re...@windriver.com> wrote:
> Hi Marta! > > > What about 11am Pacific on tomorrow (28 Sept or Oct 3)? > > Let us aim for October 3 so that I can prepare a full demo.. > > > I think that you have meant 10am to 2PM, otherwise 1am Pacific would > work very well for me too > > I actually did mean 2:00 am Pacific. I do work with our India team, so I > am often up late to sync with them.. > > > As discussed yesterday in the call, there are some other people who seem > interested. > > What time zone are you in? > I believe Ross is in England (UTC) > I know that Randy is in Ottawa. > > If anyone else wants to join, that would be great!. They should ping us > and I can send the Zoom link. I do not want to send that link blindly to > the full mail list. > I'm in CEST (Central European zone). If we aim for the 3rd then let's stay for late afternoon for me. I let Ross, Randy and everyone else interested to express their preferences. > > I'm going to add the missing file for the test next week, the tool needs > a script to download 2023 data. > > That file is part of my code update, so you can get that for free. > Thanks! David > > -----Original Message----- > From: Marta Rybczynska <rybczyn...@gmail.com> > Sent: Wednesday, September 27, 2023 12:18 AM > To: Reyna, David <david.re...@windriver.com> > Cc: yocto-secur...@lists.yoctoproject.org; OE-core < > openembedded-core@lists.openembedded.org>; > openembedded-architect...@lists.openembedded.org; > yo...@lists.yoctoproject.org; MacLeod, Randy <randy.macl...@windriver.com>; > Richard Purdie <richard.pur...@linuxfoundation.org>; Steve Sakoman < > st...@sakoman.com>; Khem Raj <raj.k...@gmail.com>; > mark.ha...@kernel.crashing.org; Ross Burton <ross.bur...@arm.com>; Joshua > Watt <jpewhac...@gmail.com> > Subject: Re: [Openembedded-architecture] [yocto] Security processes: YP > needs > > Hi David, > Thank you very much for the description and the offer to get a demo. > As discussed yesterday in the call, there are some other people who > seem interested. > > > PROPOSAL 1: If the full triage is too much to bite off to start with, > perhaps using it to track and coordinate work will bring immediate benefit. > > This is the reason I want to test how much time it takes. > > > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. > I am available pretty much anytime between 10:00 am Pacific to 2:00 am > Pacific. > > That would be nice. What about 11am Pacific on tomorrow (28 Sept or > Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific > would work very well for me too :P > > > PROPOSAL 3: I will start refreshing the YP SRTool repository with my > current implementation level from Wind River (with the Wind River specific > modules left out of course :-) > > That would be great. I'm going to add the missing file for the test > next week, the tool needs a script to download 2023 data. > > Kind regards, > Marta > > On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via > lists.openembedded.org > <david.reyna=windriver....@lists.openembedded.org> wrote: > > > > Hi Marta, > > > > * SRTool: We might decide to use it again. It allows one to do much but > requires constant commitment. > > > > There are many ways to use the SRTool. > > (a) The original design was to perform 100% triage of incoming CVEs. > This was a business requirement of Wind River, and we have used the SRTool > successfully for 4-5 year now. > > (b) The main limitation with the SRTool for Yocto Project was the > lack of integration with Bugzilla (Ross ran out of time) > > * This is the crucial other half of the workflow > > * There is the automatic creation of appropriate defect records for > investigation > > * There is also the automatic tracking of the overall CVE status, > both CVEs in progress and the CVEs completed > > * Wind River has an extension for full integration with Jira, and > that saves weeks of work for the CVE management > > (c) The guiding rule was that CVE management was in the SRTool, but > specific defect work was also done in Jira/Bugzilla, for a clean separate > of domains > > (d) The SRTool has a user model > > * Together with Bugzilla, it is easy to track single people and > even multiple people working on CVEs > > (e) The SRTool also has the built-on ability to look up the CVE status > from other distributions (Red Hat, Debian, ...) so that one can get a peek > of existing triages and resolutions > > (f) The SRTool is build like Toaster on top of Django, so development > and debugging skills for Toaster immediate apply > > (g) Also with the Django base, it is very simple to add any number of > modular extensions to support for example CVE Scanner integration > > (h) The SRTool also has report generation (in text, CSV, and Excel) in > addition to email notification support. > > (i) There is also a "private" model for CVEs under embargo, with > strict access control lists. > > > > PROPOSAL 1: If the full triage is too much to bite off to start with, > perhaps using it to track and coordinate work will bring immediate benefit. > > > > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. > I am available pretty much anytime between 10:00 am Pacific to 2:00 am > Pacific. > > > > PROPOSAL 3: I will start refreshing the YP SRTool repository with my > current implementation level from Wind River (with the Wind River specific > modules left out of course :-) > > > > David > > > > BTW, I also support an extension to the SRTool that manages CVE scanning > of build images, with hooks to a number existing CVE scanners (e.g. Trivy) > in addition to other vulnerability metrics. This is probably out of scope > to YP at this time, but it is perhaps something to grow in to. > > > > -----Original Message----- > > From: yo...@lists.yoctoproject.org <yo...@lists.yoctoproject.org> On > Behalf Of Marta Rybczynska via lists.yoctoproject.org > > Sent: Wednesday, September 13, 2023 4:52 AM > > To: yocto-secur...@lists.yoctoproject.org; OE-core < > openembedded-core@lists.openembedded.org>; > openembedded-architect...@lists.openembedded.org; > yo...@lists.yoctoproject.org > > Cc: Richard Purdie <richard.pur...@linuxfoundation.org>; Steve Sakoman < > st...@sakoman.com>; Khem Raj <raj.k...@gmail.com>; > mark.ha...@kernel.crashing.org; Ross Burton <ross.bur...@arm.com>; Joshua > Watt <jpewhac...@gmail.com> > > Subject: [yocto] Security processes: YP needs > > > > 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. > > > > * 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 (#188336): https://lists.openembedded.org/g/openembedded-core/message/188336 Mute This Topic: https://lists.openembedded.org/mt/101613237/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
