General Configuration

Overview

Once installed, Nullify immediately starts assessing pull requests and creating findings for new risks. The defaults get most teams moving quickly, but you can tailor behaviour through configuration files.

Global Configuration

Create a .nullify.yml in your organisation-level configuration repository to define shared policy. Depending on your platform this repository is:

• GitHub: .github-private

• Bitbucket: .bitbucket-private

• Azure DevOps: .azure-private

The repository should remain private and accessible to the Nullify app. GitHub uses the same mechanism for organisation-wide issue and pull-request templates, so existing practices apply.

Repository Configuration

Add a .nullify.yml to individual repositories when you need to override the global defaults. Settings cascade as follows: built-in defaults → organisation file → repository file.

The merge logic lives in config-file-parser if you want to review precedence rules.

Fail Builds

Control whether Nullify can fail CI when a new finding exceeds your policy:

enable_fail_builds: true

Severity Threshold

Limit surfaced findings by severity (critical, high, medium, low):

severity_threshold: high

Priority Threshold

Filter findings by Nullify’s priority classification (urgent, important, informational):

priority_threshold: urgent

Ignore Directories

Exclude directories from assessment:

ignore_dirs: ["data"]

Ignore Paths

Use glob patterns to skip specific files:

ignore_paths: ["tests/**", "**/*.py"]