.alertavuln-ignore

A root-level .alertavuln-ignore file tells AlertaVuln which paths in your repo are not your running application - test fixtures, generated reports, vendored code - so they never contribute findings or scores. It is a product feature available to every project, not something you need to request.

Where it lives

Create a file named .alertavuln-ignore at the root of your repo, alongside files like .gitignore. AlertaVuln looks for it in exactly that location; a missing file is treated as no exclusions at all.

Format (v1)

Each non-blank, non-comment line is a path prefix, relative to the repo root:

Rule	Behaviour
One entry per line	Each line is a single path prefix
`#` comments	A line starting with `#` is ignored
Blank lines	Ignored
Case	Matching is case-insensitive
Separators	Backslashes are normalised to forward slashes, so Windows-style paths work
Matching	A prefix matches everything nested under it, not the bare prefix path itself - `test/fixtures/` excludes `test/fixtures/anything`, but a prefix does not exclude a file literally named `test/fixtures`. Use directory-shaped prefixes, not individual file names.
Size	The file is capped at 64KB

Example

# Deliberately-vulnerable fixtures used by our test suite - not real code
test/package-files/

# Generated HTML/JSON reports checked in for reference
docs/reports/

The first entry excludes everything under test/package-files/, so intentionally-insecure sample code used to exercise the test suite never shows up as a real finding. The second excludes docs/reports/, a folder of generated reports that gets committed for convenience but isn’t part of the application either.

Which scanners honour it

Scanner	Honours `.alertavuln-ignore`?
Dependency scanning	Yes
SAST (code scanning, including secret-detection engines)	Yes
Reachability	Yes
Tech-stack sync	Yes
Container image scanning	No - scans a built image, not your source tree
DAST	No - scans a running URL, not your source tree

The exclusion applies everywhere a covered scanner runs: the CLI, hosted “scan it for me” scans, and server-side ingest. Container image scanning and dynamic scanning are unaffected by design - they inspect a built artifact or a live endpoint, not files in your repo, so there is no source path for the ignore file to exclude.

Enforcement

.alertavuln-ignore is enforced both when scanning and again at ingest, so ignored paths are filtered out even when a scan is uploaded directly:

At scan time - the CLI and hosted scan workers read the file from the scan root and drop matching paths before results are even produced, before upload.
At server ingest - for uploaded code-scan findings and tech-stack manifests, the AlertaVuln API re-applies the same matching logic as an authoritative backstop, independent of what the scanning side already filtered.

Because the server-side filter is authoritative, adding a new entry to .alertavuln-ignore also cleans up findings from past scans: on the next scan of that path, previously-reported findings that now fall under an ignored prefix are marked fixed rather than lingering as open.

For dependency and tech-stack scanning this cleanup is package-aware: when a package is discovered only in manifests under a newly-ignored path, the next repo scan (or av techstack sync) drops that package from the project’s tech stack, and any open CVE alerts for it are resolved automatically with the reason “affected package removed from project”. A package that is also declared in a manifest outside the ignored path stays tracked - only packages whose every source manifest is now excluded are removed. Scanning is event-driven, so the resolution happens on the next scan of the project, not the instant you commit the ignore entry.

Silent by design

Ignored paths simply produce no findings - there is no dismissed-findings list or suppressed-count dashboard to check. The one visible signal is at scan time: the CLI prints a one-line notice,

suppressed 12 findings via .alertavuln-ignore

when at least one finding was excluded, so you can confirm the file is taking effect (or notice a typo’d prefix that matched nothing).

Inline suppression

Sometimes the right place to suppress a finding is not a whole path but a single line - a reviewed false positive you want to annotate at the source, right where the next reader will see it. AlertaVuln honours inline suppression comments on the finding’s own line, or on a comment line immediately above it.

Our own marker: `alertavuln-ignore`

Add alertavuln-ignore (or the short alias av-ignore) in a comment. It is engine-agnostic - it applies uniformly across every scanner AlertaVuln runs, and it names no third-party tool, so it reads cleanly in any codebase.

A bare marker suppresses any finding reported on that line:

// Path is built from a fixed internal allow-list, reviewed 2026-07.
var full = Path.Combine(baseDir, name); // alertavuln-ignore

A scoped marker suppresses only findings whose rule matches an id you list after a colon, so unrelated findings on the same line still surface:

cmd := exec.Command(bin, args...) // av-ignore: subprocess-launched-with-variable

You can write the short leaf id (unsafe-path-combine) rather than the fully qualified rule id - a scoped id matches when it equals the rule id, is a trailing segment of it, is its leaf, or is a leading dotted segment. Separate multiple ids with commas: // alertavuln-ignore: id-one, id-two. A CWE id also matches, for example // av-ignore: cwe-22.

We respect the markers your other scanners already honour

If your team already annotated a reviewed false positive for another security scanner, adopting AlertaVuln does not resurrect it. We recognise the inline suppression markers these security scanners honour, in the form each tool uses:

Marker	Tool	Form recognised
`nosemgrep`	Semgrep	bare, or `nosemgrep: rule-id`
`#nosec`	gosec	bare, or `#nosec G404`
`trivy:ignore`	Trivy	`trivy:ignore:AVD-...`
`codeql` / `lgtm`	CodeQL	bracket form only: `lgtm[cwe-22]`, `codeql[...]`

A marker is honoured only when it is the first thing in the comment - a marker merely mentioned in prose (// TODO: drop the nosemgrep annotation) or sitting inside a string literal (a URL such as "https://lgtm.com/...") never suppresses a finding. The CodeQL / lgtm bracket form is required precisely because a bare lgtm reads as “looks good to me” far too often to treat as a suppression.

This is the “we do not break your environment” guarantee: the false positives your existing tooling already suppresses stay suppressed when AlertaVuln scans the same code.

Lint markers are deliberately not honoured

Pure style and lint suppression markers - noqa (flake8/ruff), eslint-disable, and nolint (golangci-lint) - do not suppress a security finding. A noqa on a line almost always silences a formatting or style nit; if we treated it as “ignore the security finding here too”, we would silently drop a real vulnerability because someone suppressed an unrelated lint warning. Only markers whose purpose is security-finding suppression are honoured. To suppress a security finding, use alertavuln-ignore (or one of the recognised security markers above), which makes the security decision explicit at the source.

Visibility

Like the ignore file, inline suppression is silent in the results, but the CLI prints a one-line notice at scan time when at least one finding was suppressed this way:

suppressed 3 finding(s) via inline comments (alertavuln-ignore or a recognized scanner marker)