Ingest Harbor vulnerability findings, scans, and audit logs

Latest Dynatrace Preview

The Dynatrace integration with Harbor allows you to unify and contextualize vulnerability findings across DevSecOps tools and products, enabling central prioritization, visualization, and automation of security findings.

Harbor is a container registry that allows scanning the stored container images with various tools, such as Trivy. It serves the generated vulnerability findings from container images. The Dynatrace platform observes the corresponding runtime entities (the running containers) associated with those images. Ingesting and mapping vulnerability findings to the runtime entities helps users to better focus on the top risks that affect their production applications.

How it works

ingest mechanism

Dynatrace integration with Harbor is an extension running on Dynatrace ActiveGate. Once you enable and configure the Dynatrace Harbor extension

  1. It periodically reaches out to Harbor products and fetches the new vulnerability findings, scans, and audit logs.

  2. The fetched data is ingested into Dynatrace and mapped to the Dynatrace semantic conventions.

  3. Data is stored in a bucket called default_security_custom_events (for details, see Built-in Grail buckets).

Prerequisites

See below for the Harbor and Dynatrace requirements.

Harbor requirements

We recommend using a robot account for fine-grained authorization. Make sure to

  • Store the generated secret for the robot account, as it won't be recoverable after creation

  • Refresh the expiry period in due time

  • Edit the robot account to enable the following permissions:

    • In System permissions, enable List for the Audit log, Project, and Security Hub resources
    • In Project permissions, enable List for the Artifact resource for all the projects you want to monitor

Dynatrace requirements

  • ActiveGate version 1.300+

  • Permissions: For a list of permissions required, go to Dynatrace Hub Hub, select Extensions Extensions, and display Technical information.

  • Generate an access token with the openpipeline.events_security scope.

Get started

  1. In Dynatrace, search for Harbor and select Install.

  2. Follow the on-screen instructions to configure the extension.

  3. Verify configuration by running the following queries in Notebooks:

    • For audit logs:

      fetch logs
      | filter log.source=="Harbor"
    • For finding events:

      fetch events
      | filter dt.system.bucket == "default_security_custom_events"
      | filter event.kind == "SECURITY_EVENT"
      AND event.provider=="Harbor"
      AND event.type=="VULNERABILITY_FINDING"
    • For scan events:

      fetch events
      | filter dt.system.bucket == "default_security_custom_events"
      | filter event.kind == "SECURITY_EVENT"
      AND event.provider=="Harbor"
      AND event.type=="VULNERABILITY_SCAN"
  4. Once the extension is installed and working, you can access and manage it in Dynatrace via the Extensions Extensions app. For details, see Extensions 2.0 concepts.

Use cases

With the ingested data, you can accomplish various use cases, such as

Frequently asked questions (FAQ)

Why are some scans not being reported?

The Harbor APIs only expose the status of the last completed scan for artifacts. This means that when the extension runs, it can only report the most recent scan that occurred (if any) during the last collection interval.

If the extension is set to collect scan and vulnerability data once per hour and two scans occurred in that last hour, only the details of the most recent one will be reported.

Which data model is used for the security logs and events coming from Harbor?

  • Vulnerability finding events store the individual vulnerability findings reported by Harbor per container image and component.

  • Vulnerability scan events indicate coverage of scans for individual container images.

  • Audit logs represent user activity logs in Harbor.

Which extension fields are added on top of the core fields of the events ingested from Harbor?

The container_image namespace is added for container image-related information with the following fields:

  • container_image.digest represents the container image digest; this value can be used to match to the runtime containers

  • container_image.repository represents the container repository name

  • container_image.registry represents the container registry name

The container_image.tags field isn't reported by Harbor, so it's not available.

What Harbor asset types are supported by Dynatrace for runtime contextualization?

CONTAINER_IMAGE: All findings from Harbor are generated by vulnerability assessments of container images set with the CONTAINER_IMAGE value in the object.type field, and the container_image namespace is added.

How do we normalize the risk score for Harbor findings?

  • dt.security.risk.level is taken from the severity level set by the configured scanner in Harbor. The values (CRITICAL, HIGH, MEDIUM, LOW, and NONE) are mapped as is, with the exception of Unknown, which is also mapped to NONE.

  • dt.security.risk.score is mapped to a set of fixed values based on the risk level determined above.

dt.security.risk.level (mapped from finding.severity)
dt.security.risk.score
Critical -> CRITICAL
10.0
High -> HIGH
8.9
Medium -> MEDIUM
6.9
Low -> LOW
3.9
Unknown -> NONE
0.0