Rules that explain the risk, evidence, and fix.

Review security, dependency, and code-health rules with concrete examples, detection boundaries, remediation guidance, and reproducible local commands.

Rules that explain the risk, evidence, and fix.

16
Extended coverage14
03Detect duplicate code before merge.See how duplicate code fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI04Detect command injection before merge.See how command injection fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI05Detect path traversal before merge.See how path traversal fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI06Detect server-side request forgery (SSRF) before merge.See how server-side request forgery (SSRF) fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI07Detect JWT security weaknesses before merge.See how JWT security weaknesses fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI08Detect CORS misconfiguration before merge.See how CORS misconfiguration fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI09Detect CSP misconfiguration before merge.See how CSP misconfiguration fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI10Detect weak cryptography before merge.See how weak cryptography fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI11Detect weak randomness before merge.See how weak randomness fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI12Detect dead code before merge.See how dead code fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI13Detect dependency cycles before merge.See how dependency cycles fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI14Detect oversized files before merge.See how oversized files fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI15Detect malicious packages before merge.See how malicious packages fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI16Detect vulnerable dependencies before merge.See how vulnerable dependencies fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.LOCALREPORTCI

Use Rules that explain the risk, evidence, and fix. as a decision directory.

Review security, dependency, and code-health rules with concrete examples, detection boundaries, remediation guidance, and reproducible local commands. Open the page that matches the concrete decision in front of you, verify its evidence and limits, then continue to the relevant implementation or proof page.

  • Scope: Review security, dependency, and code-health rules with concrete examples, detection boundaries, remediation guidance, and reproducible local commands.
  • Evidence: Inspect the unsafe pattern, safer alternative, rule identifier, severity, confidence, detection scope, common false positives, and reproducible scan command.
  • Boundary: A rule detects a defined code pattern, not every possible exploit path; reviewers still need context, configuration, and tests for the affected system.

Choose a page by the evidence you need.

For Rules that explain the risk, evidence, and fix., do not choose from a name alone. Match the page to the repository, reviewer, output, and enforcement point that will determine whether the workflow is useful.

Decision pointWhat to inspect
ScopeReview security, dependency, and code-health rules with concrete examples, detection boundaries, remediation guidance, and reproducible local commands.
EvidenceInspect the unsafe pattern, safer alternative, rule identifier, severity, confidence, detection scope, common false positives, and reproducible scan command.
BoundaryA rule detects a defined code pattern, not every possible exploit path; reviewers still need context, configuration, and tests for the affected system.

Questions about Rules that explain the risk, evidence, and fix.

For Rules that explain the risk, evidence, and fix., these answers define what the directory covers, how to validate a page, and where human judgment remains necessary.

What does the Rules that explain the risk, evidence, and fix. directory cover?

It covers Review security, dependency, and code-health rules with concrete examples, detection boundaries, remediation guidance, and reproducible local commands. Each child page owns a narrower task or evaluation so readers can avoid mixing unrelated decisions.

What should I verify before acting on a Rules that explain the risk, evidence, and fix. page?

Verify the concrete evidence first: Inspect the unsafe pattern, safer alternative, rule identifier, severity, confidence, detection scope, common false positives, and reproducible scan command.

What should I not infer from the Rules that explain the risk, evidence, and fix. directory?

Do not infer more than the stated boundary: A rule detects a defined code pattern, not every possible exploit path; reviewers still need context, configuration, and tests for the affected system.

Continue with implementation evidence.

For Rules that explain the risk, evidence, and fix., use these routes to inspect a real artifact, confirm the product boundary, or implement the workflow described in this directory.

Validate the workflow on your own code.

Start with one local scan, inspect the evidence, and expand to reports, agents, or CI only when the signal is useful.