Scan (Vulnerabilities, SBOM, AIBOM)

Purpose

Scans container images for vulnerabilities (Trivy), generates a software bill of materials (Syft) and Docker Scout data, and — when AI packages are present — emits an AI bill of materials (AIBOM).

The scan module has no configuration of its own. It inherits registry access from the modules that expose images:

• Amazon ECR — via the aws module's SubImageScanRole
• GitLab Container Registry — via the gitlab module's PAT (requires the read_registry scope)

Prerequisites

• At least one registry-providing module configured and synced:
  • aws for ECR images, and/or
  • gitlab with read_registry scope for GLCR images
• Images must already appear in the graph as ContainerImage nodes from a sync. Scan runs per image.

Required Fields

None. Enable the module and save.

Setup Steps

1. Ensure the source registry module (aws, gitlab, or both) is configured and has synced at least once.
2. In Modules → Scan, toggle the module enabled and save.
3. Trigger a sync from Run Sync, or wait for the scheduled run.

What Runs Per Image

1. crane pulls the image once into a local OCI directory.
2. Trivy, Syft, and Docker Scout read that directory in parallel.
3. If Syft detects AI-related packages (openai, anthropic, langchain, transformers, …), AIBOM runs against the OCI layers.
4. Results are ingested into Neo4j and surface in Vulnerabilities, Fixes, and inventory views.

AIBOM is non-fatal: a scan is considered successful even when AIBOM is skipped.

Troubleshooting

• No images scanned — the source module has not synced yet, or it synced but produced no ContainerImage nodes. Check its latest run in Sync History.
• GLCR pulls fail — the GitLab token is missing the read_registry scope, or does not cover the group the image lives in.
• ECR pulls fail with AccessDenied — SubImageScanRole is missing the ECR read permissions. Redeploy the AWS setup template; it already includes them.