# Secret Scanning With Gitleaks

Open Orchestra uses Gitleaks as the primary repository secret-scanning gate.
The lightweight Node scanner remains as a local fallback when the `gitleaks`
binary is not installed.

## Local Use

```bash
npm run secret-scan
```

When `gitleaks` is available on `PATH`, the command runs:

```bash
gitleaks dir . --config .gitleaks.toml --redact --no-banner
```

When the binary is unavailable, the fallback scanner checks common private key,
cloud key, token, password, and API key patterns so offline development still
has a minimum guardrail.

## CI

The CI quality job installs the pinned Gitleaks binary and runs it before the
precommit gate. The precommit gate then calls `npm run secret-scan`, which uses
the same Gitleaks configuration in CI because the binary is already installed.

## Configuration

Rules live in `.gitleaks.toml` and extend the default Gitleaks ruleset.
Allowlists are limited to generated/dependency paths and explicit placeholder
values such as `<secret>` or GitHub Actions `${{ secrets.NAME }}` references.

Do not allowlist real secrets. Rotate and purge the secret instead.

## Operational SaaS Boundary

Repository scanning is not enough for a SaaS/runtime deployment. Runtime inputs
also need secret and prompt-injection guardrails before agents or providers can
read them:

- prompts
- lessons learned
- evidence
- logs
- uploaded artifacts
- model outputs
- GitHub issue bodies and comments
- tenant integrations

Operational scans must redact or quarantine findings, record provenance, and
apply tenant-specific retention and regulatory policies.