Detection rules

Detection rules decide which kinds of findings FossID reports. Every rule is on by default. Turn off the ones that don't matter for your project.

The Detection Rules editor

Open the FossID side bar and select Detection Rules in the Policies view, or run FossID: Open Detection Rules.

Switch	What it controls	Default
License Findings	Prohibited and conditional license findings in source files, based on your license policy.	On
License Modifications	Modified license text findings. Also sets Detect when modified more than N %.	On, 5%
CVEs in Matched Components	Known vulnerabilities of whole components matched in your files. This is the lowest-confidence vulnerability rule: turn it off to cut component-level noise while keeping snippet and dependency vulnerabilities.	On
Vulnerability Snippet Finder (VSF)	Code snippets that match known-vulnerable upstream code.	On
Vulnerable Dependencies	Known vulnerabilities in the resolved versions of declared dependencies, direct or transitive.	On
License Policy in Dependencies	Dependencies under licenses your policy flags.	On
Include Dev Dependencies	Whether dev dependencies are checked. See Dev dependencies.	Off

The editor also holds your custom scan volumes.

Changes take effect immediately. Existing findings are re-evaluated without rescanning. See Reading findings for what each rule reports.

Dev dependencies

Dev dependencies usually don't ship in your product, so by default FossID doesn't report vulnerabilities or policy-flagged licenses for them. The same goes for everything they pull in.

Under Include Dev Dependencies you can turn them on separately for:

• Vulnerabilities (Vulnerable Dependencies rule);
• Policy-flagged licenses (License Policy in Dependencies rule).

The parent checkbox turns both on or off together. It shows a mixed state when they differ.

A dependency counts as a dev dependency when it is declared only in one of these sections:

Manifest	Dev section
package.json	devDependencies
Cargo.toml	[dev-dependencies]
pom.xml	<scope>test</scope>
Pipfile	[dev-packages]
pyproject.toml	[tool.poetry.dev-dependencies]

A dependency declared in both a production section and a dev section counts as production. go.mod, NuGet projects and requirements.txt have no section that reliably means "dev only", so their dependencies always count as production.

Where the settings are stored

The Detection Rules editor saves to the settings section of .fossid/policy.json in your workspace. The settings are committed with your code and shared with your team:

{
  "version": 1,
  "policy": [ … ],
  "settings": {
    "licenses": {
      "prohibited_license": true,
      "conditional_license": true,
      "modified_license_text": true,
      "modified_license_threshold": 0.05,
      "policy_license_dependency": true,
      "policy_license_dependency_include_dev": false
    },
    "vulnerabilities": {
      "cve_in_component": true,
      "vuln_snippet": true,
      "vulnerable_dependency": true,
      "vulnerable_dependency_include_dev": false
    }
  }
}

In the file, modified_license_threshold is a fraction: 0.05 means 5%.

Each rule also has a VS Code setting, fossid.detectionRules.* (see Settings). For each value, FossID uses:

1. the value in .fossid/policy.json, if there is one;
2. otherwise, the VS Code setting;
3. otherwise, the default.

Important: The editor always writes all values to .fossid/policy.json. Saving from the License Policies editor does the same. After the first save, the file overrides your VS Code settings for every rule. To go back to using a VS Code setting, remove that key from the file.

If no folder is open, the editor saves to your user settings instead.