search

intel / cve-bin-tool

The CVE Binary Tool helps you determine if your system includes known vulnerabilities. You can scan binaries for over 200 common, vulnerable components (openssl, libpng, libxml2, expat and others), or if you know the components used, you can get a list of known vulnerabilities associated with an SBOM or a list of components and versions.
https://cve-bin-tool.readthedocs.io/en/latest/
GNU General Public License v3.0
1.14k stars 444 forks source link

GSoC 2024 Project Idea: Improved Triage Support #3770

Open terriko opened 5 months ago

terriko commented 5 months ago

This is mostly a placeholder for @anthonyharrison to fill in more details below (or replace this issue with his own when he's got time to write it out)

cve-bin-tool: Improved Triage Support

Project description

Triage allows users of CVE Binary Tool to customize the reports they get by adding extra data on the vulnerabilities found. This is often used for discarding false positives in cases where a fix has been backported to an older version, or cases where the product vulnerability is in dispute but the database is not yet updated. It can also be used to store notes on mitigations or change severity ratings based on more informed risk assessments of how software is used in context.

Many folk, slightly naively, are asking for "0 vulnerabilities in SBOM" type reports and since that's unlikely to actually be true, triage provides one way to give vulnerability reports that are "clean" but also give information as to why some vulnerabilities have been discarded as unfixable, mitigated, or irrelevant.

Currently, CVE Binary Tool supports VEX triage. There are three formats @anthonyharrison has in mind for more support:

In addition to support for new formats, this project may involve

Skills

Difficulty level

Project Length

Mentor

GSoC Participants Only

This issue is a potential project idea for GSoC 2024, and is reserved for completion by a selected GSoC contributor. Please do not work on it outside of that program. If you'd like to apply to do it through GSoC, please start by reading #3550.

anthonyharrison commented 5 months ago

ADDITIONAL INFORMATION

There will be hopefully be a Python library available for the start of GSOC to help with the parsing and generating of the VEX documents in the various formats.

The triage process will be to take a triage file and associated SBOM, ensure that the triage file is linked with the SBOM, scan the SBOM for vulnerabilities, remove the vulnerabilities which have been marked as not applicable (the VEX document will contain vulnerabilities which are still applicable) and then report the remaining vulnerabilities.

The reporting of the scan should include a new report section which identifies the vulnerabilities which have been included in the triage as well as generating an updated triage file.

HamzaMateen commented 4 months ago

@anthonyharrison I think I would be able to work on this. I have working proficiency of Python and I am comfortable with the parsing part. I would likely have to research on licensing and what SBOMs are and their significance here.

I would like to have your guiding input on how I should take things from here. Thank you!

What I have done so far:

I have locally setup the tool and ran the tests with the following results: 

========== 1178 failed, 812 passed, 62 skipped in 581.46s (0:09:41) =========

Read the CONTRIBUTING.md guide after which I have also opened a small documentation PR at https://github.com/intel/cve-bin-tool/pull/3852 .

anthonyharrison commented 4 months ago

Reminder - This issue is reserved for GSOC2024 applicants.

You need to apply to the GSOC program (applications have not yet opened) where you can describe your proposed approach to solving the problem. By all means explore the problem and do some background reading to get an understanding of the problem domain, but no code should be submitted for this issue.

HamzaMateen commented 4 months ago

That makes very much sense. Thank you!

tahifahimi commented 4 months ago

@anthonyharrison, At first sight, CycloneDX looks like the best option, but the tricky part is that there are two VEX formats for this. Also, it was nice to check what other projects (like Trivy)have done in this matter.

anthonyharrison commented 4 months ago

@tahifahimi The triage process within the cve-bin-tool supports a triage option based on CycloneDX in addition to a bespoke approach. There are now 3 (soon to be four) different approaches/formats to handling VEX as part of a triage process and we need to recognise this. The ingestion and generation of VEX information to be used within the documents should be independent of the format and you need to think how this could be accommodated. As noted earlier in this issue, there will shortly be a Python library which will help with this which should make the task more manageable.

One of the key features of cve-bin-tool is to be compliant with a range of standards. We support both types of SBOMS (SPDX and CycloneDX) and we should be able to do the same for VEX. Other tools may take a different view in only supporting a limited number of formats.

tahifahimi commented 4 months ago

ADDITIONAL INFORMATION

There will be hopefully be a Python library available for the start of GSOC to help with the parsing and generating of the VEX documents in the various formats.

The triage process will be to take a triage file and associated SBOM, ensure that the triage file is linked with the SBOM, scan the SBOM for vulnerabilities, remove the vulnerabilities which have been marked as not applicable (the VEX document will contain vulnerabilities which are still applicable) and then report the remaining vulnerabilities.

The reporting of the scan should include a new report section which identifies the vulnerabilities which have been included in the triage as well as generating an updated triage file.

@anthonyharrison thanks for the information. Please correct me if I am wrong. If we are going to have a Python library for parsing different file format, then the only important remaining file is to apply it to the cve-scanner. Since in the current triage process, it just gets a triage file and create a report based on the vulnerabilities reported in triage. The purpose of the GSoC question is to add SBOM as well as triage, scan the SBOM for vulnerabilities and report the vulnerabilities based on both triage and SBOM scanning.

anthonyharrison commented 4 months ago

@tahifahimi The current triage process will need to be improved. It doesn't currently use an SBOM as an input but not all VEX formats require a SBOM. You need to think about the issues which this may bring as part of the triage process. You also need to think about the issues which the different VEX formats offer and how to manage the data for each vulnerability so that it can be used to produce updated VEX in any format. Think also about the lifecycle of a vulnerability and how it will change. The main aim of the triage process is helping reduce the effort for developers and the reporting will need to reflect the various options.

tahifahimi commented 4 months ago

@anthonyharrison thanks a lot for that clarification! I created a local SBOM file and a VEX file for my local setup to ensure I got that right. When I scanned them using the cve-bin-tool, the results I got were not consistent between the 2. With that said, the ask is:

Will it be possible for you to suggest some test files to work with (reproduce)? Or a link perhaps to read more on this? Thanks! :slightly_smiling_face:

anthonyharrison commented 4 months ago

I am not surprised that there is some inconsistency - that is why we have created the GSOC project!

I suggest we create a couple of SBOMs (I suggest upto 5 components), and then work through the triage process. Initially, the triage process will record that the vulnerabilities are under review. Then we need to update the triage documents to consider other states - vulnerability is valid or vulnerability is not valid (or exploitable) with an appropriate version. These new status should come via the updated VEX document.

On Tue, 5 Mar 2024 at 05:31, tahera_fahimi @.***> wrote:

@anthonyharrison https://github.com/anthonyharrison thanks a lot for that clarification! I created a local SBOM file and a VEX file for my local setup to ensure I got that right. When I scanned them using the cve-bin-tool, the results I got were not consistent between the 2. With that said, the ask is:

  • Ensure that the results for different VEX files are consistent with the SBOM files.
  • Maybe, we iterate over the SBOM and pre-existing VEX files, to ensure we create a valid VEX file from SBOM files.
  • Add support for different VEX formats which are not supported.

Will it be possible for you to suggest some test files to work with (reproduce)? Or a link perhaps to read more on this? Thanks! 🙂

— Reply to this email directly, view it on GitHub https://github.com/intel/cve-bin-tool/issues/3770#issuecomment-1977997376, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAID22WTH43HBNT74XIBKTYWVKDXAVCNFSM6AAAAABCT37UE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXHE4TOMZXGY . You are receiving this because you were mentioned.Message ID: @.***>

Mayankrai449 commented 4 months ago

@anthonyharrison I was working on adding locations of products in CycloneDX SBOMs. Since sboms are generated using lib4sbom library, I wanted to ask if it is possible to update it to parse location data and use this format utilising evidence key: Screenshot 2024-03-06 210620

I have achieved this addition manually in the https://github.com/intel/cve-bin-tool/blob/d3132dacd1be605f0100ef6b3a5fcffa08d11c37/cve_bin_tool/output_engine/__init__.py#L897 I thought utilizing lib4sbom library for it would be a cleaner method.

I've also acknowledged your work on lib4vex for vex generation, and I've been going through it and would like to contribute. Hopefully we can utilize it soon for our gsoc project

mastersans commented 4 months ago

@anthonyharrison I am interested in this project and I have started working on the proposal will share a draft soon on Gitter.

anthonyharrison commented 3 months ago

@anthonyharrison I am interested in this project and I have started working on the proposal will share a draft soon on Gitter.

@mastersans. Look forward to seeing your draft. I suggest you read around the topic to understand the life cycle around SBOMs and VEX so you understand the issues.

mastersans commented 1 month ago

@anthonyharrison while doing the this week gsoc task i had an inital structure in mind, In lib4vex we are using list of Vulnerablity object with addition to metadata to generate the vex document similarly when we parse we retrieve metadata, product , vulnerability:: when i looked into the vulnerability class present in lib4sbom there were different attributes that we can set in case of vulnerability, i am not sure and little confused weather its intended in such way, i have marked the once being present in vulnerability obj used so shouldn't the report also include the remaining like score, metric cvss_version etc:

unmarked onces aren't being used in parsing or generation, here the line i studied in lib4sbom:

https://github.com/anthonyharrison/lib4sbom/blob/fbc28a03e418444bf1085e7b6647daabc8180c34/lib4sbom/cyclonedx/cyclonedx_parser.py#L445

https://github.com/anthonyharrison/lib4sbom/blob/fbc28a03e418444bf1085e7b6647daabc8180c34/lib4sbom/cyclonedx/cyclonedx_generator.py#L689

can you guide me a little regarding this is it meant to not take the score, cvss vector and others into consideration also while generation of vulnerability data in above link we are only taking NVD data source into account. I hope something didn't went underlooked from my side. cc @terriko

anthonyharrison commented 1 month ago

@mastersans The Vulnerability object in lib4sbom has a set_value method which allows any attribute to be added into the Vulnerability object. You can add use this to include the additional attributes with the object.

However the multiple formats of VEX documents supported by lib4vex have different sets of attributes for a vulnerability so the attributes may not be included in the vulnerability item within a VEX document. lib4vex is an initial implementation but could be extended to include additional attributes for a vulnerability if it is deemed useful.

mastersans commented 1 month ago

@anthonyharrison I did came across set_value() method and my interpretation was same regarding different set of attributes as you mentioned but even if we use set_value() we aren't taking the list of attributes i mention into account while parsing and generation, example: set_value() with purl is working because we are using it here : https://github.com/anthonyharrison/lib4sbom/blob/fbc28a03e418444bf1085e7b6647daabc8180c34/lib4sbom/cyclonedx/cyclonedx_generator.py#L705

so even after using set_value() it won't include the given things and I did it tried it out, I hope i am not horribly wrong with this one.

anthonyharrison commented 1 month ago

@mastersans Setvalue can be used for any attribute. Not all of the attributes are used in the SBOM/VEX generation process currently but this can be changed if required.

mastersans commented 1 month ago

@mastersans Setvalue can be used for any attribute. Not all of the attributes are used in the SBOM/VEX generation process currently but this can be changed if required.

@anthonyharrison that mostly sums it up for me Thanks, I'll draft a PR regarding it asap and make use of current set methods and set_value() addtionally.

terriko commented 1 week ago

Marking this as attached to the 3.3.1 milestone to make my tracking for that easier.