Semgrep
Purpose
Pulls code security findings into SubImage from either Semgrep Cloud Platform or Semgrep OSS JSON reports. Correlating these with infra metadata helps prioritize fixes.
Secret fields below accept either an AWS Secrets Manager ARN or a value pasted directly into SubImage's managed vault. See Secrets for details.
If your Semgrep Cloud endpoint is self-hosted and not publicly reachable, set tailscale_hostname and run the collector via a SubImage Outpost.
Configuration Modes
SubImage supports two Semgrep modes:
- Cloud: pull findings and dependency data from Semgrep Cloud Platform APIs
- OSS: ingest Semgrep CLI JSON reports through a repository mapping file
Choose the mode in the module configuration blade before saving.
Cloud Setup
Fields
| Field | Secret? | Description |
|---|---|---|
semgrep_app_token |
Yes | Semgrep App Token with org.read scope |
semgrep_dependency_ecosystems |
No | (Optional) Comma-separated ecosystems such as npm,pip for dependency sync |
tailscale_hostname |
No | (Optional) Internal hostname resolved via Outpost |
Steps
- In Semgrep Cloud, open Organization Settings → API Tokens.
- Create a token with
org.readscope. - In SubImage, choose the Cloud tab in the Semgrep module.
- Enter the token in
semgrep_app_token, or provide its AWS Secrets Manager ARN. - Optionally set
semgrep_dependency_ecosystemsif you want Semgrep dependency data ingested. - If your Semgrep endpoint is private, set
tailscale_hostnameand run through a SubImage Outpost. - Save the module configuration.
OSS Setup
Fields
| Field | Secret? | Description |
|---|---|---|
semgrep_oss_source |
No | Repository mapping file path or URI for OSS ingestion |
Steps
- Run Semgrep CLI and produce JSON report artifacts for the repositories you want to ingest.
- Create a repository mapping YAML file and point
semgrep_oss_sourceat it. - In SubImage, choose the OSS tab in the Semgrep module.
- Enter the local path or object-store URI for the mapping file.
- Save the module configuration.
Repository Mapping File Requirements
The mapping file must:
- Be valid UTF-8 YAML.
- Contain a top-level
repositorieslist. - Give each repository entry
provider,owner,repo,url,branch, and a non-emptyreportslist. - Use
reportsentries that each point to exactly one Semgrep OSS JSON artifact.
For sharded or monorepo scans, list each JSON artifact separately under reports. Do not point a reports entry at a directory or object-store prefix containing multiple files.
Example:
repositories:
- provider: "github"
owner: "simpsoncorp"
repo: "sample_repo"
url: "https://github.com/simpsoncorp/sample_repo"
branch: "main"
reports:
- "/path/to/sample_repo-semgrep.json"
- provider: "github"
owner: "different-org"
repo: "different-repo"
url: "https://github.com/different-org/different-repo"
branch: "main"
reports:
- "s3://security-artifacts/semgrep/different-repo/report-1.json"
- "s3://security-artifacts/semgrep/different-repo/report-2.json"OSS Prerequisites And Behavior
- Semgrep OSS JSON does not include repository identity, so the repository mapping file is required.
- To create
FOUND_INrelationships for OSS findings, matching repository nodes must already exist in the graph. - For GitHub repositories, the
GitHubRepository.idmust match the repositoryurldeclared in the mapping file. - If matching repository nodes do not exist yet, SubImage can still ingest
SemgrepSASTFindingnodes, but they will not attach to repositories.
Notes
- Cloud-only Semgrep fields such as finding state, fix status, opened time, and assistant data are only populated for Semgrep Cloud findings.
- OSS mode is aimed at Semgrep SAST findings from Semgrep CLI JSON artifacts, not Semgrep Cloud API data.