Scopes

Scopes

While doing vulnerability assessments on a specific product it is often the case that we give some vulnerability some status for some reason, and that this reasonning would also be valid for the same vulnerability on another product.

CVE scan provides a notion of scopes to allow the security analysis to use a single annotation file for several vulnerability reports and automatically import the and apply assessments that are shared between them, while keeping the ability to restrict some assessments to some specific reports.

The first step to enable this function is to provide a specific scope for a given report, by using the --scope.transversal, --scope.project and --scope.component command-line options (or the corresponding entries in a configuration file):

cvescan scan-inventory \
    --uct-dir ~/cvescan/sources/uct.git \
    --inventory-format cvescan \
    --inventory inventory.json \
    -o report.json
    --scope.transversal "ARMv8"
    --scope.project "MyProject"
    --scope.component "Component_1"

Then load up the report in the web UI. Now when creating an annotation for some vulnerability you will be presented with an enriched interface:

The "Scope" drop-down allows to select the scope of the annotation:

• Component level (e.g. /MyProject/Component_1): this annotation will only be valid for this report, and will never be shared with other reports with a different scope.component value;
• Project level (e.g. /MyProject): this annotation will be shared with any report that has the same scope.project value;
• Transversal scope (e.g. ARMv8): this annotation will be shared with any report that has the same scope.transversal value. The difference with project and component scopes lies in the fact that there is no hierarchical dependency between the transversal scope and other ones: there can be serveral components in different projects that share the same transversal scope.
• All: this annotation will be shared with all reports, regardless of their scope values.

After creating the annotation you will notive that the top of the manual assessment panel now displays scope information:

Promoting / demoting an annotation

Now that we have an annotation it is possible to edit its scope. Promotion allows you to indicate that a given annotation is valid for a larger scope (e.g. all components in a given project), while demotion allows to restrict the scope of a specific annotation (e.g. only a specific component of a project). This can be done by clicking on the scope of the annotation:

This provides some room for afterthoughts. It is usual for instance, to work on a specific report whithout thinking about whether the assessments are valid for other components or projects, then later promote the annotations for which the reasonning used is can be applied to others ones.

Duplicating an annotation

Sometimes a specific assessment can be true for some reasons on a large class of products, but can be adjusted for some specific products. A typical example of this would be an "Exploitable" status attributed to some vulnerability for a Linux platform, while some product making use of this platform does not provide any entry point to trigger the vulnerability that shoud be marked as "Not exploitable" on this specific product.

In this case you can duplicate a specific annotation: the new annotation must have a more specific scope than the original one. Now the vulnerability view will present a stack of annotations:

While it is possible to inspect the more general annotations (by clicking on them in the stack), it will always be the more specific annotation that will take precedence over the others.

Overriding version information

For any annotation with a scope you can override the vulnerable version information from the vulnerabilities database by editing a dedicated "version-specific" tag. This allows to set a specific status to the vulnerability for a version range based on the information you gathered, while keeping track of the original version range.

A word of warning

While this functionnality helps keeping the assessment time to a minimum by avoiding to redo the same work on the same vulnerabilities over and over again, it needs to be used with care. Let's say for instance that some annotation has been made on some CVE on the basis that a specific assumption is true for all components of a given project (e.g. no bluetooth support in the kernel), then it makes sense to give it the project scope.

Assume now that later on some additional component is added to the project, but that does not satisfy this specific assumption (i.e. some component with bluetooth support), then the annotation will be automatically applied to this new component and the corresponding vulnerability will be flagged as "not vulnerable", while it may not necessarily be the cases.

Thus it is critical to define the annotations scopes with care (i.e. ask the question "am I sure that this assessment is true whatever my context ?"), and to review automatically imported annotations when starting work on a new report.