Reading findings

A finding is a single problem FossID reports. For example: a file contains code under a license your policy prohibits, or a dependency has a known vulnerability.

Where findings appear

Problems panel. Every finding is listed under the source FossID. Findings from a custom scan volume are listed under FossID · <volume name>.

• Errors are problems your policy says must be fixed: a prohibited license, or a known vulnerability.
• Warnings need a decision: a conditional license, or a modified license text.

In the editor:

• Squiggles under the matching code. A finding about the whole file (for example, the whole file matches an open-source component) sits at the very start of the file without underlining anything.
• Modified license text is highlighted. Added and changed wording gets a yellow wavy underline. Text that was removed from the standard license is shown as red, struck-through ghost text where it would have been.
• Hovering over a squiggle shows the finding and the Explain with FossID and Fix with FossID actions.

In dependency manifests, each declared dependency gets a short annotation at the end of its line:

Annotation	Meaning
→ 4.17.21 ✓ (green)	Resolved version; no problems in it or anything it depends on.
→ 6.4.4, ⚠ 1 CVE (HIGH) (red)	The dependency has a known vulnerability. (HIGH, via ws) means the vulnerability is in one of its own dependencies.
🚫 GPL-3.0-only (via leaf) (red)	A license your policy prohibits, in this dependency or one of its dependencies.
⚠ MPL-2.0 (conditional) (yellow)	A license your policy marks as conditional.

While a manifest is being rescanned, its annotations are dimmed and start with ↻. Annotations disappear as you type and come back after you save.

Following a finding to its source

The code column of a finding in the Problems panel often shows source ↗. Click it to open the most precise source FossID knows. Depending on the finding, that is:

• the matching lines in the upstream repository (GitHub or GitLab);
• the component's page in its package registry (npm, crates.io, PyPI);
• the component's homepage;
• the vulnerability's entry in the National Vulnerability Database (NVD);
• the license's page on spdx.org.

Expand a finding in the Problems panel to see related information: other places in the same file with the same match, clauses that were added, removed or replaced in a license text, or the other vulnerabilities and licenses of a dependency. Click an entry to jump to it.

What each kind of finding means

Each finding comes from a detection rule. The rule's ID is shown as the finding's code when there is no source link. You can turn each rule on or off; see Detection rules.

Prohibited license — fossid/prohibited-license

Error. The file contains code, or a license text, under a license your policy prohibits. For example:

• Prohibited license: GPL-3.0-only (inherited from <component> v<version>) — <policy reason>: the code matches an open-source component under that license.
• Prohibited license in this file: GPL-3.0-only: the file itself carries that license text.
• Prohibited weak copyleft license: …: your policy prohibits the whole license category.

When copied code carries a license, FossID uses the strictest one that applies. A permissive license header in your own file doesn't hide a GPL snippet copied into it.

Requires a license policy.

Conditional license — fossid/conditional-license

Warning. As above, but your policy marks the license as warn: allowed under conditions you need to check.

Requires a license policy.

Modified license text — fossid/modified-license-text

Warning. A license text in the file differs from the standard (SPDX) wording by more than the threshold, 5% by default. For example: Modified license: MIT (12% modified, 1 added, 2 changed).

Changes that touch only copyright lines (names and years) never count. You can change the threshold in Detection rules.

Vulnerable snippet — fossid/vulnerability-snippet

Error. A piece of code in the file matches upstream code with a known vulnerability. There is one finding per vulnerability. For example: Vulnerable snippet: CVE-2024-12345 — CRITICAL (CVSS 9.8) — <description>.

Vulnerable dependency — fossid/vulnerable-dependency

Error, on the dependency's line in a manifest. The resolved version of the dependency, or of something it pulls in, has a known vulnerability. For example:

• lodash v4.17.15 — CVE-2020-8203 — HIGH (CVSS 7.4)
• express v4.17.1 — CVE-… — HIGH via root → … → qs v6.7.0 (transitive, depth 3)

When a dependency has several vulnerabilities, you get one finding with the worst one first, and (+N more — expand for full list). Each vulnerability can still be ignored on its own.

Dev dependencies are skipped by default; see Dev dependencies.

License policy in dependencies — fossid/policy-license-dependency

On the dependency's line in a manifest. The dependency, or something it pulls in, is under a license your policy flags. It shows as an error if any of its licenses is prohibited, and a warning if they are only conditional. For example: Prohibited license: GPL-3.0-only in <dependency> v<version> — <reason>.

Requires a license policy. Dev dependencies are skipped by default.

Known vulnerabilities in a matched component — fossid/cve-in-matched-component

Error. A whole file matches a bundled or vendored open-source component, and that component has known vulnerabilities. For example: ⚠️ 3 known vulnerabilities — <component> v<version> (<license>).

This is the least certain vulnerability finding: FossID can't confirm that your copy is the affected version. It can't be ignored per finding. If it's too noisy, turn off CVEs in Matched Components in Detection rules.

Custom volume match — fossid/custom-volume-match

The code matches something on one of your organization's custom scan volumes. For example: Matches <component> <version> as <path> in custom volume "<name>" (score N). The severity is set per volume.

Several matches of the same component

Popular projects are often mirrored many times. When a file matches several copies of the same project under the same license, FossID shows one finding, for the best match, instead of one per copy.

How findings go away

• You fix the problem. When you save, FossID rescans the file and removes findings that no longer apply.
• You accept it. Ignore the finding with a reason and an expiry date. Ignored findings are hidden everywhere, including manifest annotations.
• You exclude the file. Exclude it from scanning.
• You change the rules. Changing the policy or turning off a rule updates all findings right away.

Findings your AI assistant adds to the Problems panel can carry their own check. For example, "this license header is gone" or "this tool now returns nothing". When you save, FossID runs the check and removes the finding if it passes.