Structural security

Catch recognizable security-sensitive code patterns before they become part of shared history.

Check ID: structuralSecurity. Engine: ast-grep 0.45.1 with Zedbee’s original rules, verified against the Zedbee 0.1.0 source snapshot on September 7, 2026.

Built-in check

Local patterns, checked against your change

Structural security parses JavaScript and TypeScript and looks for a small set of recognizable code structures, such as dynamic code execution or explicitly disabled TLS verification. It does not execute the source being scanned or download third-party rules.

The check is enabled at error severity in fast, recommended, and thorough. The configuration shown makes that default explicit; you do not need to add it just to enable the check in those profiles.

With when: "relevant", changed supported source files select the workspaces to inspect. Swarm compares supported source in the baseline and target snapshots, then attributes findings to the selected change. Supported extensions are .js, .jsx, .mjs, .cjs, .ts, .tsx, .mts, and .cts.

Keep settings in the repository-root .zedbeerc.jsonc. Stage updates for local scans; commit and push them for CI to use them. The check supports severity and timing, not custom rule packs or per-rule configuration.

How Swarm attributes findings Compare managed engines and versions

{
  "schemaVersion": 1,
  "profile": "recommended",
  "checks": {
    "structuralSecurity": {
      "severity": "error",
      "when": "relevant"
    }
  }
}

Rule inventory

The seven built-in rules

Each rule identifies a code structure worth reviewing. A match is not proof that an attacker can reach or exploit it; the check does not trace the origin of runtime values.

Structural security rule coverage
Rule ID	Reported structure	What to review
`direct-eval`	A direct `eval(...)` call.	Replace text execution with a parser or an explicit set of supported operations.
`function-constructor`	`Function(...)` or `new Function(...)`.	Use ordinary functions or a constrained interpreter instead of compiling text as code.
`child-process-string-exec`	Recognized Node `child_process.exec` or `execSync` calls.	Prefer a fixed executable and separate argument array; validate which arguments are permitted.
`dynamic-vm-execution`	Recognized Node `vm.runInContext`, `runInNewContext`, or `runInThisContext` calls.	Avoid executing untrusted text. A Node vm context is not treated as a security guarantee.
`tls-verification-disabled`	An object property sets `rejectUnauthorized` to literal `false`.	Remove the override and configure a trusted certificate authority when needed.
`weak-password-hash`	A recognized Node `createHash` call uses MD5 or SHA-1 and is directly chained to `update` with a password-named value.	Use a dedicated password-hashing function with appropriate parameters, not a fast general-purpose hash.
`credential-over-insecure-http`	Recognized Node HTTP(S) or request-package options combine a static HTTP URL with a present credential.	Use HTTPS and keep credentials out of plaintext transports and URLs.

Module-based rules recognize supported imports, including import aliases. They do not follow arbitrary aliases assigned later. Request-option detection is limited to Node HTTP(S) modules and the request package, not every HTTP client.

Examples

Recognizable shapes, not runtime proofs

The shell example reports child-process-string-exec even though its command is a literal. The rule recognizes the shell-execution API; it does not first prove that user input reaches the command.

The TLS example reports tls-verification-disabled because of the object property itself. It does not need to prove that the options are eventually passed to a network client.

The HTTP example combines a literal HTTP URL and a credential in a recognized request call. The check does not need to know the token’s runtime value, but statically empty credential values are ignored.

These examples illustrate detection, not code to copy into a project. Review the surrounding behavior before choosing a fix. Structural security findings do not have managed automatic fixes.

import { exec } from "node:child_process";

exec("git status");

Detection limits

What this check cannot establish

This check matches local syntax. It does not provide general taint tracking, dataflow analysis, inter-file analysis, reachability analysis, framework rule packs, or a continuously updated community rule registry.

The alias example assigns an imported API to another variable. The current rule does not follow that assignment, so this form can escape detection. Values assembled across statements can also fall outside the matching boundary.

To avoid mistaking local names for built-in APIs, global-looking names such as eval and Function are ignored when rebound in the file. This conservative behavior can miss real uses as well as avoid false positives.

No finding does not prove the code is secure.

These seven rules cover specific structures, not every way an application can be attacked. Use broader security analysis and code review where your project needs them; this check is not a replacement for an enterprise SAST platform.

import { exec } from "node:child_process";

const run = exec;
run(command);

Act on a result

Review, fix, and scan again

Read the rule ID, source location, remediation, and attribution evidence. Make the appropriate change in your working files, review the diff, stage it, and rerun the scan. zedbee fix does not automatically repair structural security findings.

Severity warn keeps attributable findings visible without blocking; off disables the check. Changing severity changes policy, not detection coverage. A scan can also be incomplete rather than pass or report a blocking finding.

If you see STRUCTURAL_SECURITY_PARSE_FAILED, inspect the reported baseline or target file. Confirm it contains valid JavaScript or TypeScript. If the syntax is valid for your project but unsupported by the parser, report a compatibility issue; do not treat missing analysis as a clean result.

Secret detection and vulnerable-dependency analysis are separate checks. Structural security itself performs no network lookup; enabling other checks can introduce their separately documented network behavior.

Read about secret detection and redaction Review online dependency vulnerability analysis Review the rest of the check suite

npx zedbee checks
npx zedbee scan --format json > zedbee-report.json