New feature: Exempt vulnerabilities for single archives (digests)

[henrikplate]

Until release 3.1.6, vulnerabilities could be exempted by combining the configuration settings vulas.report.exceptionExcludeBugs and vulas.report.exceptionExcludeBugs.<ID>, whereby the former enumerates all vulnerability identifiers that should not cause a build exception, and the latter was used to provide a corresponding reason for every identifier <ID>, e.g.,

vulas.report.exceptionExcludeBugs = ABC, 123
vulas.report.exceptionExcludeBugs.ABC = Lorem ipsum
vulas.report.exceptionExcludeBugs.123 = Foo bar

The feature implemented with this PR simplifies and extends exemptions: First, the enumeration is not required any longer. Second, the exemption can be done for single archives (by specifying their digest) or all archives (by using *)

The following example exempts

• vulnerability ABC, no matter the affected library (indicated by the wildcard *), and
• vulnerability XYZ for the archives with digest 123 and 456.

vulas.report.exemptBug.ABC.reason = Lorem ipsum
vulas.report.exemptBug.ABC.libraries = *

vulas.report.exemptBug.XYZ.reason = Foo bar
vulas.report.exemptBug.XYZ.libraries = 123, 456

Moreover, the configuration used to exempt entire scopes changes to vulas.report.exemptScope.

TODOs

• Tests
• Documentation

[henrikplate]

To be tested: (De)serialization of VulnerableDependency#exemption and information included in result reports

[serenaponta]

I am not sure about how this test file was created but I think it comes from running the code as in the serialization of the vulnerableDependency the View to be used was missing and thus the constructList was serialized even if we never did it as it's not required by the client at this step.

[serenaponta]

At this step old exemptions existing in the db are not kept into account as their key does not contain the prefix vulas. and thus doesn't match DEPRECATED_CFG_PREFIX

[serenaponta]

There is a mismatch between old config keys where the prefix vulas. was removed and the new ones. As a result exemptions saved with older clients are not considered. This would also impact the way exemptions are read from Configuration objects vs the Map.
I also added a test to show that the digest/reasons values returned passing from the Map are different than those obtained via the Configuration objects

I can also do the changes but first I want to agree on the prefix.

[serenaponta]

Still something is not working as expected as the JSON from the test system contains the following (but JUnit tests are successfully checking that the content is correct)

"exemption": {
"bugId": "CVE-2020-9548",
"digest": "dig",
"reason": "3490508379D065FE3FCB80042B62F630F7588606= testing new feature"
},

This happens when separators are not escaped to be part of the key (https://commons.apache.org/proper/commons-configuration/javadocs/v1.10/apidocs/index.html?org/apache/commons/configuration/PropertiesConfiguration.html)
e.g. vulas.report.exemptBug.CVE-2020-1234.dig:ABCD= testing new feature

Also, to double check that vulas:report only exempts a certain CVE for the specified digest.

[henrikplate]

I guess this should be final String[] scopes = _map.get(CFG).split(",");

[serenaponta]

Yes, I just pushed it.

[serenaponta]

Why should we allow exemptions for library ids whose namespace (aka mvn group) is not specified?

[henrikplate]

Package URLs for Python packages will not have a namespace. Alternatively, we can consider the type, but such if-else conditions would not be nice either. Moreover, I do not know whether the prg. language can be easily determined at this point in time.

[serenaponta]

This is linked to the previous comment, why not requiring that also the namespace is not null?