[Openembedded-architecture] proposal: instant security information and a bom.json

[Pascal Bach]

On 18.08.2016 10:19, Richard Purdie wrote:
> On Thu, 2016-08-18 at 07:50 +0000, Meier, Roger wrote:
>> Dear OpenEmbedded Architecture Team
>>
>> We would like to have up-to-date information on known security
>> vulnerabilities for each build based on OpenEmbedded.
>>
>> Goal:
>> * provide information about known security vulnerabilities, see [1]
>> * cover all components included within an image
>> * all builds provide a bom.json containing meta data on security
>>     vulnerabilities and additional information about the image such
>>     as license information, vendor URL's, etc.
>>
>> Implementation proposal:
>> * bitbake recipies will contain additional fields, e.g.
>>     * CPE_NAME="cpe:2.3:a:openssl:openssl:1.0.1f"
>>         The Common Platform Enumeration standard identifies
>> components
>>         uniquely and vulnerabilities have assigned identifiers, see
>> [2]
> Whilst I understand the idea, I am worried about trying to maintain
> duplicate information in our recipes. Why couldn't this just be:
>
> CPE_NAME = "cpe:2.3:a:${BPN}:${BPN}:${PV}"
This is only true if the package name is the same as the name used in the cpe database.
It is true for busybox and openssl for example but not for for Qt5 for example where there is only one cpe but there are many sub packages.
So it might be reasonable to use the above as default but allow to override it in a recipe if necessary.
>
>>     * CVE_FIXES="CVE-2016-2842 CVE-2016-0705"
>>         This information shall reflect known vulnerabilities that are
>> fixed within
>>         a recipe by a patches, see [3]
> We already discussed and agreed to add CVE tags into the patches
> themselves. Again, I don't want to duplicate information, I'd much
> rather the system just constructed such a field by parsing the tags out
> of the patches.
That is a really good idea.
>
>> * add the new fields CPE_NAME and CVE_FIXES to
>> classes/package.bbclass 
> Which piece of package.bbclass and why? Could you 'cpe' class not
> extend the package.bbclass functions if its enabled making it opt in?
It was just a first idea to put that into the package.bbclass, however I think a new cpe class that can be inherited globally should work too.
>
>> * use a Web API to get information about the security
>> vulnerabilities, e.g.
> Have you looked at the cve-tool patch that has been on the OE-Core
> mailing list? That also has some similarities and intentions to this
> and I'd love to see people collaborating on such tools.
I will have a look at it. From our point of view it is important to have a mechanism that is exchangeable so that it can be integrated with other sources of CVE information.
So the source can be cve-took, cve-check or any WebAPI. As long as they provide the information in the right format.

In addition the proposed bom.json we see as an important part as it would allow to do some additional analysis later. For example determine security issues in already released products.
> Just to be clear, I do think something like this would be good, however
> we need to ensure we don't duplicate information or make things harder
> for recipe maintenance.
I agree it should be the least effort possible for the recipe authors/maintainers.

Pascal