aikido ignore: ignore a finding with a .aikido file, by path, by CVE, or by rule

TL;DR

An aikido ignore is how you tell Aikido Security to stop reporting a finding you have reviewed and accepted. The code-based route is a .aikido file at your repository root: use it to exclude paths (the exclude/paths key hides files from secrets, SAST, lockfile, code-quality, and Deep Review scans) and to ignore specific CVEs with a written reason, which the Aikido UI then shows next to the ignored CVE. Path matching is simple string inclusion, not globs: if the literal value you write appears anywhere in the full file path, the file is excluded, and wildcards or regular expressions are not supported.

Use this when

• An Aikido finding is a false positive or an accepted risk and you want it ignored in code, reviewable in version control
• Your .aikido exclude paths are not matching the files you expected
• You need to ignore a specific CVE for one repository and record why

Not for this skill when

• The finding is a real, reachable vulnerability: fix it instead of ignoring it
• You need to choose the narrowest ignore scope (this issue vs by path vs by CVE vs by rule): see the ignore scopes skill in Related skills
• You are ignoring a single pull-request finding via a PR reply, including the 400 feature-disabled error: see the PR ignore skill in Related skills

Steps

1. Decide the scope before you write anything. Ignore the smallest thing that covers the problem: one path or one CVE in this repository beats a broad pattern. Every ignore should carry a reason a reviewer can judge later.

Expected: you know exactly which finding, path, or CVE you are ignoring, and why.

2. Create or edit the .aikido file at the repository root. Add your excluded paths as literal substrings of the full file paths, not glob patterns.

Expected: the file sits at the repo root; each entry is a plain path fragment like a folder name or a generated-file path, with no wildcard characters.

3. To ignore a CVE instead of a path, record the CVE in the same .aikido file together with your reason.

Expected: the Aikido UI shows the CVE as ignored with your reason next to it, so the decision is visible to the whole team.

4. Commit the .aikido file and let Aikido rescan.

Expected: the excluded files no longer appear in secrets, SAST, lockfile, code-quality, or Deep Review results, and the ignored CVE stops being reported for this repository.

5. If an exclude entry did not take effect, check the spelling against the full path first. Matching is string inclusion, so an entry works only if it appears verbatim somewhere in the path Aikido reports; a pattern that looks right as a glob silently matches nothing.

Expected: after correcting the entry to a literal substring, the rescan drops the file.

Variant phrasings

.aikido exclude paths not matching

The troubleshooting form of this query. The cause is almost always a glob or regex habit: Aikido matches by string inclusion, so rewrite the entry as a literal substring of the full path (step 5).

aikido ignore cve

The CVE form: record the CVE in the .aikido file with a reason (step 3). The reason is not optional bookkeeping; it is what the UI shows and what a later reviewer audits.

aikido ignore file

The file itself is the mechanism: one .aikido file at the repository root carries both path exclusions and CVE ignores for that repository.

Root cause

Aikido's code-based ignores are deliberately simple: the .aikido file is parsed as literal configuration, and path matching is substring inclusion over the full file path. There is no glob engine and no regex engine, so patterns imported from other tools (gitignore-style or linter-style) fail silently instead of erroring, which is why excludes so often look correct and do nothing.

Edge cases

• The .aikido file must live at the repository root; one placed in a subfolder is not picked up for the repo-wide scans.
• An ignored CVE with no reason is a future audit problem: write the reason when you add the ignore.
• Broad substrings exclude more than you intend (a short folder name can appear in many paths); use the longest distinctive fragment that still matches.
• Ignoring hides the finding from the listed scan types; it does not change the code, so re-check ignores when dependencies or code layout change.

Tool compatibility

Aikido Security code scanning (secrets, SAST, lockfile, code quality, Deep Review) with .aikido files as documented in the Aikido help pages linked in the evidence.

Related skills

• Aikido ignore scopes: this issue vs by path vs by CVE vs by rule: https://vectle.com/skills/skl_T4dgUYBdk7Go3wyxdsfMhQ
• Ignoring an Aikido PR finding via an @AikidoSec ignore reply, and the 400 feature-disabled error: https://vectle.com/skills/sklGEAo-Z4RPQxQsOsTMCZhQ

Provenance

Built from Aikido's documentation on ignoring via code with .aikido files, linked in the evidence.

Source: Problem: Exclusions in the .aikido file do not match the files you expected. Path matching in .aikido is simple string inclusion: if the configured value appears anywhere in the full file path, the file is excluded. Wildcards and regular expressions are not supported. Place the .aikido file in the repository root. The exclude/paths key hides files from secrets, SAST, lockfile, code-quality and Deep Review scans. The same file can also ignore specific CVEs with a reason, which the Aikido UI then shows next to the ignored CVE.

Verified resolution: Per Aikido docs: use literal path substrings in .aikido (no wildcards or regex) and record CVE ignores with a reason.

Source URL: https://help.aikido.dev/code-scanning/scanning-practices/ignore-via-code-with-aikido-files.md