Policy Rule Categories¶

Policy Rule Categories define the type of security findings a policy rule applies to. They establish the scope of evaluation by grouping findings based on their security domain, source, or operational context.

What Are Policy Rule Categories?¶

A policy rule category represents a class of findings produced by Boost Security scanners and integrations.

Each category groups findings that share:

A common security domain (for example, code, dependencies, infrastructure)
Similar risk characteristics
A consistent set of attributes that can be evaluated by policy actions

In simple terms, a policy rule category answers the question:

Question

What kind of security findings does this rule apply to?

Why Policy Rule Categories Matter¶

Policy rule categories provide structure and predictability to policy enforcement.

For users, categories make policies easier to reason about.

How Categories Fit Into the Policy Model¶

Policy rules in Boost Security follow a layered evaluation model:

Policy – A collection of rules and a default action
Rule Category – Defines which findings are in scope
Policy Actions – Apply conditions to those findings
Response – Determines what happens when conditions are met

You can think of categories as the outer boundary of a rule.

Categories vs Rules vs Actions¶

It’s important to distinguish between these closely related concepts:

Concept	Purpose
Policy Rule Category	Defines which type of findings are evaluated
Policy Rule	Groups a category, actions, and a response
Policy Actions	Define conditions under which the rule applies
Response	Defines what happens when the rule triggers

A category does not enforce behavior by itself; it only defines scope.

Common Policy Rule Categories¶

Policy rule categories generally align with the security domain in which a finding exists. Examples include:

Static Application Security Testing (SAST) - Findings related to vulnerabilities in application source code.
Software Composition Analysis (SCA) - Findings related to third-party and open-source dependencies.
Secrets - Findings related to exposed credentials, tokens, or keys.
Infrastructure as Code (IaC) - Findings related to insecure cloud or infrastructure configurations.
Kubernetes - Findings related to cluster, service, or workload security.
Repository & Asset Metadata - Findings derived from repository configuration, visibility, labels, or flags.

Mapping Policy Rule Categories to Supported Actions¶

Each policy rule category exposes only the actions that are semantically and technically relevant to the type of findings it evaluates.

This design ensures rules remain valid, predictable, and aligned with the underlying security data.