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

[Mark Hatle <mark.hatle@kernel.crashing.org>]

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