This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

False Positives

1 - Hints

2 - Corrections

When Anchore analyzes an image, it reports a Software Bill of Materials (SBOM) to be stored and later scanned in order to match package metadata against known vulnerabilities. One aspect of the SBOM is a best effort guess of the CPE (Common Platform Enumeration) for a given package. The Anchore analyzer builds a list of CPEs for each package based on the metadata that is available (ex. for Java packages, the manifest, which contains multiple different version specifications among other metadata), but sometimes gets this wrong.

For example, Java Spring packages are generally reported as follows:

  • Spring Core, version 5.1.4
    • cpe:2.3:a:*:spring-core:5.1.4:*:*:*:*:*:*:*

However, since Spring is a framework built by Pivotal Software, the CPE referenced in the NVD database looks more like:

  • cpe:2.3:a:pivotal_software:spring_security:5.1.4:*:*:*:*:*:*:*

To facilitate this correction, Anchore provides the Correction feature. Now, a user can provide a correction that will update a given package’s metadata so that attributes (including CPEs) can be corrected when Anchore does a vulnerability scan

Using the above example, a user can add a correction as using anchorectl or via HTTP POST to the /corrections endpoint:

{
  "description": "Update Spring Core CPE",
  "match": {
    "type": "java",
    "field_matches": [
        {
            "field_name": "package",
            "field_value": "spring-core"
        },
        {
            "field_name": "implementation-version",
            "field_value": "5.1.4.RELEASE"
        }
    ]
  },
  "replace": [
      {
          "field_name": "cpes",
          "field_value": "cpe:2.3:a:pivotal_software:spring_security:5.1.4:*:*:*:*:*:*:*"
      }
  ],
  "type": "package"
}

JSON Reference:

  • description: A description of the correction being added (for note taking purposes)
  • replace: a list of field name/value pairs to replace.
  • type: The type of correction being added. Currently only “package” is supported
  • match:
    • type: The type of package to match upon. Supported values are based on the type of content available to images being analyzed (ex. java, gem, python, npm, os, go, nuget)
    • field_matches: A list of name/value pairs based on which package metadata fields to match this correction upon
      • The schema of the fields to match can be found by outputting the direct JSON content for the given content type:
        • Ex. Java Package Metadata JSON:
        {
    "cpes": [
        "cpe:2.3:a:*:spring-core:5.1.4.RELEASE:*:*:*:*:*:*:*",
        "cpe:2.3:a:*:spring-core:5.1.4.RELEASE:*:*:*:*:java:*:*",
        "cpe:2.3:a:*:spring-core:5.1.4.RELEASE:*:*:*:*:maven:*:*",
        "cpe:2.3:a:spring-core:spring-core:5.1.4.RELEASE:*:*:*:*:*:*:*",
        "cpe:2.3:a:spring-core:spring-core:5.1.4.RELEASE:*:*:*:*:java:*:*",
        "cpe:2.3:a:spring-core:spring-core:5.1.4.RELEASE:*:*:*:*:maven:*:*"
    ],
    "implementation-version": "5.1.4.RELEASE",
    "location": "/app.jar:BOOT-INF/lib/spring-core-5.1.4.RELEASE.jar",
    "maven-version": "N/A",
    "origin": "N/A",
    "package": "spring-core",
    "specification-version": "N/A",
    "type": "JAVA-JAR"
}

Note: if a new field is specified here, it will be added to the content output when the correction is matched. See below for additional functionality around CPEs.

To add the above JSON using anchorectl the following command can be used

anchorectl correction add -i path-to-file.json

You could also achieve something similar using

anchorectl correction add \
--match package=spring-core \
--match implementation-version="5.1.4.RELEASE" \
--type java \
--replace cpes="cpe:2.3:pivotal_software:spring_security:5.1.4:*:*:*:*:*:*:*" \
--replace description="Update Spring Core CPE"

Don’t forget you can list, delete and get a correction with the anchorectl

The command to retrieve a list of existing corrections is:

anchorectl correction list

The command to delete a corrections is:

anchorectl correction delete {correction_id}
# {correction_id} is the UUID of the correction you wish to delete

The command to get a correction is:

anchorectl correction get {correction_id}
# {correction_id} is the UUID of the correction you wish to get

The result of the correction can be checked using the image content command of anchorectl. For example to see our above java correction we would run

anchorectl image content -t java Image_sha256_ID -o json

We would see the spring-core package returned as having the CPE cpe:2.3:a:pivotal_software:spring_security:5.1.4:*:*:*:*:*:*:*

Note: Don’t forget to replace the Image_sha256_ID with the image ID you’re trying to test.

Corrections may be updated and deleted via the API as well. Creation of a Correction generates a UUID that may be used to reference that Correction later. Refer to the Enterprise Swagger spec for more details.

CPE Templating

CPE replacement can be templated based on the other fields of the package as well. In the above example, a replacement could have been provided as follows:

{
  "field_name": "cpes",
  "field_value": "cpe:2.3:a:pivotal_software:spring_security:{implementationVersion}:*:*:*:*:*:*:*" 
}

For the “cpes” field only, Anchore Enterprise can recognize a templated field via curly braces “{}”. Package JSON keys contained here will be replaced with their corresponding value.

Vulnerability Matching Configuration

Search by CPE can be globally configured per supported ecosystem via the anchore enterprise policy engine config. The default enables search by cpe for all ecosystems except for javascript (since NPM package vulnerability reports are exhaustively covered by the GitHub Security Advisory Database).

A fully-specified default config is as below:

policy_engine:
    vulnerabilities:
      matching:
        default:
          search:
            by_cpe:
              enabled: true
        ecosystem_specific:
          dotnet:
            search:
              by_cpe:
                enabled: true
          golang:
            search:
              by_cpe:
                enabled: true
          java:
            search:
              by_cpe:
                enabled: true
          javascript:
            search:
              by_cpe:
                enabled: false
          python:
            search:
              by_cpe:
                enabled: true
          ruby:
            search:
              by_cpe:
                enabled: true
          stock:
            search:
              by_cpe:
                # Disabling search by CPE for the stock matcher will entirely disable binary-only matches 
                # and is *NOT ADVISED*
                enabled: true

A shorter form of the default config is:

policy_engine:
    vulnerabilities:
      matching:
        default:
          search:
            by_cpe:
              enabled: true
        ecosystem_specific:
          javascript:
            search:
              by_cpe:
                enabled: false

If disabling search by CPE for all GitHub covered ecosystems is desired, the config would look like:

policy_engine:
    vulnerabilities:
      matching:
        default:
          search:
            by_cpe:
              enabled: false
        ecosystem_specific:
          stock:
            search:
              by_cpe:
                enabled: true