Skip to main content

Ignoring findings

Sometimes a finding is correct but acceptable. Your compliance team may have cleared a license for this use, or a vulnerable code path may never run in your product. In those cases you ignore the finding.

An ignore is a documented exception:

  • it always has a reason;
  • it always has an expiry date, after which the finding comes back;
  • vulnerability ignores record a VEX analysis (Vulnerability Exploitability eXchange, the industry standard for stating why a vulnerability does or doesn't affect you).

Ignores are stored in .fossid/ignores.yaml in your workspace folder. Commit the file so your whole team shares the same decisions, and use Governance to require review of changes.

Ignore or exclude? Ignoring hides one specific finding for a limited time. Excluding a file stops FossID scanning it at all, permanently. Prefer ignoring. It keeps a record of what you accepted and why.

Ignoring a finding from the editor​

Put the cursor on the finding and press Ctrl+. (Cmd+. on macOS), or right-click the finding in the Problems panel. Choose Ignore: <kind> <identifier>…, for example Ignore: license GPL-3.0-only….

If a finding has more than one identity, you get one action per identity. For example, a license found through a copied snippet offers both Ignore: license … and Ignore: snippet ….

FossID then asks for the details.

For a license, snippet or component finding:

  1. Why is it ignored? A reason is required. For example: Cleared by OSPO exception, see OSPO-142.
  2. How many days until this ignore expires? Choose 30 days (default), 90 days, 1 year, or Custom number of days….

For a vulnerability:

  1. VEX state: how the vulnerability relates to your project:
    • not_affected: your project is not affected;
    • false_positive: the finding is wrong;
    • in_triage: you are still investigating;
    • or Skip — record rationale only.
  2. Justification (required for not_affected): why you are not affected. For example code_not_reachable, code_not_present, requires_configuration or protected_at_runtime.
  3. Planned response(s) (optional, multi-select): can_not_fix, will_not_fix, update, rollback, workaround_available.
  4. Why is this vulnerability acceptable? A rationale is required.
  5. Expiry. For in_triage, 7 days is suggested.

Press Esc at any step to cancel without writing anything.

When the ignore is saved, FossID confirms with ignored <kind> <id> until <date>. and offers Open ignores.yaml. The finding disappears immediately.

Ignoring more broadly: Ignore a Finding…​

FossID: Ignore a Finding… in the Command Palette does the same, but lets you widen the ignore:

  1. Select a finding to ignore. The list shows findings in the active file, or in the whole workspace if no file is open.
  2. Path scope: This file, This folder and everything under it, or Anywhere in the repo.
  3. Kind scope: This kind only or Any kind.
  4. Identifier scope: This one (for example this CVE) or Any of that kind.

Each option shows how many current findings it would cover. Then you enter the reason and expiry as above.

Managing ignores: the Ignores editor​

Open the FossID side bar and select Manage Ignores in the Ignores view.

The Ignores tab lists every active ignore, grouped into Vulnerabilities, Licenses, Snippets, and Wildcards & other. Use the Filter box to search by identifier, path, kind or VEX state.

For each ignore you can:

  • Edit the rationale in place. Press Enter or click away to save, or Esc to undo. The rationale can't be empty.
  • Change the expiry by entering a number of days from today (1 to 36500). Hover to see the exact expiry and creation dates.
  • See what it covers. Suppresses shows how many findings it currently hides.
  • Edit the VEX analysis of a vulnerability. Expand the row to change VEX State, Justification and Response.
  • Reveal in ignores.yaml or Remove ignore from the ⋯ menu. Removing takes effect immediately and the findings reappear.

Expired ignores (N) opens a second tab with lapsed ignores. Renew one by giving it a new number of days, or remove it.

How ignores behave​

  • Expiry. An ignore applies up to and including its expiry date (UTC). The finding comes back at the next UTC midnight, even if the editor is idle.
  • Any match hides the finding. If any active ignore covers a finding, it is hidden. There is no priority between ignores.
  • Dependencies with several problems. Ignoring one vulnerability or license of a dependency leaves its other vulnerabilities and licenses visible.
  • Hidden everywhere. Ignored findings disappear from the Problems panel, from the editor, and from manifest annotations.
  • Not ignorable: known vulnerabilities in a matched component can't be ignored individually. Turn the rule off in Detection rules if needed.

The ignores file​

You can also edit .fossid/ignores.yaml by hand. Changes take effect as soon as you save, and after a git checkout or pull.

version: 1
ignores:
  - finding: '**:license:LGPL-2.1-only'
    reason: 'Cleared by OSPO exception, see OSPO-142.'
    expires: 2026-12-31
    created: 2026-09-28

  - finding: 'src/vendor/parser.c:vuln:CVE-2024-12345'
    analysis:
      state: 'not_affected'
      justification: 'code_not_reachable'
      response: ['will_not_fix']
      detail: 'The vulnerable code path is compiled out of our build.'
    expires: 2026-10-28
    created: 2026-09-28
FieldRequiredMeaning
findingyesWhat the ignore covers, as path:kind:identifier (see below).
reasonfor license, snippet and component entriesWhy the finding is acceptable.
analysisfor vulnerability entriesThe VEX analysis: state, justification (required when state is not_affected), response (list) and detail (required: the rationale).
expiresyesLast day the ignore applies, as YYYY-MM-DD (UTC).
creatednoDate the ignore was added. FossID fills it in.

The finding key has three parts, separated by colons:

  • path: a file, folder or pattern using .gitignore syntax, relative to the workspace folder. For example src/vendor/parser.c, src/vendor/**, or ** for anywhere.

  • kind: license, vuln, snippet, component, or * for any kind.

  • identifier:

    • an SPDX license ID for license;
    • a CVE ID for vuln;
    • a snippet ID for snippet;
    • name@version for component;
    • or *.

    You can use * as a wildcard inside a value, for example CVE-2024-*.

VEX values:

  • state: not_affected, false_positive, in_triage, exploitable, resolved, resolved_with_pedigree.
  • justification: code_not_present, code_not_reachable, requires_configuration, requires_dependency, requires_environment, protected_by_compiler, protected_at_runtime, protected_at_perimeter, protected_by_mitigating_control.
  • response: can_not_fix, will_not_fix, update, rollback, workaround_available.

Wildcard entries get a Suppresses N finding(s) line above them in the editor, so you can see how much they cover.

Tip: Install the YAML extension by Red Hat to get completion and hover help for ignores.yaml, based on the schema FossID ships.

When FossID writes the file, it sorts the entries and uses a consistent layout, so reviews and git blame stay clean. Comments you add by hand are not kept when FossID next writes the file.

When the ignores file has problems​

FossID checks ignores.yaml as you type and reports problems in the Problems panel:

ProblemSeverityEffect
Broken file: invalid YAML, merge-conflict markers, or a wrong versionErrorNo ignores apply until the file is fixed. Every finding is shown.
Unrecognized content: unknown fields, or missing required fieldsErrorEntries that are otherwise valid still apply, but FossID won't edit the file until you fix it. Editing it would drop what it doesn't recognize.
Ineffective value: an invalid date, a malformed finding key, a duplicate entry, or an unknown VEX valueWarningThat entry just never applies.

FossID also notifies you once when the file becomes broken or unrecognized, with Open File.

If you try to add an ignore while the file is broken, or has unsaved changes open in an editor, FossID writes nothing and tells you what to fix first.

Merge conflicts​

Two branches often add ignores at the same time. When ignores.yaml has merge conflicts, FossID offers to resolve them for you:

  • from the notification (Resolve Automatically);
  • from the banner in the Ignores editor (Resolve automatically);
  • from the Quick Fix on the conflict marker: FossID: resolve merge conflict (merge both sides).

FossID keeps every ignore from both sides. When both sides changed the same entry, it keeps the one with the later expiry. It first shows you a preview of the merged file and a summary, then asks you to Apply. The result is a normal edit, so you can undo it.