Hi Marta,
* SRTool: We might decide to use it again. It allows one to do much but
requires constant commitment.
There are many ways to use the SRTool.
(a) The original design was to perform 100% triage of incoming CVEs. This
was a business requirement of Wind River, and we have used the SRTool
successfully for 4-5 year now.
(b) The main limitation with the SRTool for Yocto Project was the lack of
integration with Bugzilla (Ross ran out of time)
* This is the crucial other half of the workflow
* There is the automatic creation of appropriate defect records for
investigation
* There is also the automatic tracking of the overall CVE status, both
CVEs in progress and the CVEs completed
* Wind River has an extension for full integration with Jira, and that
saves weeks of work for the CVE management
(c) The guiding rule was that CVE management was in the SRTool, but specific
defect work was also done in Jira/Bugzilla, for a clean separate of domains
(d) The SRTool has a user model
* Together with Bugzilla, it is easy to track single people and even
multiple people working on CVEs
(e) The SRTool also has the built-on ability to look up the CVE status from
other distributions (Red Hat, Debian, ...) so that one can get a peek of
existing triages and resolutions
(f) The SRTool is build like Toaster on top of Django, so development and
debugging skills for Toaster immediate apply
(g) Also with the Django base, it is very simple to add any number of modular
extensions to support for example CVE Scanner integration
(h) The SRTool also has report generation (in text, CSV, and Excel) in
addition to email notification support.
(i) There is also a "private" model for CVEs under embargo, with strict
access control lists.
PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps
using it to track and coordinate work will bring immediate benefit.
PROPOSAL 2: I am happy to give you a live demo of Wind River's fully
operational SRTool, so you can see all of the bells and whistles in action. I
am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific.
PROPOSAL 3: I will start refreshing the YP SRTool repository with my current
implementation level from Wind River (with the Wind River specific modules left
out of course :-)
David
BTW, I also support an extension to the SRTool that manages CVE scanning of
build images, with hooks to a number existing CVE scanners (e.g. Trivy) in
addition to other vulnerability metrics. This is probably out of scope to YP at
this time, but it is perhaps something to grow in to.
-----Original Message-----
From: yo...@lists.yoctoproject.org <yo...@lists.yoctoproject.org> On Behalf Of
Marta Rybczynska via lists.yoctoproject.org
Sent: Wednesday, September 13, 2023 4:52 AM
To: yocto-secur...@lists.yoctoproject.org; OE-core
<openembedded-core@lists.openembedded.org>;
openembedded-architect...@lists.openembedded.org; yo...@lists.yoctoproject.org
Cc: Richard Purdie <richard.pur...@linuxfoundation.org>; Steve Sakoman
<st...@sakoman.com>; Khem Raj <raj.k...@gmail.com>;
mark.ha...@kernel.crashing.org; Ross Burton <ross.bur...@arm.com>; Joshua Watt
<jpewhac...@gmail.com>
Subject: [yocto] Security processes: YP needs
Hello,
I've been working recently on collecting what works and what doesn't
in YP security processes. The goal is to go forward and define an
actionable strategy!
Today, I'd like to share with you the summary of what I have heard as
needs from several people (those in Cc:).
I want the community to comment and tell us what you find important
and what you'd like to see added or changed from this list.
* CVEs: Visibility if YP is vulnerable or not
People want to be able to check/look up a specific CVE; it might be a
CVE unrelated to YP
(eg. package not included, Windows issue). The cve-checker result is a
part of the solution, but people also want to know which CVEs do not
apply.
* CVEs: synchronization of the work on fixes
Currently, there is no synchronization; multiple parties might be
working on the same fix while nobody is working on another. There
might be duplication of work.
Ross has https://wiki.yoctoproject.org/wiki/CVE_Status
* Triaging of security issues
Related to CVE fixes and includes issues reported directly to the YP.
Some issues are more likely to be serious for embedded products
(attack by network), so not all has the same priority.
* Private security communication
A way to send a notification of a non-public security issue. For
researchers, other projects etc.
The security alias exists, but only some people know about its existence.
* Visibility of the security work of the YP
There is much work on security in the YP, but it lacks visibility.
* Documentation
Related to visibility. We need easy-to-find documentation of subjects
like submitting a CVE fix,
reporting a private issue, and how our processes work... This
documentation should address people who are not regular contributors.
* Additional tooling
We could add additional tooling: a template on how to add cve-check to
the CI (possibly
a different one than the autobuilder), analyze the result, and extend
our tooling to their layers...
It is also related to the "Architecture" topic below.
* Architecture work
Security if more than CVE fixes. We also have what is happening in
meta-security: hardening, compiler option,
secure package configuration, use of code coverage tools, and so on
* SRTool
We might decide to use it again. It allows one to do much but requires
constant commitment.
* Presence on pre-notification lists and receiving information before
the vulnerability gets public
YP currently depends on public data. Principal distributions receive
the information before
a vulnerability becomes public. It requires (in short) private
reporting, a security team, and a track
of excellent security record.
* Becoming a CNA (be able to assign CVEs)
Needed if we want to assign CVEs to the software of the YP, like
autobuilder, Toaster etc.
Kind regards,
Marta
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188183):
https://lists.openembedded.org/g/openembedded-core/message/188183
Mute This Topic: https://lists.openembedded.org/mt/101570671/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
