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

Anchore Enterprise includes the ability to read a user-supplied ‘hints’ file to allow users to add software artifacts to Anchore’s analysis report. The hints file, if present, contains records that describe a software package’s characteristics explicitly, and are then added to the software bill of materials (SBOM). For example, if the owner of a CI/CD container build process knows that there are some software packages installed explicitly in a container image, but Anchore’s regular analyzers fail to identify them, this mechanism can be used to include that information in the image’s SBOM, exactly as if the packages were discovered normally.

Hints cannot be used to modify the findings of Anchore’s analyzer beyond adding new packages to the report. If a user specifies a package in the hints file that is found by Anchore’s image analyzers, the hint is ignored and a warning message is logged to notify the user of the conflict.

Configuration

See Configuring Content Hints

Once enabled, the analyzer services will look for a file with a specific name, location and format located within the container image - /anchore_hints.json. The format of the file is illustrated using some examples, below.

OS Package Records

OS Packages are those that will represent packages installed using OS / Distro style package managers. Currently supported package types are rpm, dpkg, apkg for RedHat, Debian, and Alpine flavored package managers respectively. Note that, for OS Packages, the name of the package is unique per SBOM, meaning that only one package named ‘somepackage’ can exist in an image’s SBOM, and specifying a name in the hints file that conflicts with one with the same name discovered by the Anchore analyzers will result in the record from the hints file taking precedence (override).

  • Minimum required values for a package record in anchore_hints.json
    {
        "name": "musl",
        "version": "1.1.20-r8",
        "type": "apkg"
    }
  • Complete record demonstrating all of the available characteristics of a software package that can be specified
    {
        "name": "musl",
        "version": "1.1.20",
        "release": "r8",
        "origin": "Timo Ter\u00e4s <[email protected]>",
        "license": "MIT",
        "size": "61440",
        "source": "musl",
        "files": ["/lib/ld-musl-x86_64.so.1", "/lib/libc.musl-x86_64.so.1", "/lib"],
        "type": "apkg"
    }

Non-OS/Language Package Records

Non-OS / language package records are similar in form to the OS package records, but with some extra/different characteristics being supplied, namely the location field. Since multiple non-os packages can be installed that have the same name, the location field is particularly important as it is used to distinguish between package records that might otherwise be identical. Valid types for non-os packages are currently java, python, gem, npm, nuget, go, binary. For the latest types that are available, see the anchorectl image content <someimage> output, which lists available types for any given deployment of Anchore Enterprise.

  • Minimum required values for a package record in anchore_hints.json
    {
        "name": "wicked",
        "version": "0.6.1",
        "type": "gem"
    }
  • Complete record demonstrating all of the available characteristics of a software package that can be specified
    {
        "name": "wicked",
        "version": "0.6.1",
        "location": "/app/gems/specifications/wicked-0.9.0.gemspec",
        "origin": "schneems",
        "license": "MIT",
        "source": "http://github.com/schneems/wicked",
        "files": ["README.md"],
        "type": "gem"
    }

Putting it all together

Using the above examples, a complete anchore_hints.json file, when discovered by Anchore Enterprise located in /anchore_hints.json inside any container image, is provided here:

{
    "packages": [
    {
        "name": "musl",
        "version": "1.1.20-r8",
        "type": "apkg"
    },
    {
        "name": "wicked",
        "version": "0.6.1",
        "type": "gem"
    }
    ]
}

With such a hints file in an image based for example on alpine:latest, the resulting image content would report these two package/version records as part of the SBOM for the analyzed image, when viewed using anchorectl image content <image> -t os and anchorectl image content <image> -t gem to view the musl and wicked package records, respectively.

Note about using the hints file feature

The hints file feature is disabled by default, and is meant to be used in very specific circumstances where a trusted entity is entrusted with creating and installing, or removing an anchore_hints.json file from all containers being built. It is not meant to be enabled when the container image builds are not explicitly controlled, as the entity that is building container images could override any SBOM entry that Anchore would normally discover, which affects the vulnerability/policy status of an image. For this reason, the feature is disabled by default and must be explicitly enabled in configuration only if appropriate for your use case.

2 - Corrections

When Anchore analyzes an image, it persists a Software Bill of Materials (SBOM) which will be submitted for periodic scanning for known vulnerabilities. During the scan, various attributes will be used from the SBOM package artifacts to match to the relevant vulnerability data. Depending on the ecosystem, the most important of these package attributes tend to be Package URL (purl) and/or Common Platform Enumeration (CPE). The Anchore analyzer attempts to generate a best effort guess of the CPE candidates for a given package as well as the purl based on the metadata that is available at the time of analysis (ex. for Java packages, the manifest, which contains multiple different version specifications among other metadata), but sometimes gets this wrong.

To facilitate the necessary corrections in these instances, Anchore provides the Corrections feature. Now, a user can provide a correction that will update a given package’s metadata so that attributes (including CPEs and Package URLs) can be corrected at the time that Anachore performs a vulnerability scan.

An example follows for a very common scenario in the java maven ecosystem where the official maven groupid and artifactid are not available in the metadata and the best guess that the Anchore analyzer surfaces for package url and CPEs is not in line with the vulnerability data, so a correction can be issued to align them.

Imagine an Anchore analysis results in the following package content:

{
  "cpes": [
    "cpe:2.3:a:apache:catalina:9.0.88:*:*:*:*:*:*:*"
  ],
  "implementationVersion": "9.0.88",
  "licenses": [
    "https://www.apache.org/licenses/LICENSE-2.0.txt"
  ],
  "location": "/usr/local/tomcat/lib/catalina.jar",
  "mavenVersion": "N/A",
  "origin": "Apache Software Foundation",
  "package": "catalina",
  "purl": "pkg:maven/org.apache.tomcat-catalina/[email protected]",
  "specificationVersion": "9.0",
  "type": "JAVA-JAR",
  "version": "9.0.88"
}

There are several issues with this entry. The maven groupid and artifactid within the purl, the package name, and the CPE are all not in line with what is expected for proper vulnerability matching.

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

{
  "description": "Correct Tomcat Catalina package metadata",
  "match": {
    "type": "java",
    "field_matches": [
        {
            "field_name": "package",
            "field_value": "catalina"
        }
    ]
  },
  "replace": [
      {
          "field_name": "cpes",
          "field_value": "cpe:2.3:a:apache:tomcat_catalina:{version}:*:*:*:*:*:*:*"
      },
      {
          "field_name": "purl",
          "field_value": "pkg:maven/org.apache.tomcat/tomcat-catalina@{version}"
      },
      {
          "field_name": "package",
          "field_value": "tomcat-catalina"
      }
  ],
  "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. For the “cpes” and “purl” field only, Anchore Enterprise can recognize a templated field via curly braces “{}”. Package JSON keys contained here will be replaced with their corresponding value from the package. For “cpe” if the templated field does not exist in the package, the corresponding cpe component will be replaced with *. For “purl” if the templated field doesn’t exist the purl replacement will be aborted and the purl will remain unchanged from the original value.
  • 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",
    "purl": "pkg:maven/org.springframework/[email protected]",
    "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 and Package URL

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=catalina \
--type java \
--replace cpes="cpe:2.3:a:apache:tomcat_catalina:{version}:*:*:*:*:*:*:*" \
--replace purl="pkg:maven/org.apache.tomcat/tomcat-catalina@{version}" \
--replace package="tomcat-catalina" \
--description="Correct Tomcat Catalina package metadata"

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 now see the tomcat-catalina package content returned with the expected values:

{
  "cpes": [
    "cpe:2.3:a:apache:tomcat_catalina:9.0.88:*:*:*:*:*:*:*"
  ],
  "implementationVersion": "9.0.88",
  "licenses": [
    "https://www.apache.org/licenses/LICENSE-2.0.txt"
  ],
  "location": "/usr/local/tomcat/lib/catalina.jar",
  "mavenVersion": "N/A",
  "origin": "Apache Software Foundation",
  "package": "tomcat-catalina",
  "purl": "pkg:maven/org.apache.tomcat/[email protected]",
  "specificationVersion": "9.0",
  "type": "JAVA-JAR",
  "version": "9.0.88"
}

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.