Ingest GitLab security findings and audit logs

Latest Dynatrace
Extension
Published Apr 02, 2026

This page aligns with the new Grail security events table. For the complete list of updates and actions needed to accomplish the migration, follow the steps in the Grail security table migration guide.

Ingest GitLab dependency and container scanning findings, scan events, and audit logs into Dynatrace as security events.

Get started

Overview

Dynatrace integration with GitLab allows you to unify and contextualize GitLab security findings and audit activity across groups, projects, and container images for visualization, analysis, and automation in Dynatrace.

GitLab provides security scanning capabilities such as Dependency Scanning and Container Scanning, which scan code and build artifacts to identify security issues.

Dynatrace ingests and enriches GitLab findings with runtime context to help Dev teams filter and prioritize the risks that affect production applications and code artifacts.

Use cases

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

Requirements

See below for the GitLab and Dynatrace requirements.

GitLab requirements

A GitLab account with access to the groups and projects that should be monitored.
Access to the required GitLab tier for the integrated features:
- Dependency Scanning
- Container Scanning
A Personal Access Token (PAT) for API authentication.
CI/CD pipelines configured with GitLab-managed templates for:
- Dependency Scanning
- Container Scanning

Dynatrace requirements

ActiveGate version 1.310+ that needs to be able to
- Run Extensions 2.0 framework
- Reach the GitLab API endpoints
Permissions: For a list of permissions required, go to Hub, select Extensions, and display Technical information.
Generate an access token with the openpipeline.events_security scope and save it for later. For details, see Dynatrace API - Tokens and authentication.

Activation and setup

In Dynatrace, search for GitLab and select Install.
Follow the on-screen instructions to configure the extension.

Verify configuration by running the following queries in Notebooks:

For audit logs:
```
fetch logs
| filter log.source=="GitLab"
```

For finding events:

fetch security.events
| filter dt.system.bucket == "default_securityevents"
| filter event.provider=="GitLab"
    AND event.type=="VULNERABILITY_FINDING"

For scan events:

fetch security.events
| filter dt.system.bucket == "default_securityevents"
| filter event.provider=="GitLab"
    AND event.type=="VULNERABILITY_SCAN"

Once the extension is installed and working, you can access and manage it in Dynatrace via Extensions. For details, see About Extensions.

Details

How it works

gitlab integration mechanism

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

It periodically collects security findings and audit logs using GitLab APIs.
The fetched data is ingested into Dynatrace and mapped to the Dynatrace Semantic Dictionary.
Data is stored in a bucket called default_securityevents (for details, see Built-in Grail buckets).

Licensing and cost

For billing information, see Events powered by Grail.

FAQ

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

Vulnerability finding events store individual vulnerability findings reported by GitLab for affected artifacts and components.
Vulnerability scan events indicate scan coverage for individual artifacts.
Audit logs represent user activity logs.

Which GitLab security findings are imported into Dynatrace?

If the extension is configured to ingest data at an interval of n hours, then each run ingests all security events updated in the last n hours.
On the first ingest, Dynatrace considers findings updated in the last m hours, where m is the first ingest interval configured in the monitoring configuration.
If no new or updated findings are detected, no findings are ingested.

Which extension fields are added to the core fields of events ingested from GitLab?

The container_image namespace is added for container image related information:
- container_image.digest represents the container image digest and can be used to match runtime containers.
- container_image.repository represents the container repository name.
- container_image.registry represents the container registry name.
The gitlab namespace is added for GitLab-specific attributes on top of the core schema. The full upstream payload is stored in event.original_content.

Example fields:
- gitlab.project.id: Project identifier.
- gitlab.project.name: Project name.
- gitlab.project.branch: Source branch associated with the scan or finding.
- gitlab.group.id: Group identifier.
- gitlab.group.name: Group name.
- gitlab.finding.false_positive: Whether the finding is marked as a false positive.

Which GitLab asset types are supported by Dynatrace for runtime contextualization?

CONTAINER_IMAGE: Findings from GitLab are generated by vulnerability assessments of container images and are mapped with CONTAINER_IMAGE in object.type. The container_image namespace is added, and container_image.digest is used to match ingested findings to runtime containers monitored by Dynatrace. container_image.digest attribute is being used to match the ingested security findings to runtime containers monitored by Dynatrace.

How is risk score normalized for GitLab findings?

Dynatrace normalizes severity and risk scores for all findings ingested through this integration. This helps you prioritize findings consistently, regardless of their source. For details, see Severity and score normalization.

dt.security.risk.level is mapped from GitLab severity values returned by the vulnerability findings API.

dt.security.risk.score is derived from dt.security.risk.level using Dynatrace static severity-to-score mapping.

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