Rules Engine
The Rules Engine lets CodeScan detect specific patterns in your code using regular expressions — instantly, at zero AI cost. It runs alongside the AI pipeline on every scan and tags each match separately so you always know where each finding came from.
How it works
When you start a scan, the Rules Engine runs before the AI pipeline:
Plan availability
Community rules are free for everyone. Custom rules require a paid plan:
Opening the Rules panel
In the scanner, click the ⬡ Rules button in the top header. The panel slides in from the right with two tabs:
- Community — 25 built-in rules, all on by default. Toggle any rule off to skip it on future scans.
- Custom — your own rules. Create, edit, enable/disable, or delete them here.
The number badge on the ⬡ Rules button shows how many rules are currently active.
Community rules reference
All 25 built-in rules run automatically. You can turn any of them off in the Community tab if they generate noise for your project.
Creating a custom rule — field guide
Click + New custom rule in the Custom tab. Fill in the fields below:
A short, human-readable label shown in the findings panel. Be specific — 'Hardcoded DB password' is better than 'Security issue'. This is what your team will see in reports.
Hardcoded DB passwordA JavaScript-compatible regular expression (no leading/trailing slashes). The pattern is tested against each line of the file. Backslashes must be doubled (\s not \s). The pattern is case-insensitive by default.
Tip: Test your regex at regex101.com before saving. Select JavaScript as the flavour.
db_pass\s*=\s*["'][^"']+["']Groups the finding with similar issues. Used for filtering and reports. Common values: Hardcoded Secret, SQL Injection, Command Injection, XSS, Path Traversal, Security Misconfiguration, Weak Cryptography, Custom.
Hardcoded SecretHow serious is this finding? Choose the level that matches the worst-case impact if exploited:
criticalcriticalImmediate exploitation possible. Exposed credentials, RCE, authentication bypass.highExploitable with moderate effort. Injection flaws, insecure deserialization.mediumReal risk but requires specific conditions. Weak crypto, misconfigured headers.lowMinor risk or defence-in-depth improvement. HTTP instead of HTTPS, verbose errors.infoNo direct risk. Debug statements, TODO comments, informational notes.Explains what the rule detected and why it is dangerous. Shown in the finding detail panel. Write 1–3 sentences. Focus on the security impact, not just what the pattern matches.
A database password is hardcoded in the source code. If this file is committed to version control, the password becomes accessible to anyone with repo access.Actionable fix instructions shown to the developer. Be specific — include the function, pattern, or config setting to use instead of the insecure one.
Move the database password to an environment variable (process.env.DB_PASS) and load it at runtime. Rotate the password if it has already been committed.Common Weakness Enumeration ID for the vulnerability type. Optional but adds a clickable link to the CWE database in the finding. Format: CWE-NNN.
CWE-259CWE-89SQL InjectionCWE-79Cross-Site Scripting (XSS)CWE-78OS Command InjectionCWE-22Path TraversalCWE-259Hardcoded PasswordCWE-798Hardcoded Credentials (API key, token)CWE-327Weak Cryptographic Algorithm (MD5, DES)CWE-338Insecure Random Number GeneratorCWE-295Improper Certificate ValidationCWE-352CSRFCWE-601Open RedirectCWE-532Sensitive Data in LogsCWE-489Debug Code Left in ProductionCWE-95Code Injection / eval()Restricts the rule to specific languages. Leave blank to match all languages. Enter language names separated by commas. The names must match what CodeScan detects from the file extension:
javascript, typescriptjavascript.js .jsx .mjs .cjstypescript.ts .tsxpython.pyruby.rbgo.gojava.javakotlin.ktswift.swiftphp.phprust.rscsharp.cscpp.c .cpp .cc .h .hppshell.sh .bashsql.sqlExample custom rules
Copy these as starting points for your own rules:
(?:mongodb|postgres|mysql|redis):\/\/[^\s"']+:[^\s"']+@SeveritycriticalCategoryHardcoded SecretCWECWE-798Languages(blank — all)WhyDetects database connection strings with embedded usernames and passwords.(?:jwt_secret|JWT_SECRET|jwtSecret)\s*[:=]\s*["'][^"']{10,}["']SeveritycriticalCategoryHardcoded SecretCWECWE-798Languages(blank — all)WhyDetects hardcoded JWT signing secrets.res\.cookie\s*\([^)]+\)(?!.*httpOnly)SeveritymediumCategorySecurity MisconfigurationCWECWE-614Languagesjavascript, typescriptWhyFlags cookies set without the httpOnly or secure flags.pickle\.loads?\s*\(SeverityhighCategoryInsecure DeserializationCWECWE-502LanguagespythonWhypickle.loads on untrusted data allows arbitrary code execution.(?:console\.log|print|logger\.).*(?:password|token|secret|apikey|ssn|credit_card)SeveritymediumCategoryInformation DisclosureCWECWE-532Languages(blank — all)WhyCatches logging statements that include sensitive field names.Reading rule findings in the scanner
Rule-matched findings appear in the same list as AI findings. You can tell them apart by the tag next to the status:
Rule findings include all the same fields as AI findings: severity, category, line number, snippet, description, recommendation, and CWE. The only difference is that Fix and Enrich are not available on rule matches — those require the AI pipeline.
Tips for writing good regex rules
- Escape backslashes: write
\\snot\s— the pattern field is a plain string, not a regex literal. - Anchor to context:
password\\s*=\\s*["']is better than justpassword— it avoids flagging comments and variable names. - Use alternation for variants:
(?:password|passwd|pwd)catches multiple spellings in one rule. - Set a language filter for language-specific patterns (e.g.
shell=Trueonly makes sense in Python). - Use INFO severity for patterns that are always worth reviewing but not always a bug (e.g. console.log).
- Test at regex101.com — paste your pattern, select JavaScript, and test against sample code before saving.