Security Config Files

The QGIS Plugins security scanner supports standard configuration files that allow you to fine-tune how Bandit, detect-secrets, and Flake8 behave when scanning your plugin. By including these files in your plugin ZIP you can suppress known false positives without having to skip entire rules.

Tip: Config files are the recommended approach for addressing persistent false positives in non-skippable rules. They provide a transparent, versioned record of intentional suppressions directly inside your plugin package.

Effect on Validation Status

When the scanner detects one or more recognised config files in your plugin ZIP, the version receives a Validated (configured) status instead of the plain Validated status:

  • Validated (configured) — All checks passed and at least one security config file was found. The version is fully available for approval; trusted users are auto-approved exactly as they would be with a plain Validated status.
  • The distinct status makes it easy for administrators to identify versions where scans were influenced by developer-supplied config.
  • Config files do not lower the bar for passing — critical issues still block the plugin. They only affect which findings are reported by the underlying tools.
Supported Config Files

Place any of the following files at the top level of your plugin ZIP (next to your plugin's metadata.txt). The scanner will automatically detect and use them.

File Tool Purpose
.bandit Bandit Skip specific Bandit test IDs or exclude paths from the Bandit scan
.secrets.baseline detect-secrets Baseline file listing known/accepted secrets so they are not re-reported
.flake8 Flake8 Ignore specific Flake8 error codes or configure per-file ignores
Per-Tool Configuration Examples
Bandit — .bandit

Create a .bandit INI file at the root of your plugin. Use skips to list test IDs that should be ignored and exclude_dirs to omit vendored or test directories entirely.

[bandit]
# Ignore XML-related warnings — XML usage has been audited and is safe
skips = B405,B314,B318

# Do not scan vendored libraries or test fixtures
exclude_dirs = vendor,tests/fixtures

Full list of Bandit test IDs: bandit.readthedocs.io

detect-secrets — .secrets.baseline

Generate a baseline file locally that captures all accepted findings. The scanner will compare new scan results against this baseline and ignore anything already listed.

# Generate the baseline from your plugin directory
detect-secrets scan your_plugin_directory/ > .secrets.baseline

# Review the file to ensure only intentional/non-sensitive entries are listed
# then add it to your plugin ZIP alongside metadata.txt

Any finding present in the baseline is treated as an accepted known value and is not reported as a new issue. Findings that are absent from the baseline are still reported normally.

detect-secrets documentation: github.com/Yelp/detect-secrets

Flake8 — .flake8

Create a .flake8 INI file to extend the list of ignored error codes or apply per-file ignores.

[flake8]
# Ignore line-length and unused-import warnings project-wide
extend-ignore = E501, F401

# Per-file ignores for generated or vendored code
per-file-ignores =
    vendor/*.py: E501,F401,F811
    *_generated.py: E501

Full Flake8 configuration reference: flake8.pycqa.org

Including Config Files in Your Plugin ZIP

The config files must be at the root of the plugin directory inside the ZIP (i.e. the same level as metadata.txt and __init__.py).

myplugin.zip
└── myplugin/
    ├── metadata.txt
    ├── __init__.py
    ├── myplugin.py
    ├── .bandit          ← recognised
    ├── .flake8          ← recognised
    └── .secrets.baseline← recognised

Files nested deeper in subdirectories are not detected. Make sure your build or packaging script includes dotfiles — some tools exclude hidden files by default.

Note — Future restrictions: Currently config files are accepted for all plugins without restriction. Future policy changes may limit which rules can be suppressed via config, particularly for non-skippable critical rules. The resulting Validated (configured) status already provides administrators with visibility into which versions rely on config-based suppression so that policy can be enforced retroactively if needed.