Skip to content

Rules

Explore CodeGuard Rules

Understand every security and architecture rule, why it matters, and how to fix it.

Showing 7 of 7 rules

SEC001SecuritySeverity: warning

Dynamic eval execution #

Calls to eval(), including globalThis.eval, window.eval and global.eval.

Why it matters

eval executes a string as code with the caller's privileges. If any part of that string can be influenced by an attacker, it becomes arbitrary code execution.

What it detects

  • eval(expression)
  • globalThis.eval(expression)
  • window.eval(expression)
  • global.eval(expression)
Problematic Evaluating a string as code
export function calculate(expression: string) {
  return eval(expression);
}
Safer Parse data instead of running it
export function parseSettings(text: string) {
  return JSON.parse(text) as Record<string, unknown>;
}

Recommended fix

Avoid evaluating strings as code; use explicit parsing or a safe data format.

False-positive and limitation notes

  • The rule matches the call shape only. It does not prove that the evaluated string is attacker-controlled, so a call on a fixed trusted string is still reported.
  • Indirect forms such as aliasing eval to another variable are not tracked.

Enable or disable with "SEC001": true | false under rules.security in codeguard.config.json.

SEC002SecuritySeverity: warning

Function constructor #

Use of Function(...) or new Function(...) to build code from strings.

Why it matters

The Function constructor compiles a string into executable code, with the same injection risk as eval and weaker tooling support.

What it detects

  • new Function(...)
  • Function(...)
Problematic Building a function from a string
const add = new Function("a", "b", "return a + b");
Safer Use a statically defined function
const add = (a, b) => a + b;

Recommended fix

Replace dynamic function construction with explicit, statically defined functions.

False-positive and limitation notes

  • Any Function constructor call is reported, even when every argument is a constant.
  • Calls to a locally defined function named Function are indistinguishable from the global constructor.

Enable or disable with "SEC002": true | false under rules.security in codeguard.config.json.

SEC003SecuritySeverity: warning

Potential command injection #

A shell command built from a non-literal value and passed to a child_process API.

Why it matters

exec and exec-style calls run their command through a shell. Interpolating untrusted input lets an attacker append extra shell commands.

What it detects

  • exec / execSync with a non-literal first argument
  • execFile / execFileSync with shell: true and a dynamic command or arguments
  • Only when child_process or node:child_process is imported or required in the file
Problematic Interpolating input into a shell command
import { exec } from "node:child_process";

export function archive(name: string) {
  exec(`tar -czf out.tgz ${name}`);
}
Safer Fixed executable with an argument array
import { execFile } from "node:child_process";

export function archive(name: string) {
  execFile("tar", ["-czf", "out.tgz", name]);
}

Recommended fix

Use execFile with a fixed executable and argument array, and validate untrusted input.

False-positive and limitation notes

  • Findings are potential, not confirmed: the rule cannot tell whether the dynamic value is validated or trusted.
  • A static string command is never reported; a command held in a constant variable is non-literal and is reported.
  • spawn and other APIs are not inspected, and neither is a child_process function re-exported from another module.

Enable or disable with "SEC003": true | false under rules.security in codeguard.config.json.

SEC004SecuritySeverity: warning

Hardcoded credential #

A static string assigned to a credential-like name such as password, secret, token or apiKey.

Why it matters

Secrets committed to source control are exposed to everyone with repository access and remain in history after removal.

What it detects

  • Variable declarations, object properties and assignments whose name contains password, passwd, secret, api key, token, credential or private key
  • Only string or no-substitution template literals of at least four characters
  • Finding messages never include the secret value
Problematic A literal secret in source
const apiKey = "sk_live_51Nx4f9aB7cD2";
Safer Read the value at runtime
const apiKey = process.env.API_KEY;

Recommended fix

Load credentials from a secret manager or environment variable; do not commit secret values.

False-positive and limitation notes

  • Placeholders such as your_key, changeme, example, dummy, redacted, test, <...> and ${...} are skipped, as are process.env and import.meta.env values.
  • A literal that merely looks like a secret, for example a UI label assigned to a variable named token, can still be reported.
  • Secrets in unusual forms (concatenation, function arguments, files excluded from scanning) are not detected.

Enable or disable with "SEC004": true | false under rules.security in codeguard.config.json.

SEC005SecuritySeverity: warning

String passed to a timer #

A string literal passed as the first argument of setTimeout or setInterval.

Why it matters

Timer functions given a string evaluate it as code, an implicit eval that is easy to overlook.

What it detects

  • setTimeout("code", delay)
  • setInterval("code", delay)
  • String literals and no-substitution template literals
Problematic A timer that evaluates a string
setTimeout("refresh()", 1000);
Safer Pass a function
setTimeout(() => refresh(), 1000);

Recommended fix

Pass a function to the timer instead of a string of executable code.

False-positive and limitation notes

  • Only literal strings are matched; a string held in a variable is not detected.
  • Calls through window.setTimeout or globalThis.setTimeout are not matched; only the bare identifiers are.

Enable or disable with "SEC005": true | false under rules.security in codeguard.config.json.

ARCH001ArchitectureSeverity: warning

Circular dependency #

A group of scanned local modules that import each other, directly or indirectly.

Why it matters

Cycles couple modules tightly, complicate refactoring and testing, and can cause partially initialized exports at runtime.

What it detects

  • Cycles among scanned local modules (strongly connected groups, including a module importing itself)
  • import, export-from, require(), dynamic import() and import types with string literals
  • One finding per cycle, located at the first module in sorted path order
Problematic Two modules importing each other
// src/a.ts
import { b } from "./b.js";
export const a = () => b();

// src/b.ts
import { a } from "./a.js";
export const b = () => a();
Safer Move shared code to a lower-level module
// src/shared.ts
export const shared = () => 1;

// src/a.ts and src/b.ts
import { shared } from "./shared.js";

Recommended fix

Extract shared code into a lower-level module or invert the dependency to break the cycle.

False-positive and limitation notes

  • Type-only imports count as edges, so a cycle that exists only in types is still reported.
  • External packages and files outside the project are never part of the graph.

Enable or disable with "ARCH001": true | false under rules.architecture in codeguard.config.json.

ARCH002ArchitectureSeverity: warning

Unresolved local import #

A relative import or configured path alias whose target cannot be found in the project.

Why it matters

A broken local import fails at build or run time and often points to a renamed, moved or deleted module.

What it detects

  • Relative specifiers (starting with .) with no matching file
  • tsconfig.json paths aliases (with optional baseUrl) with no matching file
  • Extension and index-file resolution, so ./x.js can resolve to x.ts
Problematic Import of a file that does not exist
import { format } from "./utils/fromat.js";
Safer Point to an existing module
import { format } from "./utils/format.js";

Recommended fix

Check the relative import or configured path alias and ensure its target exists inside the project.

False-positive and limitation notes

  • Bare package names such as react are treated as external and never reported.
  • Alias handling does not model every package export or inherited configuration case.
  • Imports resolving outside the project root or through symlinks are not reported.

Enable or disable with "ARCH002": true | false under rules.architecture in codeguard.config.json.