Detectors

1. Secrets in source code

Detects

Live-shaped credentials in text files: cloud keys (AWS/Azure/GCP and friends), SCM tokens (GitHub classic/fine-grained/OAuth/App, GitLab, Bitbucket), AI provider keys, payment keys, messaging and monitoring tokens, private-key blocks, and auth-bearing URIs.

How

High-confidence regex patterns, one per known credential format. The matched value is masked the instant it is found, before it is attached to a finding or persisted.

Doesn't catch

A credential in a format with no published pattern. Custom/corporate tokens with no fixed shape are the entropy detector's job (below); a value with a truly novel format may be missed by both.

Secret pattern rules→

2. Sensitive files committed to the repo

Detects

Files that should never be in version control regardless of contents: *.pem / *.key, *.pfx / .p12 / .jks / .keystore, SSH private keys, KeePass vaults, .env.production, cloud credential files, kubeconfig, .npmrc with auth, terraform.tfstate, database dumps, .git-credentials, .htpasswd.

How

Filename / path / extension / content-header matching — not a regex over the file body. Only the path is recorded, never the contents.

Doesn't catch

A sensitive file hidden under a non-standard name, or a secret embedded inside an otherwise-ordinary file (that is detectors 1 and 3).

Sensitive file rules→

3. High-entropy secrets in config files

Detects

Custom secrets in .env, .envrc, .ini, .toml, .yaml, .properties, and .conf files that no regex knows about.

How

Parses KEY=VALUE pairs, discards obvious placeholders (xxx, changeme, URLs, semver, IPs), and flags values with Shannon entropy at or above 4.0 bits/char whose key name looks secret-bearing (password, secret, api_key, token, …).

Doesn't catch

High-entropy values whose key name does not look like a secret, or secrets outside the recognized config file types. Tuned to favor few false positives over total coverage.

Secret pattern rules→

4. Secrets in recent git history

Detects

Credentials that were committed and later removed — still leaked, still in the history.

How

Replays up to the 30 most recent commits, extracts the added lines from each patch, and re-runs the full secret pattern library over them. Findings are deduplicated against the current tree so only history-exclusive matches surface, tagged with commit SHA + author + date.

Doesn't catch

Anything older than the 30-commit window, individual commit patches larger than 200 KB (skipped), or history that was rewritten away. Best-effort: if GitHub rate-limits the history pass it is skipped and reported, not assumed clean.

Scan limits→

5. Code-level vulnerabilities (SAST)

Detects

Injection (SQL, command, NoSQL, SSTI, prototype pollution, XXE), XSS, SSRF / open redirect, auth/JWT mistakes, weak crypto, path traversal, dynamic eval, ReDoS, insecure transport, cookie/session hygiene, insecure deserialization, info disclosure — each mapped to a CWE.

How

Two layers run side by side: AST analysis via the TypeScript Compiler API (ts-morph) over JS/TS that tracks user input into dangerous sinks across property hops, plus conservative single-line regex rules for JS/TS and Python where AST would be overkill. A third framework-aware layer fires stack-specific checks only when it detects the framework (Next.js, Express, NestJS, Django, Flask, FastAPI, Spring, Laravel, Rails).

Doesn't catch

Deep cross-file/interprocedural dataflow. Coverage is primarily JavaScript/TypeScript; Python is covered by the regex layer; other languages are not analyzed for code vulns.

SAST rules→

6. Vulnerable dependencies (SCA)

Detects

Known-vulnerable packages across npm, PyPI, Go, RubyGems, Maven/Gradle, and Composer, plus container-image OS-package CVEs. End-of-life Docker base images are flagged statically too.

How

Parses lockfiles/manifests and queries the npm advisory bulk API and OSV.dev, linking each finding to its GHSA/CVE. Container CVEs are ingested from a Trivy SARIF report you run in CI and commit. One shared OSV core, a 500-package cap, and a registry outage marks the detector skipped rather than failing the scan.

Doesn't catch

Vulnerabilities with no advisory published yet, versions that cannot be resolved statically (property-interpolated or dynamic ranges), and live image scanning — that is delegated to the Trivy report you provide.

Scan limits→

7. Supply-chain attacks (typosquatting, install hooks, dependency confusion)

Detects

Malicious or hijacked dependencies before they run: typosquatted package names, install-time lifecycle-hook abuse in package.json scripts and Python setup.py / pyproject build hooks, and registry signals — dependency confusion (a declared name that 404s on the public registry), freshly-published packages, and suspicious-maintainer flags.

How

Typosquatting uses Damerau-Levenshtein edit distance against popular npm/PyPI names. Lifecycle hooks are pattern-matched for curl|sh, base64 decode-and-execute, env-var exfiltration, and destructive rm -rf chains. Registry signals come from public npm registry metadata.

Doesn't catch

Deep behavioral analysis of package source, or ecosystems beyond npm/PyPI for the registry-metadata signals.

Supply-chain rules→

8. Infrastructure & CI misconfiguration (IaC)

Detects

Dockerfile hygiene, risky GitHub Actions workflows (pull_request_target with PR checkout, unpinned third-party actions, script injection), Terraform / CloudFormation / Kubernetes / Helm misconfig, and over-privileged cloud IAM declared in code (AWS/GCP/Azure/GitHub scopes).

How

Line- and structure-based checks per file type, each self-guarding on file shape so non-matching YAML/JSON is skipped.

Doesn't catch

Misconfig in IaC formats not listed here, or runtime cloud state — these read your committed files, not your live cloud accounts.

IaC & Cloud IAM rules→

9. Repository posture score

Detects

How the repo is set up rather than a specific bug: branch protection, governance docs, dependency-update hygiene, signed commits, org MFA, secret scanning, least-privilege workflow tokens, release provenance — 17 signals in four groups, graded A–F.

How

Reads repo metadata, files, branch protection / rulesets, and commit verification via the GitHub API, then scores the percentage of assessable signals earned. Signals it cannot inspect are reported as unknown and excluded from the math.

Doesn't catch

Penalize you for signals it cannot see (admin-only settings on a public scan show as unknown, not failed).

Posture score→

10. IAM risk scanner

Detects

Identity-and-access risk in the IAM policy documents you commit: GitHub Actions OIDC trust weaknesses (no Condition, wildcard repo/ref, pull_request trust), privilege-escalation patterns, and admin-equivalent grants.

How

Selects IAM-shaped files from the tree (Terraform, CloudFormation/SAM, JSON policy docs, serverless.yml), extracts policy statements, and runs the three check families over them. Findings deduct from a 100-point score that maps to a low/medium/high/critical level.

Doesn't catch

Inspect your live cloud accounts or org settings — it reads policy-as-code, not the AWS/GCP/Azure control plane. (Org MFA enforcement is a posture signal, detector 9, not part of this scanner.)

11. Open-source license / compliance risk

Detects

Legal rather than security risk: strong copyleft (GPL/AGPL/SSPL), weak copyleft (LGPL/MPL/EPL/CDDL), and proprietary/UNLICENSED dependencies in a project that redistributes them.

How

For npm, reads the license field already in package-lock.json (no network). For PyPI/Go/RubyGems it enriches via deps.dev, bounded to 200 packages. Dual licenses with a permissive escape are treated as acceptable; dev-only npm deps are skipped.

Doesn't catch

Give legal advice, or resolve license text that a registry does not record. It surfaces the risk; the call is yours.