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....@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
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
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/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
