Repository security

Repository security scans the git repositories on your team's computers for vulnerable dependencies and leaked secrets, under one policy you set on the server. Git hooks and CI enforce the policy, and the server shows a report for every repository. Source code and secret values never leave the computer.

Repository security is on the Enterprise plan, and in the 30-day trial. Saving a policy needs it.

How it works

It runs on each computer, because it reads local files: a client, or a server's own machine.
The server holds one scanning policy. Computers follow it while their managed setting Repository security is on.
It's driven by MCP tools in the AI tools, the spandock reposcan command, git hooks and CI.
What reaches the server is a report with counts, advisories and secret fingerprints.

Turn it on

On the server's dashboard, open Safety & compliance → Repository security → Policy and save a policy.
Under People & computers → Computers → Client defaults, or in one computer's settings, set Repository security:
- Recommended: the policy applies, and SpanDock's MCP tools are added to the computer's AI tools. Git hooks and CI only warn.
- Enforced: the same, and SpanDock's git hooks and spandock reposcan ci block as the policy says.
- Off (the default): no policy and no reports.
Computers apply the change within a minute, and their reports appear under Repositories.

The policy

Setting	What it does	Default
Require a scan before commit or push	The pre-commit or pre-push hook checks the latest scan	Off
Maximum report age	A hook or CI accepts a scan at most this old	24 hours
Required scanners	A required scanner that can't run makes the scan partial	None
Scan git history	Also scan every commit's added lines for secrets	Off
CVE severity that blocks	Critical, high, medium, low or none	High
Secrets that block	Any finding, verified only, or none	Any
Timeout	30 to 3,600 seconds for the whole scan	600
When a scan can't finish	Open allows a partial or failed scan with a warning; closed blocks it	Open
Permit provider verification	A found credential may be sent to its own provider to check it	Off
Code-quality rules	Lint, test coverage, complexity, file size and comment ratio, each off, warn or block	Off

Options only make a scan stricter. An AI tool, the command line or CI can add requirements, but never relax the policy: a weaker option is refused with the reason, and the scan doesn't run. Every save is a new policy version, and a report made under an older version doesn't satisfy hooks or CI until the repository is scanned again.

Actions on repositories decide, for SpanDock's git hooks, scans, code quality and the policy file, whether computers do it themselves (Enforce), only suggest it (Suggest) or neither (Off). Enforced actions are labelled Required by your administrator, and a computer can't weaken them.

What blocks and what only advises

Control	Blocking?
MCP tools refusing weaker options	Yes, for scans started through SpanDock
Git hooks in enforced mode	Yes, on that computer, when the latest scan is missing, too old, under an older policy, incomplete (when the policy fails closed) or above the thresholds
Git hooks in recommended mode	No: they say why and let the commit or push through
`spandock reposcan ci` in enforced mode, or with `--enforce`	Yes: exit status 1
"Scan when a session starts"	No: the AI tools are asked to scan, but nothing enforces it

Git hooks are a local control that a developer can skip (git commit --no-verify). CI is the control they can't skip.

Git hooks and the policy file

With the hooks action set to Enforce, each computer installs the hooks the policy requires in every repository that reports to SpanDock there: one scanned on that computer, or one whose folder its AI tools' telemetry named. Only git repositories inside the person's home folder qualify, and the disk is never searched.

An existing hook is kept and run first.
A repository that uses another hook manager (husky, lefthook, pre-commit), a hooks folder outside the repository, and a hook the person installed themselves are left alone. The Hooks tab says why.
Turning the setting off removes exactly the hooks SpanDock installed and puts back what they wrapped.

The policy file, .spandock/repo-policy.json, is kept in those repositories while the policy file action is on Enforce. A file someone edited is kept and no longer updated, and SpanDock never commits it. Commit it yourself so CI uses it. Download policy file on the Policy tab, and spandock reposcan policy export, give the same file.

From an AI tool or a terminal

While the setting is on, ask the AI tool to scan the repository it's working in. The security_* MCP tools start a scan, report its progress, return the report and say whether the repository meets the policy. They run on the computer and are never served over the tunnel, so the server can't make a computer scan.

spandock reposcan scan --path .          # scan now
spandock reposcan check --path .         # what the hooks run
spandock reposcan install-hooks --path . # pre-commit and pre-push
spandock reposcan remove-hooks --path .  # restores hooks they wrapped

In CI

- run: spandock reposcan ci --path . --policy .spandock/repo-policy.json --enforce --history

ci scans, prints the result and exits with status 1 when an enforced policy isn't met. In CI, reports stay in the job.

What a scan collects

Size: files, folders and bytes; code, comment and blank lines per language.
Frameworks and tooling, detected from manifests and file names.
Git: branches and tags, contributors by name only, the last 200 commits (hash, time, author name, subject with secrets redacted) and the remote, sanitised to host/org/repo.
AI tool files such as CLAUDE.md, AGENTS.md, GEMINI.md, Cursor rules, Copilot instructions and .mcp.json: by path, tool and hash, never their text.
Dependency vulnerabilities, from lockfiles for npm, Yarn, pnpm, Python, Cargo, Go, Composer, Bundler and Gradle, looked up in the OSV database. Each finding has its identifiers, severity, fixed versions and an upgrade command.
Secrets, with TruffleHog when it's installed, or the built-in scanner otherwise. Only the detector, path and line, severity, verification state and a one-way fingerprint are kept.

A report is clean only when the scan is complete with no advisories and no secret findings. A partial, failed or timed-out scan always says "not clean".

What never leaves the computer

Source code and secret values. A secret never appears in a report, a log, the queue or the server's database.
Commit email addresses, credentials and local folder paths.
The OSV lookup sees package names, versions and ecosystems only. Turn it off in the policy for private package names; the vulnerability check is then partial.
Provider verification is off by default: it sends a found credential to its provider, so it runs only when the policy permits it.

Reports are sent to the server over the encrypted tunnel and kept for 400 days. Changing the policy needs an administrator and is recorded in the audit log.

Limits

Maven pom.xml has no lockfile, so those dependencies aren't looked up, and the scan is partial.
The built-in secret scanner is a fallback: fewer detectors than TruffleHog, and no verification.
Satellites' own machines keep their reports locally; reports from their clients reach the hub.
Older computers ignore the code-quality rules and the automatic hooks.