Re: [OE-core] [Openembedded-architecture] [yocto] Security processes: YP needs
On Wed, 27 Sept 2023, 12:05 Reyna, David, 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 > Sent: Wednesday, September 27, 2023 12:18 AM > To: Reyna, David > Cc: yocto-secur...@lists.yoctoproject.org; OE-core < > openembedded-core@lists.openembedded.org>; > openembedded-architect...@lists.openembedded.org; > yo...@lists.yoctoproject.org; MacLeod, Randy ; > Richard Purdie ; Steve Sakoman < > st...@sakoman.com>; Khem Raj ; > mark.ha...@kernel.crashing.org; Ross Burton ; Joshua > Watt > 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 > 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. > > > >
Re: [OE-core] [Openembedded-architecture] [yocto] Security processes: YP needs
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 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. David -Original Message- From: Marta Rybczynska Sent: Wednesday, September 27, 2023 12:18 AM To: Reyna, David Cc: yocto-secur...@lists.yoctoproject.org; OE-core ; openembedded-architect...@lists.openembedded.org; yo...@lists.yoctoproject.org; MacLeod, Randy ; Richard Purdie ; Steve Sakoman ; Khem Raj ; mark.ha...@kernel.crashing.org; Ross Burton ; Joshua Watt 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 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,
Re: [OE-core] [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 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 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-architect...@lists.openembedded.org; yo...@lists.yoctoproject.org > Cc: Richard Purdie ; Steve Sakoman > ; Khem Raj ; > mark.ha...@kernel.crashing.org; Ross Burton ; Joshua > Watt > 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
