Code scanning (SAST)

AlertaVuln runs a series of specialised scans over your source code, normalises everything they emit into one finding set, and tiers each finding REDYELLOWGREEN.

The Code Scan page with RED, YELLOW and GREEN severity count tiles, Secrets/Misconfig/Code/License type filters, and findings grouped per file

The Code Scan page: severity tiles up top, type filters, and findings grouped by file. Demo data.

Local-first by design

av sast scan runs every engine on your machine:

Engines are downloaded on first use, pinned to an exact version, and verified against a hard-coded SHA-256 checksum before they are installed.
Verified binaries are cached under alertavuln/bin in your user config directory and reused on later scans.
Each engine runs as a separate subprocess with a five-minute timeout - nothing is linked into the CLI.
Your source code never leaves the machine. Only when you opt in with --project are the resulting findings - not your code - uploaded.

One engine failing does not abort the scan: the failure is recorded against that engine and the remaining engines still run.

The scan series

Rather than one monolithic analyser, av sast scan runs a series of specialised scanners over your tree. Between them the series covers:

Insecure code patterns in your source, across the languages present in the tree.
Hard-coded secrets and credentials - API keys, access keys, private keys, passwords and tokens.
Infrastructure-as-code misconfigurations in Terraform, Dockerfiles, Kubernetes manifests, Helm charts and CloudFormation.
Licences present in the scanned tree.

Every scanner is version-pinned and checksum-verified before it runs, and every scan runs the whole series, so a given CLI build always produces reproducible results: the same scanners, at the same versions, on every run.

Dependency-vulnerability scanning is deliberately not part of the series. Dependency CVEs are owned by the core CVE pipeline - your tech stack matched against CVE announcements on the Vulnerabilities page - so scanning for them here would double-report the same CVEs on the Code Scan page.

RED / YELLOW / GREEN tiering

Engines emit SARIF. A numeric security-severity score (0–10) wins when one is present; otherwise the SARIF level decides:

Signal	Tier
Score ≥ 7.0	RED
Score 4.0 – 6.9	YELLOW
Score below 4.0	GREEN
Level `error`, no score	RED
Level `warning`, no score	YELLOW
Any other level, no score	GREEN

A result with no explicit level inherits its rule’s default level, so scanners that declare severity per rule tier correctly.

For CI gating, --fail-on red (or yellow) makes the scan exit non-zero when the worst finding reaches that tier.

Uploading to a project

Pass --project to upload the findings so they appear on the project’s Code Scan page, where they are grouped into Secrets, Misconfig, Code and License categories. The scan’s source repo and git ref are detected from the scanned working tree’s git metadata (--repo / --ref override the detection; --no-upload keeps a scan local-only). Uploaded findings carry their raw SARIF signals, and the server computes the authoritative tier from them.

Server-side scanning (Enterprise)

If you can’t - or don’t want to - check a repo out locally, av sast server-scan asks AlertaVuln to clone and scan a project’s connected repos on our infrastructure. It is an Enterprise feature, counts against a weekly quota on a rolling 7-day window, and always prints a cost warning before enqueueing. The local av sast scan stays free and unlimited on every plan.

What each area covers

Secret detectionHard-coded secrets and credentials found across the working tree.

IaC misconfigurationMisconfiguration checks for Terraform, Kubernetes, Dockerfiles and more.

Licence complianceSPDX classification and the copyleft RED/YELLOW/GREEN policy signal.