Custom Rules Engine: Tailoring NonaGuard to Your Standards
Out-of-the-box checks are just the beginning. Learn how to create custom scan rules that enforce your organization's specific policies and standards.
Every organization has its own standards beyond general best practices. Maybe you require all custom modules to have unit tests. Or you need to flag any user who hasn't logged in for 90 days. Or your compliance team wants alerts when specific modules are installed. NonaGuard's custom rules engine lets you encode these policies as automated scan checks.
How Custom Rules Work
Custom rules are user-defined checks that run alongside NonaGuard's built-in 200+ checks during every scan. Each rule defines:
- Condition: What to check (e.g., "module X is installed", "user count exceeds N", "cron interval is less than Y")
- Severity: How critical a violation is (info, warning, high, critical)
- Description: Human-readable explanation of why this matters
- Remediation: What to do when the rule triggers
Rule Definition Format
Custom rules use a declarative YAML format that's intentionally simple — no programming required:
🤖 NonaGuard uses AI-powered analysis to turn scan findings into prioritized, step-by-step remediation plans — with effort estimates and cost projections.
# custom-rules/block-dangerous-modules.yaml
name: Block Dangerous Community Modules
description: Flag instances with unapproved community modules installed
severity: critical
category: security
condition:
type: module_installed
modules:
- base_import_security_group # Known problematic module
- auto_backup # Stores credentials in DB
- web_shell # Gives direct Python shell access
remediation: |
Uninstall the flagged module immediately. If the module provides
necessary functionality, request a security review from the
engineering team before reinstalling.
Example Custom Rules
Enforce Module Blocklist
Flag any instance that installs a module your organization has banned (e.g., community modules that haven't been security-reviewed).
# custom-rules/module-blocklist.yaml
name: Unapproved Module Detection
severity: high
category: compliance
condition:
type: module_installed
# Any module matching these patterns triggers the rule
module_patterns:
- "web_unsplash" # Leaks API keys
- "base_import_*" # Unrestricted data import
- "*_debug_*" # Debug tools in production
remediation: |
Remove unapproved modules from production. Use staging
environments for evaluation. All community modules require
security review before production deployment.
User Activity Threshold
Alert when a user with elevated permissions hasn't logged in for a configurable number of days — a strong indicator of an orphaned account that should be deactivated.
# custom-rules/stale-admin-accounts.yaml
name: Stale Admin Account Detection
severity: high
category: permissions
condition:
type: user_activity
groups:
- base.group_system # Admin users
- base.group_erp_manager # Settings access
max_inactive_days: 90
remediation: |
Deactivate the user account if the employee has left the
organization. If active, require password reset and 2FA
enrollment before re-granting access.
Version Pinning
Require all instances in your portfolio to run a specific Odoo version. Flag any instance that's on a different version for investigation.
# custom-rules/version-pinning.yaml
name: Odoo Version Policy
severity: warning
category: compliance
condition:
type: odoo_version
# All instances must be on these versions
allowed_versions:
- "17.0"
- "18.0"
# Anything below this triggers critical severity
critical_below: "16.0"
remediation: |
Instances on unapproved versions must be scheduled for
upgrade within 90 days. Contact the client to begin
upgrade planning.
Custom Code Standards
Check that all custom modules in a specific namespace follow your coding standards:
# custom-rules/code-standards.yaml
name: Custom Module Standards Enforcement
severity: warning
category: custom_code
condition:
type: module_metadata
module_prefix: "custom_"
require:
- has_readme: true
- has_access_rules: true
- has_icon: true
- manifest_has_key: "license"
remediation: |
Update the module to include a README.rst, proper
ir.model.access CSV definitions, a static/description/icon.png,
and a license key in __manifest__.py.
Portfolio-Wide Rules
Custom rules are especially powerful at portfolio scale. A single rule definition applies to every scan across all managed instances. When you discover a new risk or policy requirement, encode it once and it's automatically checked everywhere:
- Audit preparation: Add rules for SOC 2 or ISO 27001 controls you need to evidence
- Incident response: After a security event, add a rule to detect the same pattern across your portfolio
- Client onboarding: Run your custom rules on new client instances during initial assessment
- Compliance tracking: Track rule violations over time to demonstrate ongoing compliance improvement
Rule Execution and Reporting
Custom rules run in the same scan cycle as built-in checks. Results appear in the standard scan report alongside NonaGuard's findings, with your custom severity levels and remediation text. This means custom rule violations affect the Pulse Score — giving you a single metric that reflects both industry best practices AND your organization's specific standards.
Custom rules are available on Pro plans and above. Explore the rules engine with your free account.
⚡ See NonaGuard in Action
200+ automated checks, AI-powered insights, branded PDF reports, and continuous monitoring — all designed specifically for the Odoo ecosystem.
