Solutions · Fix vulnerabilities in bulk
Campaigns in Nullify's Security Program Management turn a class of findings into one objective, such as "eliminate leaked secrets", and work it to closure at a pace your developers can absorb.
Trusted by security teams at
The problem
The same vulnerability shows up across many repositories. The same outdated library sits in service after service. The same insecure pattern gets copied from one team to the next.
Handled one ticket at a time, each instance becomes its own task, its own context switch and its own conversation with a different developer. The backlog barely moves, and the root cause stays in place to produce the next batch.
And when a bulk fix does happen, it often lands as a wall of pull requests that developers learn to ignore.
In practice
Upgrade CVE-affected dependencies
Illustrative example. Campaign progress shows resolved versus remaining for each team.
Open fix pull requests, per repository
Illustrative example. Nullify keeps at most 3 open fix pull requests per repository and 5 per remediation plan.
The outcome
Campaigns are built from real findings around a goal like "upgrade CVE-affected dependencies".
Security leaders choose what's in the campaign and how much Nullify automates.
Nullify keeps at most 3 open fix PRs per repository and 5 per remediation plan, and assignment accounts for each person's open PRs and tickets.
Campaign reporting tracks resolved versus remaining, team by team.
How it works
Pick an objective and filter findings by type, CWE, CVE, repository, team, individual or severity. Campaigns can target code, dependency, secret and pentest findings.
Owners come from CODEOWNERS, commit history and service metadata, and work isn't moved across teams without approval. Where a code change resolves the issue, Autofix opens a minimal, build-validated fix in GitHub or GitLab, within the PR caps.
Developers review and merge. Stalled PRs and tickets are escalated in Slack with the risk and SLA stated, and campaign progress shows resolved versus remaining for each team.
The product
FAQ
It's an objective-driven piece of work built from real findings, such as "eliminate leaked secrets" or "upgrade CVE-affected dependencies". Security leaders set the scope and how much Nullify automates, and Nullify works it through to closure.
Nullify keeps no more than 3 open fix PRs per repository and 5 per remediation plan at a time. It also takes each person's open PRs and tickets into account when assigning work.
Code, dependency, secret and pentest findings, filtered by type, CWE, CVE, repository, team, individual or severity.
Yes. Every fix arrives as a pull request with a merge-ready patch, and developers review and approve it in their normal code review. Nullify never auto-merges.
See how Nullify plans and runs a remediation campaign across your repositories.
