On 9/15/23 2:59 AM, Marta Rybczynska wrote:
On Wed, Sep 13, 2023 at 6:28 PM Mark Hatle
<mark.ha...@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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187771):
https://lists.openembedded.org/g/openembedded-core/message/187771
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]
-=-=-=-=-=-=-=-=-=-=-=-
