repyyDocs

repyyDocumentationDetection coverage

Detection coverage

Know what the scan can see.Know where review still matters.

This guide maps repyy’s built-in static checks to their rule IDs, explains the controls that reduce false positives, and names the boundaries that a scan deliberately leaves outside its scope.

Static Source is read as dataContextual Findings retain file rolesHonest Limits become incomplete results
An acceptance map, not a guarantee

Exact indicators age. Heuristics can produce false positives and false negatives. NO FINDINGS means no enabled rule matched within completed coverage; it does not prove safety.

Coverage map

The scanner combines individual indicators with correlated behavior. The IDs below are the families you will see in terminal, JSON, SARIF, and HTML reports.

Detection areaRepresentative checksRule IDs
Dynamic executioneval, Function constructors, VM execution, string timers, browser execution APIs, OS process spawningEXEC-*, COMBO-002
ObfuscationBase64, hex and Unicode decoding; dense escapes; string reversal; computed globals; shufflers; long or high-entropy linesOBFS-*, UNICODE-001
Package lifecyclenpm and Composer hooks; Python, Cargo, Go, JVM, and MSBuild build-time executionPKG-001, PY-001, PHP-001, RUST-001, RUST-002, GO-001, JVM-001, DOTNET-001
Malicious dependenciesSourced package/version indicators across eight ecosystems, typosquats, unusual versions, URL/VCS dependenciesIOC-PKG-*, TYPOSQUAT-001, PKG-002, PKG-003, PKG-005
Package-manager integrityRegistry credentials, alternate sources, overrides and aliases, nonstandard lockfile URLs, local package-manager executables/plugins, wrapper URLs and checksums, unsafe package binariesNPMRC-*, LOCK-001, PKG-004, PKG-006, PKG-008, PKG-009, PY-003, RUBY-002, RUST-003, RUST-004, RUST-005, PHP-002, PHP-003, NUGET-001, YARN-*, JVMWRAP-*
Download and executionPipe-to-shell, decode-to-execute, downloaded executable launch, remote importsCHAIN-*, IMPORT-002, DOCKER-002
BackdoorsRequest-controlled commands, runtime-computed imports, Node require bypasses, hardcoded authentication bypassesBACKDOOR-*, IMPORT-001, IMPORT-003
Credential and wallet accessSSH, cloud and container credentials; browser databases; wallets; clipboard, cookies, keylogging, forms, sensitive readsCRED-*, EXFIL-002, ENV-001
SecretsPrivate keys and AWS, GitHub, Stripe, Slack-style tokens; evidence is redactedSECRET-*
Suspicious networkDiscord, Telegram, Pastebin, ngrok, public raw-IP URLs, WebSockets, DNS transfer primitivesNET-*, IPURL-001, EXFIL-001
Collection and exfiltrationHost fingerprinting or environment collection correlated with outbound transferFINGERPRINT-001, COMBO-001
Reverse and bind shellsShell, netcat/ncat, socat, FIFO, scripting-language and socket/dup patternsREVSHELL-*
CryptominingXMRig, CoinHive, CryptoNight, Stratum, pool names, corroborated mining portsMINER-001
Sandbox and CI evasionVM, container, and CI probes with elevated correlated executionEVADE-001, COMBO-003
CI/CD integrityUntrusted GitHub event interpolation, privileged checkout, mutable actions, secret egress, low-trust cache writes, artifact use in privileged workflow_run jobs, pull requests on self-hosted runners, CI variable injectionCICD-*
Editor and agent executionVS Code tasks/settings/extensions, devcontainers, JetBrains, Vim/Neovim project config, AI-agent hooks and prompt injection in common instruction-file names and formatsIDE-*, AGENT-*
Image active contentExecutable SVG script elements, event handlers, and JavaScript linksIMAGE-001
ContainersRemote ADD, privileged/host namespaces, Docker socket, capabilities, sensitive mountsDOCKER-*
Git metadataActive hooks, hooks-path changes, executable filters/helpers, unsafe protocol configurationGITHOOK-*, GITMETA-001
File and repository integrityKnown SHA-256 indicators, binaries, executable bits, escaping symlinks, archive traversal/resource bounds, missing README/licenseIOC-HASH-SHA256, BINARY-001, EXECBIT-001, SYMLINK-*, ARCHIVE-001, REPO-*
Social engineeringUrgency plus interview pressure, instructions to disable security or elevate privilegesSOCIAL-*, APT-001

Supply-chain files by ecosystem

These are static review signals in repository files. An alternate source or build hook can be intentional; repyy does not install, resolve, or execute it.

Node/npm, Yarn, pnpmpackage.json lifecycle scripts, non-registry dependencies across all four scopes, aliases checked by actual package name, nested overrides and resolutions; registry settings, Yarn executable/plugins, and suspicious lockfile URLs. npm package spec · Yarn settings
Pythonrequirements*.txt, pip config, Pipfile, pyproject.toml, and uv.toml alternate indexes or unsafe uv strategy; setup hooks and direct URL/VCS dependencies. pip format · uv indexes
RubyGemfile and .bundle/config alternate sources or mirrors and inline Git/path gems. Gemfile.lock has generic text checks, not a resolved-source audit. Bundler Gemfile
Gogo.mod/go.work replacements, including block form, and //go:generate. go.sum hashes are not independently audited. Go module reference
RustCargo.toml declared or sibling build.rs execution, Git/path/registry dependencies, and overrides; .cargo/config.toml source replacement. Cargo.lock is not resolved. Cargo build scripts · source replacement
Java/JVMMaven and Gradle build/repository rules; Gradle/Maven wrapper distribution URLs and SHA-256 settings. Gradle Wrapper · Maven Wrapper
PHPcomposer.json scripts, alternate repositories, and unrestricted plugin permission. composer.lock has generic text checks, not a resolved-source audit. Composer repositories · plugin permissions
.NETNuGet.Config feeds and wildcard mappings; project and centrally managed Directory.Packages.props dependencies; MSBuild Exec in project, .props, and .targets files. NuGet configuration · MSBuild Exec

How repyy improves precision

Rules are interpreted with context so a suspicious token in a test fixture is not treated exactly like the same token in an install hook. Precision changes the review signal; it never turns a scan into proof of safety.

Match scoperaw checks content, code separates executable tokens from common comments and literals, and structured checks parse supported formats.
File rolesExecutable code, CI/install hooks, manifests, docs, examples, tests, evidence, generated output, dependencies, rule definitions, metadata, and archive entries are distinguished.
CorrelationsBehavior chains require distinct actionable signals from executable code. Imports, generated examples, and low-confidence matches cannot create a high-confidence chain alone.
Context downgradeDocumentation, tests, fixtures, and signature corpora may be downgraded. Confirmed IOCs are never silenced by contextual downgrades.
Noise exclusionsLong-line and entropy checks skip lockfiles, source maps, and known generated output; entropy must be near an execution primitive.
Indicator parsingPackage names are matched only in parsed manifests. A sourced affected version can become a confirmed IOC; an uncertain range remains a review signal.
Path matchingRule globs compare case-insensitively. Common agent instruction files receive instruction context; ordinary documentation and test fixtures retain contextual downgrades.

Artifact findings require a download of an upstream run’s artifact followed by a command in the same workflow_run job. Cache-write findings require pull_request_target, issue_comment, or workflow_run with effective write or write-only cache mode. They prompt review of upstream trust and job behavior; see GitHub’s secure-use guidance and cache access guidance. CI interpolation and secret-egress checks also inspect decoded multiline run blocks one step at a time. A pull_request job on a self-hosted runner is a review signal because the scanner cannot infer repository visibility or fork-approval settings; see GitHub’s runner warning.

Every finding keeps matched locations, occurrence totals, confidence, disposition, and a stable fingerprint. Display controls such as --min-severity, --min-confidence, and --detail change what you see, not the verdict or exit code.

Focus a review
repyy scan ./repo --min-severity high --min-confidence high --detail review

Coverage has a boundary

Default resource limits prevent hostile repositories and archives from exhausting the scanner. When a timeout, limit, permission, clone, archive, or read error reduces coverage, the result is SCAN INCOMPLETE.

Per repository10 minute timeout · 100,000 files · 50 MiB per file
Per archive10,000 entries · 1 GiB uncompressed bytes · 3 nested levels
Dependency treesSkipped by default; opt in with --include-dependencies
Adjust deliberately
repyy scan ./repo --timeout 20m --max-files 150000 --max-file-size 104857600

Review the coverage warnings before relying on a result. Exit code 2 indicates an incomplete target, even if another target completed successfully. See the exit-code reference for automation behavior.

Package-manager options such as pip -r/-c are not followed, build configuration is not evaluated, and declared dependencies are not compared with resolved lockfile content. Wrapper archive hashes are checked for presence and format, not verified against downloaded bytes. Sibling build.rs detection applies to unpacked repository files.

Raster-image metadata and pixels are not parsed for embedded instructions or scripts. Valid text SVG files are inspected for active content.

Deliberate exclusions

Some signals are outside the scanner’s private, offline boundary or would create misleading accusations.

Language

Non-English comments are not evidence of malware and are not scored.

Online identity

GitHub account age, followers, and activity are not collected. They would require sending identifiers to an online API.

Network ranges

Loopback, private, unspecified, link-local, and multicast addresses are excluded from raw-IP alerts.

Known generated content

Lockfiles, source maps, generated output, and full-SHA-pinned GitHub Actions receive targeted exclusions where appropriate.

Offline intelligence is explicit

Scans never contact the update service or upload repository data. Use repyy intel status to inspect snapshot age; use repyy intel update only when you choose to download a signed public snapshot.

Explain a rule before acting

Rule explanations are available offline and show the rule’s severity, confidence, disposition, category, matching scope, applicable paths, rationale, legitimate-use context, and recommended action.

Terminal explanation
repyy rules explain EXEC-001
Machine-readable explanation
repyy rules explain EXEC-001 --format json

For package indicators, explanation includes the active snapshot’s advisory source and affected-version context. A package name alone is a review signal; verify the resolved version and artifact before deciding.

Inspect the active intelligence

Built-in behavioral rules and the dated offline intelligence snapshot are separate inputs. The snapshot adds sourced package/version advisories and exact published file hashes.

Snapshot status
repyy intel status
Rules and sources
repyy rules list
JSON for tooling
repyy rules list --format json

Every report records the ruleset and intelligence snapshot used, so a finding can be audited later. Read the intelligence guide for update and rollback behavior.

A practical review workflow

1
Check coverage first

Look for SCAN INCOMPLETE, skipped dependency trees, archive warnings, and the snapshot date.

2
Start with blocking signals

Open high-confidence critical findings in executable, install-time, or CI code. Then review hardening and informational findings.

3
Read the surrounding evidence

Use the location, file role, match scope, rationale, and legitimate-use context. A rule hit is a prompt for inspection.

4
Choose a controlled next step

Ask the owner for context, continue in an isolated environment, or stop. Keep dependencies and target code unexecuted until review is complete.

Need the command-level details?

Return to the main documentation, or open the dedicated CLI reference and configuration guide.