Every custom static analysis rule should have a named owner, normally the team that owns the code or API it protects, with security reviewing the intent. Rules live in a version controlled repository, change through pull requests, and carry a review date. Without that, rules turn into orphaned code that blocks builds.
Why ownership is the real problem
Writing a rule is easy. The trouble starts when a developer sees a failing build, asks who wrote the rule, and nobody knows. That is how rules get disabled in frustration, with no record. ESLint's own site has pages for proposing new rules and for how the project is maintained, which shows rules are treated as maintained software. Your internal rules deserve a lighter version of the same.
Roles
| Role | Responsibility |
|---|---|
| Rule owner | Answers questions, triages false positive reports, keeps tests green |
| Rule reviewer | Approves changes, usually a second engineer |
| Security reviewer | Confirms the rule matches the intended risk |
| Platform or tooling team | Runs the shared rules package and the CI integration |
| Consumers | Report problems with the rule id |
In a small team one person may hold several roles. What matters is that the names are written down.
What lives where
- A rules repository or package. Rules, tests, and documentation together. Analyzers in some ecosystems are published as packages, so projects can install a specific version.
- A CODEOWNERS style file. Maps each rule to its owner for review requests.
- A one page README per rule. Intent, example of bad and good code, how to fix, how to suppress, owner and next review date.
- A changelog. A line per change, so developers can see why behavior shifted.
Versioning
Pin rule packages by version in each project, so a rule change does not appear as a surprise build failure on an unrelated pull request. Upgrade on purpose, and read the changelog. Microsoft's documentation notes that an analyzer installed as a NuGet package applies only to the project that installs it, which makes the version a project level decision.
Change process
- Open a pull request with the rule change and the new test.
- The owner and one reviewer approve.
- Release a new version with a changelog entry.
- Roll it out as warn first if the change widens what is reported.
When the owner leaves
Treat it like any other handover. Reassign every rule the person owned within their notice period. A rule with a departed owner and no new name should move to warn, then be reviewed for retirement.
Quick check
Should security own all custom rules?
Usually not. Security should review intent, but the team that owns the protected code knows its usage and can answer false positive reports faster.
Do small teams need this much process?
A lighter version is enough: a name, a README and a review date for each rule, kept in the repository.
Safeguard's scanning covers dependencies and SBOMs, and its reachability analysis helps show which findings your code can actually call. You can run a free scan on a repository.
Sources
Last reviewed: 19 October 2026.
