User Vulnerability Management
#Vulnerability Management
In the vulnerability portlet, you can view the vulnerabilites that are currently present in SW360 in more detail, independent of the release or project they apply to. Clicking on the top level entry Vulnerabilities, a table listing all vulnerabilities is shown:
Clicking on a vulnerability entry in the table, the details view of this vulnerability is shown.
The details view is also linked from the vulnerabilities view in the project portlet and component and release portlet, respectively.
Vulnerabilities automatically imported into SW360 - e.g. via the CVE search connection of SW360 - can be applicable for a release or not. The latter can happen, because release data in SW360 is incorrect or not complete. Then the CVE search service uses a more general search pattern yielding a lot of vulnerabilities, only some of which actually apply to the release. Therefore, in SW360 a vulnerability can be marked for a given release with one of the following verification states:
- NOT CHECKED
- CHECKED
- INCORRECT
Only admins can mark a vulnerability or change the verification state and enter a comment to give reasons for the change. The verification state and the meta-information (when and by whom the verification state was changed and the comment) are stored as VerificationStateInfo at the appropriate ReleaseVulnerabilityRelation.
The verification state is displayed in the detail mode of a release, at vulnerabilities in the column Verification of the vulnerability table. User without admin-rights can only see the vulnerabilities that are NOT CHECKED or CHECKED together with a tooltip containing the meta-info. The INCORRECT vulnerabilities are hidden from users without admin rights in the release detail view and also in the component detail view and in the project detail view.
Admins see in the same table a dropdown menu, where they can adjust the state. An admin is shown all vulnerabilities belonging to a project, component or release, also those that are marked as INCORRECT.
In the detail view of a project, in the category Vulnerabilites, the vulnerabilities belonging to the linked releases of the project are shown. Such a vulnerability in the context of a certain project can be assigned one of the following Ratings:
- NOT CHECKED
- IRRELEVANT
- RESOLVED
- APPLICABLE
Those ratings are shown in the vulnerability table of the project details view. A user that has writing permission for the project can change the rating via a drop-down menu. If he changes the value, he is asked to enter a comment. The VulnerabilityRating together with the meta-data (who has changed the rating, date of change of the rating and comment) is stored in one database object ProjectVulnerabilityRating per project.
A user that has no writing permission on the project is shown the Vulnerability Rating in the table without the possibility to change the value.
The number of vulnerabilities for a project with rating NOT CHECKED is displayed in the bullet of the Vulnerability tab of the project detail view. The bullet is red if there are vulnerabilities with status NOT CHECKED for the project. In the example 7 of the 10 existing vulnerabilities are NOT CHECKED.
The complete list of status changes for vulnerability ratings in the project portlet and for vulnerability verifications in the component portlet is shown when hovering with the mouse over the vulnerability rating/verification in the table. This is shown for the project vulnerability table in the picture below.
#CVE-Search
See this use case.
All heuristics start by looking at the cpe. If the cpe is valid, i.e. start with the string "cpe:" and are longer then 10 chars, this is used for the search. If the search fails it falls back to the other search levels.
There are at the moment two different heuristics implemented which define how and in which order to search the cveSearch DB.
They can actually be combined, i.e. one could be the fallback of the other.
The matching of vendor- and product-names is improved by using a lists of actual vendors resp. actual products of an vendor.
From the information given for a release, which is expected to be either of the form
- vendor=
"VENDOR_NAME", name="PRODUCT_NAME"and a version or - vendor=
"", name="VENDOR_NAME PRODUCT_NAME"and a version (as generated by the bdpimport).
we try to find the best matches from the vendors list and then for these ones the best matches in their respective product lists. The first run includes the version, and if no matching product with the correct version is found, a second run is made without the version restriction.
For the definition which matches are good we use a variation of the Levenshtein distance with some asymmetric modifications. In the following we will call the left side needle and the right side haystack. The needles will come from the lists and the haystack will be (parts of) the raw information extracted from the release. The defining rules are
- Our Levenshtein distance is equal to the regular Levenshtein distance, if the haystack does not contain any spaces.
- Skipping a prefix ending with a space or of the haystack does not cost anything, i.e. does not increase the distance
- Skipping a postfix starting with a space of the haystack does not cost anything, i.e. does not increase the distance
- If either the needle or the haystack is empty, the distance is
Integer.MAX_VALUE
This means that the string "needle" has
- distance 0 to itself, i.e.
"needle" - distance 0 to itself plus a postfix separated by a space, e.g.
"needle postfix" - distance 0 to itself plus a prefix separated by a space, e.g.
"prefix needle" - distance 2 to something which has regular distance of 2 surrounded by a prefix and a postfix which are separated by spaces, e.g.
"prefix nedles postfix"
The finetuning parameters can be configured by setting the following properties in /etc/sw360/sw360.properties or in the configuration.yml
cvesearch.default.vendor.threshold=1
cvesearch.default.product.threshold=0
cvesearch.default.cutoff=6
There are three variables which can be used for finetuning of the algorithm
-
cutoff(defaults toInteger.MAX_VALUE, i.e. no cutoff) -
vendorThreshold(defaults to0, i.e. no vendor threshold) -
productThreshold(defaults to0, i.e. no product threshold)
- is not able to find anything if no vendor but a unique product is given
- many search queries
- it will always try find the best match, e.g. also very bad matches, if cutoff is to large
In the vulnerability tables of the projects portlet and the component and release portlet you can see, whether a vulnerability was found directly by the CPE or by heuristics. In the latter case, also the distance (and therefore the quality of the match with 0 = best possible match) is displayed.
In addition, below the vulnerability tables of the projects portlet and the component and release portlet, you can see the number of directly linked releases that was found by CPE or heuristic, respectively:
This heuristic builds in the first step the correct needle
cpe:2.3:.:.*apache.*maven.*3.0.4.* and finds the cpe cpe:2.3:a:apache:maven:3.0.4
The heuristic guesses the vendor apache and the product maven. Together with the version this results in the same cpe-needle cpe:2.3:.:.*apache.*maven.*3.0.4.*.
The first levels of this heuristic fails until the sixth level which does not use the vendor. The resulting needle is then cpe:2.3:.:.*apache.*maven.*3.0.4.* and finds the cpe cpe:2.3:a:apache:maven:3.0.4
The heuristic guesses the vendor apache since it is a substring of apache maven and thus has distance 0, the same is true for the productname maven which results in the same cpe-needle as above.