[prev in list] [next in list] [prev in thread] [next in thread]
List: openembedded-architecture
Subject: Re: [Openembedded-architecture] [yocto] Security processes: YP needs
From: "Marta Rybczynska" <rybczynska () gmail ! com>
Date: 2023-09-27 17:24:56
Message-ID: CAApg2=Tz5QDw7RPhh1Kux=w0REFp2R3K0b+QL6oPazrOpVdCnA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, 27 Sept 2023, 12:05 Reyna, David, <david.reyna@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 <rybczynska@gmail.com>
> Sent: Wednesday, September 27, 2023 12:18 AM
> To: Reyna, David <david.reyna@windriver.com>
> Cc: yocto-security@lists.yoctoproject.org; OE-core <
> openembedded-core@lists.openembedded.org>;
> openembedded-architecture@lists.openembedded.org;
> yocto@lists.yoctoproject.org; MacLeod, Randy <Randy.MacLeod@windriver.com>;
> Richard Purdie <richard.purdie@linuxfoundation.org>; Steve Sakoman <
> steve@sakoman.com>; Khem Raj <raj.khem@gmail.com>;
> mark.hatle@kernel.crashing.org; Ross Burton <ross.burton@arm.com>; Joshua
> Watt <JPEWhacker@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.com@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: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On
> Behalf Of Marta Rybczynska via lists.yoctoproject.org
> > Sent: Wednesday, September 13, 2023 4:52 AM
> > To: yocto-security@lists.yoctoproject.org; OE-core <
> openembedded-core@lists.openembedded.org>;
> openembedded-architecture@lists.openembedded.org;
> yocto@lists.yoctoproject.org
> > Cc: Richard Purdie <richard.purdie@linuxfoundation.org>; Steve Sakoman <
> steve@sakoman.com>; Khem Raj <raj.khem@gmail.com>;
> mark.hatle@kernel.crashing.org; Ross Burton <ross.burton@arm.com>; Joshua
> Watt <JPEWhacker@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
> >
> >
> >
>
[Attachment #5 (text/html)]
<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Wed, 27 Sept 2023, 12:05 Reyna, David, <<a \
href="mailto:david.reyna@windriver.com">david.reyna@windriver.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marta!<br> <br>
> What about 11am Pacific on tomorrow (28 Sept or Oct 3)? <br>
<br>
Let us aim for October 3 so that I can prepare a full demo..<br>
<br>
> I think that you have meant 10am to 2PM, otherwise 1am Pacific would work very \
well for me too <br> <br>
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..<br> <br>
> As discussed yesterday in the call, there are some other people who seem \
interested.<br> <br>
What time zone are you in? <br>
I believe Ross is in England (UTC)<br>
I know that Randy is in Ottawa.<br>
<br>
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.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I'm \
in CEST (Central European zone). If we aim for the 3rd then let's stay for late \
afternoon for me.</div><div dir="auto"><br></div><div dir="auto">I let Ross, Randy \
and everyone else interested to express their preferences.</div><div \
dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
> I'm going to add the missing file for the test next week, the tool needs a \
script to download 2023 data.<br> <br>
That file is part of my code update, so you can get that for \
free.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Thanks! \
</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> David<br>
<br>
-----Original Message-----<br>
From: Marta Rybczynska <<a href="mailto:rybczynska@gmail.com" target="_blank" \
rel="noreferrer">rybczynska@gmail.com</a>> <br>
Sent: Wednesday, September 27, 2023 12:18 AM<br>
To: Reyna, David <<a href="mailto:david.reyna@windriver.com" target="_blank" \
rel="noreferrer">david.reyna@windriver.com</a>><br>
Cc: <a href="mailto:yocto-security@lists.yoctoproject.org" target="_blank" \
rel="noreferrer">yocto-security@lists.yoctoproject.org</a>; OE-core <<a \
href="mailto:openembedded-core@lists.openembedded.org" target="_blank" \
rel="noreferrer">openembedded-core@lists.openembedded.org</a>>; <a \
href="mailto:openembedded-architecture@lists.openembedded.org" target="_blank" \
rel="noreferrer">openembedded-architecture@lists.openembedded.org</a>; <a \
href="mailto:yocto@lists.yoctoproject.org" target="_blank" \
rel="noreferrer">yocto@lists.yoctoproject.org</a>; MacLeod, Randy <<a \
href="mailto:Randy.MacLeod@windriver.com" target="_blank" \
rel="noreferrer">Randy.MacLeod@windriver.com</a>>; Richard Purdie <<a \
href="mailto:richard.purdie@linuxfoundation.org" target="_blank" \
rel="noreferrer">richard.purdie@linuxfoundation.org</a>>; Steve Sakoman <<a \
href="mailto:steve@sakoman.com" target="_blank" \
rel="noreferrer">steve@sakoman.com</a>>; Khem Raj <<a \
href="mailto:raj.khem@gmail.com" target="_blank" \
rel="noreferrer">raj.khem@gmail.com</a>>; <a \
href="mailto:mark.hatle@kernel.crashing.org" target="_blank" \
rel="noreferrer">mark.hatle@kernel.crashing.org</a>; Ross Burton <<a \
href="mailto:ross.burton@arm.com" target="_blank" \
rel="noreferrer">ross.burton@arm.com</a>>; Joshua Watt <<a \
href="mailto:JPEWhacker@gmail.com" target="_blank" \
rel="noreferrer">JPEWhacker@gmail.com</a>><br>
Subject: Re: [Openembedded-architecture] [yocto] Security processes: YP needs<br>
<br>
Hi David,<br>
Thank you very much for the description and the offer to get a demo.<br>
As discussed yesterday in the call, there are some other people who<br>
seem interested.<br>
<br>
> 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.<br> <br>
This is the reason I want to test how much time it takes.<br>
<br>
> 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.<br> <br>
That would be nice. What about 11am Pacific on tomorrow (28 Sept or<br>
Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific<br>
would work very well for me too :P<br>
<br>
> 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 :-)<br> <br>
That would be great. I'm going to add the missing file for the test<br>
next week, the tool needs a script to download 2023 data.<br>
<br>
Kind regards,<br>
Marta<br>
<br>
On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via<br>
<a href="http://lists.openembedded.org" rel="noreferrer noreferrer" \
target="_blank">lists.openembedded.org</a><br> <david.reyna=<a \
href="mailto:windriver.com@lists.openembedded.org" target="_blank" \
rel="noreferrer">windriver.com@lists.openembedded.org</a>> wrote:<br> ><br>
> Hi Marta,<br>
><br>
> * SRTool: We might decide to use it again. It allows one to do much but requires \
constant commitment.<br> ><br>
> There are many ways to use the SRTool.<br>
> (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.<br> > (b) The main limitation with the SRTool for Yocto \
Project was the lack of integration with Bugzilla (Ross ran out of time)<br> > \
* This is the crucial other half of the workflow<br> > * There is the \
automatic creation of appropriate defect records for investigation<br> > * \
There is also the automatic tracking of the overall CVE status, both CVEs in progress \
and the CVEs completed<br> > * Wind River has an extension for full \
integration with Jira, and that saves weeks of work for the CVE management<br> > \
(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<br> > (d) \
The SRTool has a user model<br> > * Together with Bugzilla, it is easy to \
track single people and even multiple people working on CVEs<br> > (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<br> > (f) The SRTool is build like Toaster on top of Django, \
so development and debugging skills for Toaster immediate apply<br> > (g) Also \
with the Django base, it is very simple to add any number of modular extensions to \
support for example CVE Scanner integration<br> > (h) The SRTool also has \
report generation (in text, CSV, and Excel) in addition to email notification \
support.<br> > (i) There is also a "private" model for CVEs under \
embargo, with strict access control lists.<br> ><br>
> 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.<br> ><br>
> 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.<br> \
><br> > 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 :-)<br> ><br>
> David<br>
><br>
> 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.<br> ><br>
> -----Original Message-----<br>
> From: <a href="mailto:yocto@lists.yoctoproject.org" target="_blank" \
rel="noreferrer">yocto@lists.yoctoproject.org</a> <<a \
href="mailto:yocto@lists.yoctoproject.org" target="_blank" \
rel="noreferrer">yocto@lists.yoctoproject.org</a>> On Behalf Of Marta Rybczynska \
via <a href="http://lists.yoctoproject.org" rel="noreferrer noreferrer" \
target="_blank">lists.yoctoproject.org</a><br> > Sent: Wednesday, September 13, \
2023 4:52 AM<br> > To: <a href="mailto:yocto-security@lists.yoctoproject.org" \
target="_blank" rel="noreferrer">yocto-security@lists.yoctoproject.org</a>; OE-core \
<<a href="mailto:openembedded-core@lists.openembedded.org" target="_blank" \
rel="noreferrer">openembedded-core@lists.openembedded.org</a>>; <a \
href="mailto:openembedded-architecture@lists.openembedded.org" target="_blank" \
rel="noreferrer">openembedded-architecture@lists.openembedded.org</a>; <a \
href="mailto:yocto@lists.yoctoproject.org" target="_blank" \
rel="noreferrer">yocto@lists.yoctoproject.org</a><br> > Cc: Richard Purdie <<a \
href="mailto:richard.purdie@linuxfoundation.org" target="_blank" \
rel="noreferrer">richard.purdie@linuxfoundation.org</a>>; Steve Sakoman <<a \
href="mailto:steve@sakoman.com" target="_blank" \
rel="noreferrer">steve@sakoman.com</a>>; Khem Raj <<a \
href="mailto:raj.khem@gmail.com" target="_blank" \
rel="noreferrer">raj.khem@gmail.com</a>>; <a \
href="mailto:mark.hatle@kernel.crashing.org" target="_blank" \
rel="noreferrer">mark.hatle@kernel.crashing.org</a>; Ross Burton <<a \
href="mailto:ross.burton@arm.com" target="_blank" \
rel="noreferrer">ross.burton@arm.com</a>>; Joshua Watt <<a \
href="mailto:JPEWhacker@gmail.com" target="_blank" \
rel="noreferrer">JPEWhacker@gmail.com</a>><br> > Subject: [yocto] Security \
processes: YP needs<br> ><br>
> Hello,<br>
> I've been working recently on collecting what works and what doesn't<br>
> in YP security processes. The goal is to go forward and define an<br>
> actionable strategy!<br>
><br>
> Today, I'd like to share with you the summary of what I have heard as<br>
> needs from several people (those in Cc:).<br>
><br>
> I want the community to comment and tell us what you find important<br>
> and what you'd like to see added or changed from this list.<br>
><br>
> * CVEs: Visibility if YP is vulnerable or not<br>
><br>
> People want to be able to check/look up a specific CVE; it might be a<br>
> CVE unrelated to YP<br>
> (eg. package not included, Windows issue). The cve-checker result is a<br>
> part of the solution, but people also want to know which CVEs do not<br>
> apply.<br>
><br>
> * CVEs: synchronization of the work on fixes<br>
><br>
> Currently, there is no synchronization; multiple parties might be<br>
> working on the same fix while nobody is working on another. There<br>
> might be duplication of work.<br>
> Ross has <a href="https://wiki.yoctoproject.org/wiki/CVE_Status" rel="noreferrer \
noreferrer" target="_blank">https://wiki.yoctoproject.org/wiki/CVE_Status</a><br> \
><br> > * Triaging of security issues<br>
><br>
> Related to CVE fixes and includes issues reported directly to the YP.<br>
> Some issues are more likely to be serious for embedded products<br>
> (attack by network), so not all has the same priority.<br>
><br>
> * Private security communication<br>
><br>
> A way to send a notification of a non-public security issue. For<br>
> researchers, other projects etc.<br>
> The security alias exists, but only some people know about its existence.<br>
><br>
> * Visibility of the security work of the YP<br>
><br>
> There is much work on security in the YP, but it lacks visibility.<br>
><br>
> * Documentation<br>
><br>
> Related to visibility. We need easy-to-find documentation of subjects<br>
> like submitting a CVE fix,<br>
> reporting a private issue, and how our processes work... This<br>
> documentation should address people who are not regular contributors.<br>
><br>
> * Additional tooling<br>
><br>
> We could add additional tooling: a template on how to add cve-check to<br>
> the CI (possibly<br>
> a different one than the autobuilder), analyze the result, and extend<br>
> our tooling to their layers...<br>
> It is also related to the "Architecture" topic below.<br>
><br>
> * Architecture work<br>
><br>
> Security if more than CVE fixes. We also have what is happening in<br>
> meta-security: hardening, compiler option,<br>
> secure package configuration, use of code coverage tools, and so on<br>
><br>
> * SRTool<br>
><br>
> We might decide to use it again. It allows one to do much but requires<br>
> constant commitment.<br>
><br>
> * Presence on pre-notification lists and receiving information before<br>
> the vulnerability gets public<br>
><br>
> YP currently depends on public data. Principal distributions receive<br>
> the information before<br>
> a vulnerability becomes public. It requires (in short) private<br>
> reporting, a security team, and a track<br>
> of excellent security record.<br>
><br>
> * Becoming a CNA (be able to assign CVEs)<br>
><br>
> Needed if we want to assign CVEs to the software of the YP, like<br>
> autobuilder, Toaster etc.<br>
><br>
> Kind regards,<br>
> Marta<br>
><br>
> <br>
><br>
</blockquote></div></div></div>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1779): \
https://lists.openembedded.org/g/openembedded-architecture/message/1779 Mute This \
Topic: https://lists.openembedded.org/mt/101570670/4454510 Group Owner: \
openembedded-architecture+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub \
[openembedded-architecture@marc.info]
-=-=-=-=-=-=-=-=-=-=-=-
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic