Guides

Ignoring findings

Some findings are wrong, and some are real risks your team accepts. Record that decision once, in a committed .atmos-ignore.yaml or with triage on the platform, and the finding stops failing the build.

The ignore file#

.atmos-ignore.yaml sits at the root of your git repository and is committed with the code, so every decision has a diff, an author and a review. atmos scan, atmos sast and atmos sca read it from the repository root, whichever folder they scan. Outside a git repository they read it from the scanned folder.

.atmos-ignore.yaml

ignore:
  - id: atmos.ts.raw-sql-from-request  # a rule id
    paths: ["src/legacy/**"]
    kind: risk_accepted
    reason: Admin tool, removed in the next release.
    expires: 2026-12-31
  - id: GHSA-xxxx-xxxx-xxxx           # an advisory id, or any of its aliases
    kind: false_positive
    reason: The vulnerable function is never called with user input.

Fields#

Field	Meaning
id	Required. A rule id, or an advisory id for a dependency finding. An advisory entry matches by any of the advisory's ids, GHSA or CVE. Ids match in any case.
kind	Required. `false_positive` says the finding is wrong. `risk_accepted` says it is real and your team accepts it. The platform shows them as False positive and Accepted.
reason	Required. Why the finding does not fail the build.
paths	Optional. A list of paths in gitignore syntax, relative to the repository root. A dependency finding's path is its lockfile. Without `paths`, the entry applies to the whole repository.
expires	Optional. A date like `2026-12-31`. The entry applies through that day in UTC. After it, the scan prints a warning naming the entry and its findings count again.

Any other key, or an entry without a required field, makes the file invalid. An invalid file, a symbolic link, or a file larger than 1 MiB stops the scan with exit code 2 before anything is sent. The error names the entry and the field, and with --format json its code is invalid_ignore_file.

What an ignored finding looks like#

An ignored finding leaves the human report and never fails the build, and the report ends with a note saying how many findings the file ignored. The JSON and SARIF reports keep the finding and mark it:

--format json adds a suppressed object with the kind, the reason and expires when the entry has one.
--format sarif adds a suppressions entry with kind external, status accepted and the reason as justification, and ignoreKind and expires in its properties.

The coding agent hook and the editor extension leave ignored findings out too.

Triage on the platform#

On the Findings page, open a finding and choose Triage finding to set its status. Members, admins and owners can triage. False positive, Accepted and Ignored need a reason, and every change appears in the finding's Triage history.

A finding someone marked False positive, Accepted or Ignored stops failing the build on every branch of the project, and the pull request check skips it too. The report prints after the upload, tags each of these findings as triaged on the platform and ends with how many there were. The scan exits 0 when those were the only findings left. With --no-upload, or when the upload fails, only the ignore file applies. With --format json or --format sarif, the count goes to stderr.

When the file and triage meet#

Uploads carry ignored findings too. The platform sets each one to False positive or Accepted by its kind, and the Triage history shows the entry's reason.
When the entry is removed or expires, the next upload that reports the finding reopens it.
A status a person set on the platform wins: the file never changes it.
While an entry applies, the file wins over a person who reopens its finding, and the next scan sets the status from the file again. To reopen the finding for good, remove the entry or let it expire.

What fails the build#

Finding	Human report and build
Open, at or above `--fail-on`	Shown, and fails the build with exit code 1.
Open, below `--fail-on`	Shown, with a closing note. Does not fail the build.
Covered by `.atmos-ignore.yaml`	Counted in a closing note. Does not fail the build.
False positive, Accepted or Ignored on the platform	Shown with a tag and counted in a closing note. Does not fail the build once the scan uploads.
Already in the baseline commit	Counted in a closing note. Does not fail the build.

The exit code is in the CLI reference, and CI and pull requests shows the gate in a CI job.

Skip files with .atmosignore#

.atmos-ignore.yaml keeps findings from failing the build, while .atmosignore keeps files out of the scan. It uses gitignore syntax, and a scan never reads a source file or a lockfile it matches. Like .gitignore, it can sit in any folder of the repository, and its patterns apply to that folder and the folders below it.