Security processes: YP needs

Security processes: YP needs

[Marta Rybczynska]

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

Re: [Openembedded-architecture] Security processes: YP needs

[Mikko Rapeli]

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 (#1747): https://lists.openembedded.org/g/openembedded-architecture/message/1747
> Mute This Topic: https://lists.openembedded.org/mt/101334933/7159507
> Group Owner: openembedded-architecture+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [mikko.rapeli@linaro.org]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [Openembedded-architecture] Security processes: YP needs

[Alex Stewart]

Thanks for driving this Marta. Internally and externally, it feels like 
we're just on the cusp of everyone *suddenly caring* about our security 
response strategy. So it's good to see that we're making moves in that 
direction.

In general, this list looks complete to me. I'm primarily interested in 
the response coordination, triage, and tracking usecases. Those are the 
biggest pain points for my team, at the moment. And that is primarily 
driven by a lack of tooling.

More responses inline.

On 9/13/23 07:52, Marta Rybczynska via lists.openembedded.org wrote:
> [You don't often get email from rybczynska=gmail.com@lists.openembedded.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> 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.

I'm not sure I understand this usecase. Is there a reason those people 
can't/won't just lookup the CVE on the NIST site?

> * 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

Has there been any discussion of adopting the OpenVEX document standard 
that the Chainguard guys are putting together? [1] It seems like the VEX 
use-cases align well with our needs around tracking and coordinating CVE 
response between YP member and individual developers.

I've been considering it for my internal use for a while. And also 
considering replacing the existing cve_check output JSON with OpenVEX, 
once it has stabilized.

[1] https://github.com/openvex/spec

> * 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.

I'll note here that some of us are sinners and do actually support 
network-attached (and internet-attached) embedded devices. :)

But the greater point of OS vendors being able to triage and assign 
vendor-specific severities to incoming issues is absolutely important to 
my use-cases.

> * 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.

Is there a common nexus for this work? eg. do most of the folks who are 
doing security work tend to congregate on the security sublist?

> * 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.

Very important.

> * 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.

Can you expand on what you mean here? Is this usecase about extending 
the existing tooling into the generic CI processes that YP members are 
using, or about expanding the tooling in the YP's indigenous CI?

> * 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.

I think I passed over the wiki pages and presentations for SRTool once, 
a while ago. But I didn't pay much attention at the time because it 
wasn't clear *what it did*.

After reviewing it again, I think it might be the kind of tooling I've 
been searching for to help my team coordinate our CVE response work. 
I'll test it out and see if it is something I can use/contribute towards.

> * 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.

I'm also interested in this, as the maintainer of our opkg fork. So far, 
I haven't had to respond to a CVE against the project, but that won't 
last forever.

>
> Kind regards,
> Marta
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#1747): https://lists.openembedded.org/g/openembedded-architecture/message/1747
> Mute This Topic: https://lists.openembedded.org/mt/101334933/3616788
> Group Owner: openembedded-architecture+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [alex.stewart@ni.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

-- 
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@ni.com

Re: [OE-core] [Openembedded-architecture] Security processes: YP needs

[Mark Hatle]

On 9/13/23 11:00 AM, Alex Stewart wrote:
> Thanks for driving this Marta. Internally and externally, it feels like
> we're just on the cusp of everyone *suddenly caring* about our security
> response strategy. So it's good to see that we're making moves in that
> direction.
> 
> In general, this list looks complete to me. I'm primarily interested in
> the response coordination, triage, and tracking usecases. Those are the
> biggest pain points for my team, at the moment. And that is primarily
> driven by a lack of tooling.
> 
> More responses inline.
> 
> On 9/13/23 07:52, Marta Rybczynska via lists.openembedded.org wrote:
>> [You don't often get email from rybczynska=gmail.com@lists.openembedded.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> 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.
> 
> I'm not sure I understand this usecase. Is there a reason those people
> can't/won't just lookup the CVE on the NIST site?

Management goes to an engineer and says "Customer XYZ says we need a statement 
if CVE-2024-12345 affects us.  Can you please comment?"

Engineer goes to the Yocto Project "list", and looks the number up and doesn't 
find it.  Does this mean we're affects?  We're not affected?  We were affected, 
but it's been fixed (if so when?), etc?

So then they have to go to NIST, look at the CVE, find the information and do 
the evaluation if Yocto Project is affected.

Instead what (I have observed) is that people who like to go to a single list 
(for Yocto Project) information, look up a CVE and get a clear statement of: 
This affects us, this does not affect us, we did not evaluate it or it was fixed 
by commit XYZ in branch....

Then if the item is "not evaluated", they can THEN got to NIST for their own 
evaluation.  This saves a huge amount of time for people who are regularly 
requested to respond to these messages.

>> * 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
> 
> Has there been any discussion of adopting the OpenVEX document standard
> that the Chainguard guys are putting together? [1] It seems like the VEX
> use-cases align well with our needs around tracking and coordinating CVE
> response between YP member and individual developers.
> 
> I've been considering it for my internal use for a while. And also
> considering replacing the existing cve_check output JSON with OpenVEX,
> once it has stabilized.
> 
> [1] https://github.com/openvex/spec
> 
>> * 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.
> 
> I'll note here that some of us are sinners and do actually support
> network-attached (and internet-attached) embedded devices. :)
> 
> But the greater point of OS vendors being able to triage and assign
> vendor-specific severities to incoming issues is absolutely important to
> my use-cases.
> 
>> * 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.
> 
> Is there a common nexus for this work? eg. do most of the folks who are
> doing security work tend to congregate on the security sublist?

Security means different things to different people.  I.e.

1) Secure design
    - Is the system designed to have security services, if so are the defaults 
setup to both be appropriate and also functional?

2) Additional security software
    - i.e. meta-security, what additional software can be available to enhance 
security design/implementation of the system

3) Security (bug) response
    - This is where I see a lack of common nexus for work.  We don't have a good 
place to discuss CVE specific information.  Now the question really is, should 
we have a separate space.  CVEs are just bugs.  Bugs are usually worked on via 
the main mailing list.  So that argument says no, we shouldn't have a special 
list.  BUT the perception is CVEs are "special", so maybe a list specifically to 
discuss the ramifications of a CVE, fix/mitigation strategy or similar would 
make sense -- keeping actual bug fixes to the main mailing list?

>> * 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.
> 
> Very important.
> 
>> * 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.
> 
> Can you expand on what you mean here? Is this usecase about extending
> the existing tooling into the generic CI processes that YP members are
> using, or about expanding the tooling in the YP's indigenous CI?
> 
>> * 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.
> 
> I think I passed over the wiki pages and presentations for SRTool once,
> a while ago. But I didn't pay much attention at the time because it
> wasn't clear *what it did*.
> 
> After reviewing it again, I think it might be the kind of tooling I've
> been searching for to help my team coordinate our CVE response work.
> I'll test it out and see if it is something I can use/contribute towards.

SR Tool requires constant feeding and maintenance from staff, at a minimum to do 
initial triage work.  This means we need a small group of individuals who can 
take the new items (and changes to existing) and comment on a regular (daily) 
basis.  This is the part we've not been terribly successful in the past.  People 
are great at delivering patches, but trying to do the proactive (before 
cve-checker) evaluation of CVEs is an activity that often feels like busy work, 
so it's easy to get behind on and never catch up.

I would love to see the project use SR Tool to manage CVE information, (bugzilla 
is where the bugs need to be managed and processed), as well as cve-checker to 
be able to continue to feed information or what we believe the current state of 
things are.  This combination would give us per-emptive notification of new 
items (SR-Tool), and late validation of items (cve-checker) on the perceived 
state of things.

--Mark

>> * 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.
> 
> I'm also interested in this, as the maintainer of our opkg fork. So far,
> I haven't had to respond to a CVE against the project, but that won't
> last forever.
> 
>>
>> Kind regards,
>> Marta
>>
>>
>>
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#187610): https://lists.openembedded.org/g/openembedded-core/message/187610
> Mute This Topic: https://lists.openembedded.org/mt/101340097/3616948
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [Openembedded-architecture] Security processes: YP needs

[Marta Rybczynska]

On Wed, Sep 13, 2023 at 2:33 PM Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
>
> 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.

Do you also mean that we should make sure Poky follows security best practices?

Noted the point on documenting the way process works/will work so other teams
can extend it to their layer.

>
> 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!
>
Out of curiosity, what have you backported? cve-check? LTS work?

> 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?
>

We have Yocto Project Compatible already. Do we need something else?

Cheers,
Marta

Re: [Openembedded-architecture] Security processes: YP needs

[Marta Rybczynska]

On Wed, Sep 13, 2023 at 6:00 PM Alex Stewart <alex.stewart@ni.com> wrote:
>
> Thanks for driving this Marta. Internally and externally, it feels like
> we're just on the cusp of everyone *suddenly caring* about our security
> response strategy. So it's good to see that we're making moves in that
> direction.
>

Thank you Alex!

>
> More responses inline.
>
> On 9/13/23 07:52, Marta Rybczynska via lists.openembedded.org wrote:
> > * 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.
>
> I'm not sure I understand this usecase. Is there a reason those people
> can't/won't just lookup the CVE on the NIST site?
>

Mark's answer is clarifying that. I'll add that this is a requirement
I have heard
from multiple sources. People might look up CVE/NIST, but that takes time if
you are required to look up all CVEs. If we have common data, we avoid
duplicate work.

> > * 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
>
> Has there been any discussion of adopting the OpenVEX document standard
> that the Chainguard guys are putting together? [1] It seems like the VEX
> use-cases align well with our needs around tracking and coordinating CVE
> response between YP member and individual developers.
>

We might decide to use it. However, openVEX a way to output
the data we have/will have (the conclusion), not a way to sync up the work.

>
> > * 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.
>
> I'll note here that some of us are sinners and do actually support
> network-attached (and internet-attached) embedded devices. :)
>
> But the greater point of OS vendors being able to triage and assign
> vendor-specific severities to incoming issues is absolutely important to
> my use-cases.
>

This is an important point. YP is generic and YP assesment of severity might
be different than the one from a vendor. It means that our process should
be flexible enough that a vendor can take the data and assign their own
severity.

> >
> > * Visibility of the security work of the YP
> >
> > There is much work on security in the YP, but it lacks visibility.
>
> Is there a common nexus for this work? eg. do most of the folks who are
> doing security work tend to congregate on the security sublist?

I'd like to know :) This thread is a big cross-post (and sorry for
that, but I need
to reach the whole audience), for further discussions I'd like to invite all
to a dedicate list.

>
> > * 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.
>
> Can you expand on what you mean here? Is this usecase about extending
> the existing tooling into the generic CI processes that YP members are
> using, or about expanding the tooling in the YP's indigenous CI?

This is a requirement assembling multiple ones. Many people mentioned
that additional
tooling would be needed and/or helpful. A CI template is an example
here. I'm interested
in your list of tooling that would be important or useful to have.
Preferably related to processes
that are currently done in-house and that we can make more generic and
share the work.

>
> > * 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.
>
> I'm also interested in this, as the maintainer of our opkg fork. So far,
> I haven't had to respond to a CVE against the project, but that won't
> last forever.

CVEs against a fork, this is an interesting use-case... Noted :)

Cheers,
Marta

Re: [OE-core] [Openembedded-architecture] Security processes: YP needs

[Marta Rybczynska]

On Wed, Sep 13, 2023 at 6:28 PM Mark Hatle
<mark.hatle@kernel.crashing.org> wrote:
> >> * Visibility of the security work of the YP
> >>
> >> There is much work on security in the YP, but it lacks visibility.
> >
> > Is there a common nexus for this work? eg. do most of the folks who are
> > doing security work tend to congregate on the security sublist?
>
> Security means different things to different people.  I.e.
>
> 1) Secure design
>     - Is the system designed to have security services, if so are the defaults
> setup to both be appropriate and also functional?
>
> 2) Additional security software
>     - i.e. meta-security, what additional software can be available to enhance
> security design/implementation of the system
>
> 3) Security (bug) response
>     - This is where I see a lack of common nexus for work.  We don't have a good
> place to discuss CVE specific information.  Now the question really is, should
> we have a separate space.  CVEs are just bugs.  Bugs are usually worked on via
> the main mailing list.  So that argument says no, we shouldn't have a special
> list.  BUT the perception is CVEs are "special", so maybe a list specifically to
> discuss the ramifications of a CVE, fix/mitigation strategy or similar would
> make sense -- keeping actual bug fixes to the main mailing list?
>

It might e interesting to have opinion on people who are submitting CVE fixes...
Would keeping that discussion in a separate place be helpful?

> >>
> >> * SRTool
> >>
> >> We might decide to use it again. It allows one to do much but requires
> >> constant commitment.
> >
> > I think I passed over the wiki pages and presentations for SRTool once,
> > a while ago. But I didn't pay much attention at the time because it
> > wasn't clear *what it did*.
> >
> > After reviewing it again, I think it might be the kind of tooling I've
> > been searching for to help my team coordinate our CVE response work.
> > I'll test it out and see if it is something I can use/contribute towards.
>
> SR Tool requires constant feeding and maintenance from staff, at a minimum to do
> initial triage work.  This means we need a small group of individuals who can
> take the new items (and changes to existing) and comment on a regular (daily)
> basis.  This is the part we've not been terribly successful in the past.  People
> are great at delivering patches, but trying to do the proactive (before
> cve-checker) evaluation of CVEs is an activity that often feels like busy work,
> so it's easy to get behind on and never catch up.
>
> I would love to see the project use SR Tool to manage CVE information, (bugzilla
> is where the bugs need to be managed and processed), as well as cve-checker to
> be able to continue to feed information or what we believe the current state of
> things are.  This combination would give us per-emptive notification of new
> items (SR-Tool), and late validation of items (cve-checker) on the perceived
> state of things.

SRTools code base (https://git.yoctoproject.org/srtool) has seen no changes for
4 years. If we decide to use, we'll also need to maintain the tool. Is Windriver
going to update the fork? David (adding in copy), do you have any information?

Otherwise we would need to maintain our version, and update to the code
to take into account how the world have changed. For example, with the
 CVE v5 JSON, using the CVE database directly for the feed of new CVE list
makes more sense than using NVD, for example. For the reason of performance
and delay. When SRTool was developed, that data wasn't available.

Cheers,
Marta

Re: [OE-core] [Openembedded-architecture] Security processes: YP needs

[Mark Hatle]

On 9/15/23 2:59 AM, Marta Rybczynska wrote:
> On Wed, Sep 13, 2023 at 6:28 PM Mark Hatle
> <mark.hatle@kernel.crashing.org> wrote:
>>>> * Visibility of the security work of the YP
>>>>
>>>> There is much work on security in the YP, but it lacks visibility.
>>>
>>> Is there a common nexus for this work? eg. do most of the folks who are
>>> doing security work tend to congregate on the security sublist?
>>
>> Security means different things to different people.  I.e.
>>
>> 1) Secure design
>>      - Is the system designed to have security services, if so are the defaults
>> setup to both be appropriate and also functional?
>>
>> 2) Additional security software
>>      - i.e. meta-security, what additional software can be available to enhance
>> security design/implementation of the system
>>
>> 3) Security (bug) response
>>      - This is where I see a lack of common nexus for work.  We don't have a good
>> place to discuss CVE specific information.  Now the question really is, should
>> we have a separate space.  CVEs are just bugs.  Bugs are usually worked on via
>> the main mailing list.  So that argument says no, we shouldn't have a special
>> list.  BUT the perception is CVEs are "special", so maybe a list specifically to
>> discuss the ramifications of a CVE, fix/mitigation strategy or similar would
>> make sense -- keeping actual bug fixes to the main mailing list?
>>
> 
> It might e interesting to have opinion on people who are submitting CVE fixes...
> Would keeping that discussion in a separate place be helpful?

Ya, a security mailing list can be interesting for those types of discussions, 
but ultimately the code needs to go to the regular pull list -- which depending 
on the project (and level of discussions) it may make sense just to have those 
discussions on the regular list.  It's tricky, and I'm not sure what the right 
answer is here.

>>>>
>>>> * SRTool
>>>>
>>>> We might decide to use it again. It allows one to do much but requires
>>>> constant commitment.
>>>
>>> I think I passed over the wiki pages and presentations for SRTool once,
>>> a while ago. But I didn't pay much attention at the time because it
>>> wasn't clear *what it did*.
>>>
>>> After reviewing it again, I think it might be the kind of tooling I've
>>> been searching for to help my team coordinate our CVE response work.
>>> I'll test it out and see if it is something I can use/contribute towards.
>>
>> SR Tool requires constant feeding and maintenance from staff, at a minimum to do
>> initial triage work.  This means we need a small group of individuals who can
>> take the new items (and changes to existing) and comment on a regular (daily)
>> basis.  This is the part we've not been terribly successful in the past.  People
>> are great at delivering patches, but trying to do the proactive (before
>> cve-checker) evaluation of CVEs is an activity that often feels like busy work,
>> so it's easy to get behind on and never catch up.
>>
>> I would love to see the project use SR Tool to manage CVE information, (bugzilla
>> is where the bugs need to be managed and processed), as well as cve-checker to
>> be able to continue to feed information or what we believe the current state of
>> things are.  This combination would give us per-emptive notification of new
>> items (SR-Tool), and late validation of items (cve-checker) on the perceived
>> state of things.
> 
> SRTools code base (https://git.yoctoproject.org/srtool) has seen no changes for
> 4 years. If we decide to use, we'll also need to maintain the tool. Is Windriver
> going to update the fork? David (adding in copy), do you have any information?
> 
> Otherwise we would need to maintain our version, and update to the code
> to take into account how the world have changed. For example, with the
>   CVE v5 JSON, using the CVE database directly for the feed of new CVE list
> makes more sense than using NVD, for example. For the reason of performance
> and delay. When SRTool was developed, that data wasn't available.

Last time I used it was almost exactly 4 years ago.

The tool itself is pretty simple, it's the data import/export that is the 
complex bit(s).  Maybe the lesson here isn't to use SR Tool, but take some of 
the concepts from it and maybe implement something ourselves (in the future).

The key things are:

1) Automatic import from external CVE/Security sources (not all security items 
are CVEs)

2) A way to triage the information, and do LOCAL edits of the information
    - Way for the user to query what's new?
    - Way for the user to query what's changed since last time?
    - Way for the user to query other things...
    - Local edit could be YP 'status'
    - Local edit could add public OR private information about a given item
    - Local edits should be able to link a problem with a bug and release
    - Local edits should be able to TRACK progress of a bug
    - Local edits to CREATE security items not otherwise known (either YP 
specific, or based on bug reports, etc)
    - A way to temporarily set things as 'restricted', only for specific people 
to view until it's public information.

3) Way to generate reports for users.
    - General report
    - CVE Specific report

3) Export connection, primarily to a bug tracking system.
    - The tool should allow creation and tracking of the bugs (filed in a 
standard way based on the security information)


The above sounds complicated, but honestly shouldn't be.  Some of the items 
above are really optional, or could even use the bug tracking system directly 
which just makes this more of a reporting tool.

(The above of course all assumes we have the desire and ability to triage 
incoming security information, vs simply reacting to what cve-checker or 
specific people report to use.  The later is reactive and useful, the former is 
proactive but can be resource intensive.)

--Mark

> Cheers,
> Marta

RE: [yocto] Security processes: YP needs

[Reyna, David]

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

Re: [Openembedded-architecture] [yocto] Security processes: YP needs

[Marta Rybczynska]

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
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#1775): https://lists.openembedded.org/g/openembedded-architecture/message/1775
> Mute This Topic: https://lists.openembedded.org/mt/101570670/5827677
> Group Owner: openembedded-architecture+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [rybczynska@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

RE: [Openembedded-architecture] [yocto] Security processes: YP needs

[Reyna, David]

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 <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
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#1775): https://lists.openembedded.org/g/openembedded-architecture/message/1775
> Mute This Topic: https://lists.openembedded.org/mt/101570670/5827677
> Group Owner: openembedded-architecture+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [rybczynska@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [Openembedded-architecture] [yocto] Security processes: YP needs

[Marta Rybczynska]

[-- Attachment #1: Type: text/plain, Size: 10516 bytes --]

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
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#1775):
> https://lists.openembedded.org/g/openembedded-architecture/message/1775
> > Mute This Topic: https://lists.openembedded.org/mt/101570670/5827677
> > Group Owner: openembedded-architecture+owner@lists.openembedded.org
> > Unsubscribe:
> https://lists.openembedded.org/g/openembedded-architecture/unsub [
> rybczynska@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >
>

[-- Attachment #2: Type: text/html, Size: 15178 bytes --]