Understand the boundary.Inspect the evidence.

Security model

Repository files, filenames, configuration, archives, Git metadata and source-derived report values are untrusted input. The scanner reads them as data. It does not intentionally import, install, build, test or run assignment code. It does not compute a complete runtime call graph. Findings describe observable patterns, not proof that a behavior occurred.

The trusted computing base includes the Repyy executable, its dependencies, operating system, explicitly supplied rules, and tools used for retrieval or isolation. Host Git, SSH and Docker are capabilities with their own attack surfaces. A malicious repository may attack parsers, consume resources, disguise content, exploit race conditions, or attempt output injection. Review tests and known limitations below before relying on this boundary.

What Repyy reads

Repyy inspects regular files within the selected repository, selected Git metadata and bounded archive entries. It reads manifests without invoking package managers. Dependency/cache directories are excluded by default; --include-dependencies expands that scope. Explicit trusted configuration can add rules and suppressions. Do not use a rules file supplied by the assignment as trusted configuration.

The local target root is resolved before inspection and file reads use a confined filesystem root. Symlinks and archive paths receive additional checks. Archive contents are inspected in memory rather than extracted into a working installation. These controls reduce exposure; they do not prove every parser or operating-system boundary is flawless.

What Repyy does not execute

Normal scan paths do not invoke target scripts, hooks, build systems, test runners, Docker Compose, package managers or IDEs. Host remote scans invoke Git clone and revision lookup; Docker mode invokes the Docker client, container Git and the Repyy worker. Windows report-file permission setup may invoke icacls. These are trusted host tools, not assignment commands.

Source: repository preparation,scanner,Docker boundary.

Network behavior

This table describes implementation behavior, not a firewall guarantee for the host process. No scan feature uploads assignment contents or scan reports to a Repyy service.

The website links to third-party evidence. Opening those links contacts their operators. CLI privacy claims do not describe those external sites.

Local data handling

Local scans keep source in place. Reports go to stdout or the requested output path and can contain sensitive filenames, repository identity and redacted evidence. Redaction is pattern-based, not a guarantee that arbitrary secrets are removed. Treat reports as sensitive and review before sharing. No telemetry client or report-upload path is implemented in the normal scanner.

Intelligence snapshots and active/previous pointers are stored in the local cache. Invalid or older cached intelligence falls back to embedded data with a warning. Updates require a valid signature and schema; rollback uses previously verified local snapshots. See theintelligence guide.

Temporary repositories and cleanup

Host remotes use a private repyy-clone-* temporary directory. Git hooks/templates, recursive submodules, redirects, system/global Git configuration and unrequested Git protocols are disabled. Default history depth is one. --keep-workdir deliberately retains host checkouts. Otherwise cleanup is deferred; clone/revision failures also attempt removal.

Git acquisition has a timeout but no byte, pack, file-count, or disk quota before checkout. Scanner file limits begin after retrieval and do not protect temporary checkout storage. Clone failures are reported as incomplete targets.

Docker remotes use a private repyy-sandbox-* parent with a writable fetch child, followed by a read-only scan mount. Provider tokens use a separate mode-0600 temporary env file. Timed-out containers receive a bounded forced-removal attempt.

Checkout deletion failures are reported: successful host/Docker scans retain their findings but become incomplete with a cleanup warning; preparation failures include a cleanup error when deletion also fails. Token-file deletion and forced-container removal failures also return errors. Remaining boundary: abrupt termination or a Docker daemon failure can leave files or containers behind before those errors can be reported. Cleanup is best effort, not secure erasure. Review temporary storage after an interrupted private scan.

Host-mode boundaries

Host mode is the default. Remote scans use installed Git and, for SSH, host SSH configuration/agents. Git configuration is filtered, but the process still inherits other host environment and OS capabilities. Updating Git and SSH and choosing an appropriate isolation environment remain the user's responsibility. A local static scan does not turn the host into a malware sandbox.

Docker-mode boundaries

The image must be digest-pinned and explicitly available locally. Repyy requests read-only input/root filesystems, dropped capabilities, no-new-privileges, process/memory/CPU limits and bounded temporary storage. Remote fetch and scan are separate stages. Docker daemon access itself is a powerful host capability. Containers share a kernel and are not equivalent to a dedicated virtual machine. Seeisolation.

Incomplete scans and exit codes

Exit 0 means completed without a finding at the selected failure threshold. It can include lower-severity findings. Exit 1 means the threshold was reached. Exit 2 means an operational failure or incomplete scan and takes priority over findings. Exit 3 means invalid invocation/input. Display filters do not change the exit policy. See CLI reference.

Unsupported formats, deliberate exclusions and static resolution limits differ from operational incompleteness. Review coverage warnings and exclusions even when the scan completes. Never interpret an empty result or exit 0 as proof of safety.

Static-analysis limitations

Static analysis can miss malicious behavior and flag legitimate code. Dynamic imports, generated code, encrypted content and runtime state may be unresolved. A filename, signature or suspicious string alone does not establish malicious intent. Inspect the evidence and ask the sender for context. The inert sample benchmark versions its expectations and keeps misses and expectation corrections visible.

Claim-to-evidence map

Evidence files and named tests are browsable in the public source tree. Check the release tag or exact commit when assessing an older binary.

Releases, security testing and reviews

Read release verification, security testing, and theexternal-review brief. See the verification guide for current CodeQL, Scorecard and attestation evidence status. No independent-audit badge is claimed.

Report vulnerabilities privately using GitHub vulnerability reporting. Include version, OS, impact and the smallest inert reproduction. Do not send working credentials or private assignment source. Seesecurity policy.