Scan with GitLab CI#

DevGuard provides reusable GitLab CI components that you can include in your .gitlab-ci.yml to add security scanning with minimal configuration. Each component is a self-contained job definition — you pick what you need and pass your DevGuard credentials as inputs.

Prerequisites#

• A DevGuard account and an asset created for your repository
• A DevGuard Personal Access Token with the scan scope — create one under User Settings → Personal Access Tokens
• The asset name in the format @<org>/projects/<project>/assets/<asset> (visible in the asset settings)

Store both values as GitLab CI/CD variables in your project:

Quick start: full pipeline#

The full component wires together all scanning jobs and the complete container lifecycle in one include. It's the fastest way to get a complete DevSecOps pipeline:

This adds the following jobs to your pipeline:

• devguard:secret_scanning — detect leaked secrets with Gitleaks
• devguard:static_application_security_testing — SAST on your source code
• devguard:infrastructure_as_code_scanning — scan IaC files for misconfigurations
• devguard:software_composition_analysis — scan dependencies for known CVEs
• devguard:generate_tag → devguard:build_oci_image → devguard:container_scanning → devguard:push_oci_image → devguard:sign_oci_image → devguard:attest

Individual scanning components#

Secret scanning#

Detects secrets, API keys, and credentials in your repository using Gitleaks.

SAST#

Analyzes source code for security vulnerabilities without executing it.

Infrastructure-as-Code scanning#

Scans Terraform, Kubernetes manifests, Docker configurations and other IaC files for misconfigurations.

Software Composition Analysis (SCA)#

Scans your dependencies for known vulnerabilities. Fails the pipeline if findings meet or exceed fail_on_risk / fail_on_cvss.

Container scanning#

Scans a container image for vulnerabilities. Accepts either a local tar file (from a previous build job) or a remote image from a registry.

Scan a local tar artifact:

Scan a remote image from the registry:

If both image_tag and image_tar_path are provided, image_tag takes precedence.

Container lifecycle#

For projects that build and push container images, the container-lifecycle component handles the complete workflow: tag generation → build (Kaniko) → container scan → push → Cosign signing → in-toto attestation.

The image tag is generated automatically from the branch name, commit SHA, and timestamp. It is passed between all jobs via the $IMAGE_TAG variable. The image is only pushed after the container scan passes.

Bring your own scanner (upload components)#

If you already run your own scanners, you can upload their output to DevGuard directly:

Upload a SARIF file (from any SAST tool):

Upload an SBOM (CycloneDX JSON/XML):

Upload a VEX document:

Common inputs reference#

All components accept these shared inputs:

Using the same component twice#

To run the same component twice in one pipeline (e.g., scanning two separate paths in a monorepo), use job_suffix to avoid job name collisions:

Self-hosted DevGuard#

If you run DevGuard on your own infrastructure, replace the API and web UI URLs:

Related#

• Set up GitLab integration — connect DevGuard to your GitLab instance for issue creation and permission sync
• Scan with GitHub Actions — the equivalent guide for GitHub
• Upload an SBOM — upload pre-generated SBOMs