A rule catalogue is the set of checks a scanner applies to code. Different catalogues can target different control objectives, such as security vulnerabilities or maintainability issues, even when the underlying parsing and file discovery layers are shared.
Expanded Definition
A rule catalogue is the curated set of detection rules, checks, and evaluation logic that a scanner uses to decide whether source code, configuration, or build artefacts match a given policy objective. In practice, the parsing engine, file discovery logic, and reporting pipeline may stay the same while the catalogue changes what gets flagged. That is why teams may use one catalogue for security findings and a different one for code quality or maintainability. The term is common in static analysis, software composition review, and broader DevSecOps workflows, but its meaning can vary across vendors because some products bundle rules with severity scoring, metadata, and remediation guidance while others separate those functions.
For security work, the important distinction is that the catalogue is not the scanner itself. It is the policy layer that expresses what “bad” looks like for a particular objective, whether that objective is vulnerable code patterns, insecure dependency usage, or weak configuration. NIST Cybersecurity Framework 2.0 is useful here because it frames governance outcomes, while the catalogue provides the concrete checks that help operationalise those outcomes. The most common misapplication is treating every catalogue as interchangeable, which occurs when teams assume a vulnerability catalogue will also cover compliance, secret detection, or code maintainability without verifying scope.
Examples and Use Cases
Implementing rule catalogues rigorously often introduces a tuning burden, requiring organisations to weigh broader detection coverage against false positives, review effort, and developer friction.
- A secure coding catalogue flags hardcoded secrets, unsafe deserialisation, and injection-prone patterns during pull request scans.
- A compliance catalogue checks for missing license headers, required logging controls, or prohibited cryptographic settings in build pipelines.
- A dependency-focused catalogue identifies known vulnerable package versions and deprecated libraries before release approval.
- A maintainability catalogue highlights dead code, duplicated logic, and complexity thresholds that make secure changes harder to review.
- A platform team may keep a shared scanner but swap catalogues per repository, so product teams inherit the same parsing layer while applying different control objectives.
These examples are often implemented alongside guidance from the NIST Cybersecurity Framework 2.0, which helps teams align technical checks with broader risk management goals. The catalogue itself should be versioned and reviewed like any other control artifact, because rule changes can alter what is detected, ignored, or escalated. In mature environments, catalogue updates are treated as governed changes rather than informal tuning.
Why It Matters for Security Teams
Rule catalogues determine what security tooling actually sees, which means weak catalogue governance can create blind spots even when the scanner platform is sound. If the catalogue is too narrow, teams miss real exposures. If it is too broad or poorly maintained, analysts drown in noise and start ignoring findings. That pattern matters for identity-heavy systems as well, where code may embed secrets, access logic, API integrations, or agentic workflows that deserve specialised checks. For example, a catalogue for non-human identity controls may need to recognise token handling errors, overprivileged service accounts, or unsafe secret storage, not just generic code smells.
Security teams also need to distinguish between policy intent and rule implementation. A catalogue may claim to enforce a control objective, but the actual check could be too shallow to support that claim. This is why catalogues should be mapped to internal risk requirements, tested against representative code, and reviewed whenever new frameworks, languages, or deployment patterns are introduced. Where catalogue definitions are vendor-specific, organisations should document the scope explicitly rather than assuming consistency across tools. Teams usually discover the cost of a poor catalogue only after a breach, a failed audit, or a release that shipped hidden defects, at which point the catalogue becomes operationally unavoidable to fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | CSF 2.0 frames governance outcomes that rule catalogues help operationalise. |
| NIST SP 800-53 Rev 5 | SI-2 | Configuration and vulnerability management controls often depend on scanner rules. |
| ISO/IEC 27001:2022 | A.8.28 | Secure coding guidance aligns with rule catalogues used to detect unsafe code patterns. |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant where catalogues detect token, secret, or service-account misuse. | |
| NIST AI RMF | AI RMF applies when catalogues assess AI or code used in automated decision systems. |
Map catalogue rules to governance objectives and review whether each rule supports a documented risk outcome.
Related resources from NHI Mgmt Group
- What is the difference between behavioural analytics and traditional rule-based monitoring?
- Why does the 72-hour breach reporting rule matter for IAM and security teams?
- Why do tenant-scoped roles work better than one global role catalogue?
- How should security teams govern bulk sensitive data transfers under the DOJ rule?
