Custom Detection Rules

In addition to 200+ built-in detection patterns, Radar supports custom rules for organization-specific credentials, proprietary tokens, and custom authentication schemes.

Enterprise Feature

Custom detection rules are available exclusively on the Enterprise plan. Contact ByteHide support for details.

When to Use Custom Rules

Scenario	Example
Internal authentication tokens	Tokens prefixed with your company name or a specific identifier for microservices
Proprietary API keys	Custom-format keys with recognizable prefixes, specific lengths, or particular character sets
Internal database connections	Connection strings using internal hostnames or domain conventions
Configuration policy enforcement	Internal service URLs, internal IP addresses, or environment-specific endpoints that should not be hardcoded

Rule Configuration

Navigate to Settings > Custom Detection Rules > Add Rule in your Radar project.

Each rule includes:

Name: descriptive label that appears in finding titles (e.g., "Internal API Token")
Pattern: regular expression matching the credential format
Severity: Critical, High, Medium, or Low
Description: optional explanation displayed in the finding detail panel
Enabled: toggle to activate/deactivate without deleting

Pattern Syntax

Patterns use standard regular expression syntax applied to full file contents:

Use literal prefixes when your format includes one (e.g., mycompany_api_)
Use character classes for the credential body (e.g., [a-zA-Z0-9]{32})
Use word boundaries or context anchors to reduce false matches
Escape special regex characters with backslash (e.g., \. for a literal period)

Examples

Internal API Token

Pattern: mycompany_api_[a-zA-Z0-9]{32}
Severity: High
Matches: mycompany_api_a8Kx9mPqR2nL5vBw7cYd3jF6hT0eU4sG

Internal Database Connection

Pattern: (mongodb|postgresql|mysql):\/\/[^@]+@internal-db\.[a-z]+\.mycompany\.com
Severity: Critical
Matches: postgresql://appuser:secretpass@internal-db.prod.mycompany.com

JWT Signing Key

Pattern: JWT_SECRET\s*[=:]\s*['"][a-zA-Z0-9+/]{32,}['"]
Severity: Critical
Matches: JWT_SECRET = "a8Kx9mPqR2nL5vBw7cYd3jF6hT0eU4sGz1Xp8Nq"

Service-to-Service Token

Pattern: svc_tok_[a-f0-9]{48}
Severity: High

Webhook Secret

Pattern: whsec_mycompany_[a-zA-Z0-9]{40}
Severity: Medium

Best Practices

Guideline	Details
Be specific	Include unique prefixes, specific lengths, and character sets. `mycompany_api_[a-zA-Z0-9]{32}` is good; `[a-zA-Z0-9]{20,}` is too broad
Include format identifiers	Prefix internal tokens with a recognizable string (e.g., `myco_`) for reliable detection
Test before enabling	Run a test scan and review all matches before activating a new rule
Document each rule	Clear descriptions help team members understand findings from custom rules
Review periodically	Remove rules for deprecated formats, add rules for new credential types
Use severity consistently	Critical = production infrastructure; High = sensitive data access; Medium = non-production; Low = sandboxed systems

How Custom Rules Work with Built-in Rules

Custom rules run alongside built-in patterns in every scan. If both a custom and built-in rule match the same string, the finding appears once using the more specific rule's metadata. Custom findings use the same severity levels, status workflow, filtering, and triage actions as built-in detections. Adding custom rules has minimal impact on scan performance.

Managing Rules

Edit, disable (toggle Enabled off), or delete rules in Settings > Custom Detection Rules. Changes take effect on the next scan. Existing findings from modified or deleted rules remain in the findings table for historical reference.