feat: add varlock scan command for sensitive value leak detection

[Copilot]

Adds a new varlock scan CLI command that scans files to ensure none of your resolved sensitive config values appear in plaintext. Designed to be wired up as a git pre-commit hook.

Rather than relying on generic regex patterns like other secret scanners, varlock scan loads your varlock config, resolves all values, and then searches files for the actual literal values of items marked @sensitive. This means zero false positives and works for any type of secret — not just well-known formats.

Command options

• --staged — only scan staged files (primary git hook use case)
• --include-ignored — scan all files, including git-ignored ones (default skips ignored files via git ls-files -z)
• --path / -p — path to a specific .env file or directory ending with / to use as the schema entry point (default: cwd)

Exit code 1 when sensitive values are found in plaintext, making it drop-in compatible with git hooks.

How it works

1. Loads the varlock config via loadVarlockEnvGraph()
2. Resolves all config values
3. Collects all items where @sensitive is set and the resolved value is a non-empty string
4. Scans files for those exact values

Binary files (null bytes, common binary extensions) and build/dependency directories (node_modules, dist, .next, etc.) are skipped automatically.

Git hook setup

# .git/hooks/pre-commit
#!/bin/sh
varlock scan --staged

Sample output

🚨 Found 3 sensitive value(s) in plaintext across 2 file(s):

📂 config.js
  Line 2: API_SECRET
    const apiSecret = "my-real-secret-value-xyz";

📂 .env
  Line 2: API_SECRET
    API_SECRET="my-real-secret-value-xyz"

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Feature Request] secret scanner for git hook</issue_title>
<issue_description>### Description

Add a new varlock scan cli command which will scan files for plaintext secrets.

The idea here is that it could be wired up as a git hook.

Default behaviour can be to scan the current directory (and below) but we should have options. Also the default use case is to be ensuring no plaintext secrets will be committed to git, so we can ignore git-ignored files. But there is another use case to ensure nothing is in plaintext, so this can be an option.

We may also want to consider an option to scan all files, versus only scanning committed files or even just committed changes.

Motivation

No response

Proposed Solution

No response

Alternatives

No response

Additional Information

No response</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [Feature Request] secret scanner for git hook #315

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[changeset-bot]

⚠️ No Changeset found

Latest commit: f82dd70

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[theoephraim]

@copilot - the point of this is that we know the actual secret values to look for and dont have to resort to looking for patterns like other tools do. We should resolve the config and then look for any sensitive values.

[Copilot]

@copilot - the point of this is that we know the actual secret values to look for and dont have to resort to looking for patterns like other tools do. We should resolve the config ...

Reworked in f82dd70. The scan command now loads the varlock config via loadVarlockEnvGraph(), resolves all values, then scans files for the actual resolved values of @sensitive-marked items — no regex patterns needed. This gives zero false positives and catches any secret type, not just well-known formats. When a leak is found, it reports the env var key name so it's clear which secret leaked.

[philmillman]

Looks good to me at first glance. We may want some sort of skip pattern to explicitly exclude files outside of the staged/ignored affordances we already have. But that might be overkill too.