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 <[email protected]> Sent: Wednesday, September 27, 2023 12:18 AM To: Reyna, David <[email protected]> Cc: [email protected]; OE-core <[email protected]>; [email protected]; [email protected]; MacLeod, Randy <[email protected]>; Richard Purdie <[email protected]>; Steve Sakoman <[email protected]>; Khem Raj <[email protected]>; [email protected]; Ross Burton <[email protected]>; Joshua Watt <[email protected]> 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 <[email protected]> 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: [email protected] <[email protected]> On Behalf > Of Marta Rybczynska via lists.yoctoproject.org > Sent: Wednesday, September 13, 2023 4:52 AM > To: [email protected]; OE-core > <[email protected]>; > [email protected]; [email protected] > Cc: Richard Purdie <[email protected]>; Steve Sakoman > <[email protected]>; Khem Raj <[email protected]>; > [email protected]; Ross Burton <[email protected]>; Joshua > Watt <[email protected]> > 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 (#1778): https://lists.openembedded.org/g/openembedded-architecture/message/1778 Mute This Topic: https://lists.openembedded.org/mt/101570670/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
