Scanners and detections

A Code Security scan runs several scanners over your repository and merges their results into one set of findings. Each finding shows which tool produced it.

Scanner	What it covers
Opengrep (Oneleet rules)	Oneleet’s own curated ruleset: JavaScript and TypeScript (including Node.js and React), Python, PHP, Ruby, Rust, Go, shell scripts, HTML, GitHub Actions workflows, and npm lockfiles
Gosec	Go-specific security analysis
Bandit	Python-specific security analysis
Gitleaks	Leaked secrets and credentials, in any language or file type
Oneleet checks	Custom checks written by Oneleet, such as the npm ignore-scripts hardening check

The Oneleet ruleset

Opengrep is the open-source fork of Semgrep, a pattern-based static analysis engine. Rather than running a large community rule bundle, Oneleet maintains its own ruleset and holds every rule to a false-positive bar before shipping it. A rule that cries wolf trains your team to ignore the scanner, and that’s worse than no rule at all. Each rule is assigned a severity and confidence, and most ship with a written description and remediation guidance that appear on the issue page.

A few detections worth calling out:

• TLS certificate verification turned off, detected consistently across Node.js, Python, PHP, Ruby, Rust, and even curl flags in shell scripts. (In Go, Gosec covers the equivalent InsecureSkipVerify pattern.)
• Shell injection in GitHub Actions workflows, where untrusted ${{ github.* }} input is interpolated into run: steps. Historically this has been one of the most-found and most-fixed issues in customer codebases.
• Indicator-of-compromise rules for npm supply-chain attacks, which flag lockfiles pinning package versions known to be malicious. When the Shai-Hulud 2.0 npm worm hit in November 2025, a rule matching over a thousand compromised package versions shipped within days. A rule for the React Server Components RCE (CVE-2025-55182) shipped the day the advisory was published.
• The npm ignore-scripts check, which flags npm projects that allow packages to run lifecycle scripts on install. Most npm supply-chain attacks rely on exactly that mechanism.

Rules are added and tuned continuously. When real-world results show a rule is noisier than expected, we lower its confidence or disable it outright. If a rule keeps producing false positives in your codebase, let us know rather than living with the noise.

Rule IDs

Every Oneleet rule has a stable, readable ID such as javascript.language.eval.dynamic-code or python.tls.requests-module.no-cert-verification. These IDs appear on issue pages and are what you reference in ignore rules. Other scanners keep their native IDs (for example Gosec’s G402 or Gitleaks’ generic-api-key).

Secrets detection

Gitleaks scans every file for committed credentials such as cloud provider keys, access tokens, private keys, and generic high-entropy strings that look like secrets. Scans cover the code as checked out at scan time, not your full git history.

The secret value itself is redacted before results leave the scanner, and Oneleet never stores it. A finding tells you the file, line, and the kind of secret detected. To see the value, open the file at that location.

Secret findings are always High severity. A leaked credential is directly usable by an attacker, so there’s no judgment call to make.

If the finding is a real secret, treat it as compromised. Rotate it first, then remove it from the code. The next scan resolves the finding automatically once it’s gone. If it’s not a real secret (a test fixture, a placeholder), resolve it as a false positive or suppress it with a .gitleaksignore entry.