Classification Rules

Classification rules automatically organise and tag your artifacts as they're uploaded. Instead of manually categorising every SBOM, you can define patterns that apply consistent metadata across your organisation.

What Classification Rules Do

When you upload an SBOM or document, classification rules check the file against defined patterns. If a rule matches, it applies actions like:

  • Setting a category (e.g., "firmware", "backend", "frontend")
  • Adding tags (e.g., "production", "third-party")
  • Triggering compliance checks

This automation reduces manual work and ensures consistent organisation.

Creating a Rule

Go to Settings > Classification Rules (Admin access required) and click "Add Rule".

Rule Name

Give the rule a descriptive name like "Tag Production Builds" or "Categorise Mobile Components".

Match Pattern

Enter a pattern to match against. Patterns support regular expressions for flexibility.

Examples:

  • prod-.* matches any string starting with "prod-"
  • .*-backend-.* matches strings containing "-backend-"
  • v[0-9]+\.[0-9]+ matches version patterns like "v1.0", "v2.3"

Match Field

Choose what to match against:

Filename checks the uploaded file's name. Useful for naming conventions like "sbom-frontend-v1.json".

Product Name checks the product this artifact belongs to.

Version Number checks the version string.

Component Name checks component names within an SBOM (applies the rule to matching components).

Target Type

Specify what type of artifact this rule applies to:

  • SBOM for software bills of materials
  • HBOM for hardware bills of materials
  • VEX for VEX documents
  • Document for compliance documents
  • All applies to any artifact type

Actions

Set Category assigns a category value. Useful for grouping artifacts in views and exports.

Add Tags applies one or more tags. Enter comma-separated values like "production, customer-facing".

Options

Case Insensitive matches regardless of upper/lowercase. Enabled by default.

Stop on Match prevents further rules from processing this artifact. Use when you want exclusive rule behaviour.

Priority determines which rules run first. Higher priority rules are evaluated first. If multiple rules can match the same artifact, priority controls their order.

Policies vs Classification Rules

CRA Evidence has two rule systems:

Classification Rules (Settings > Classification Rules) are for metadata organisation. They add tags and categories. They don't block uploads or create violations.

Policies (Settings > Policies) are for compliance enforcement. They can warn or block based on license types, vulnerability thresholds, quality scores, or component blocklists.

Use classification rules to organise. Use policies to enforce standards.

Policy Types

If you need enforcement beyond classification, Policies support:

License Policies define which licenses are allowed, restricted, or blocked. Block uploads containing GPL if your products can't use copyleft licenses.

Vulnerability Policies set thresholds for acceptable vulnerabilities. Warn when uploading SBOMs with critical CVEs.

Quality Policies enforce minimum SBOM quality scores. Block uploads below a quality threshold.

Component Policies blocklist or allowlist specific components. Prevent use of known-problematic packages.

Viewing Rule Matches

After upload, check an artifact's detail page to see which rules matched. The metadata section shows applied categories and tags with the rule name that applied them.

Managing Rules

The rules list shows all your classification rules with status and match counts.

Toggle Active enables or disables a rule without deleting it. Useful for temporary suspension.

Edit lets you modify rule patterns or actions.

Delete permanently removes the rule. This doesn't affect artifacts already classified.

Example Rules

Tag All Production SBOMs

  • Name: Tag Production
  • Pattern: .*-prod.*|.*-production.*
  • Match Field: Filename
  • Target: SBOM
  • Actions: Add Tags: "production"

Categorise Backend Services

  • Name: Categorise Backend
  • Pattern: backend|api|server
  • Match Field: Product Name
  • Target: All
  • Actions: Set Category: "backend"

Identify Third-Party Components

  • Name: Tag Third-Party
  • Pattern: vendor|third-party|external
  • Match Field: Filename
  • Target: SBOM
  • Actions: Add Tags: "third-party, requires-review"

Best Practices

Start simple. Begin with a few high-value rules and add more as patterns emerge.

Use naming conventions. Rules work best when your team follows consistent naming. Document your conventions.

Test patterns. Use a regex tester to verify your patterns match what you expect before creating rules.

Review periodically. As your product structure evolves, update rules to match.

Don't over-engineer. Manual tagging is fine for edge cases. Rules are for common patterns.

Last updated February 27, 2026
Was this page helpful?
Thanks for your feedback!

Help us improve. What was missing or unclear?