Secret Detection

Vetrix scans every push for accidentally committed secrets — API keys, private keys, passwords, and tokens. Detected secrets are flagged before they can spread in history.

How it works

On each push, Vetrix inspects the diff of every new commit against a library of ~150 regex patterns covering common secret formats. Detection runs server-side before refs are updated, so pushes containing known-secret patterns can be blocked before they are written.

Blocked push (pre-receive)

When secret detection is in blocking mode and a secret is found, the push is rejected:

remote: ERROR: Secret detected in commit a1b2c3d4
remote:
remote:   File:    config/database.yml (line 12)
remote:   Type:    AWS Access Key
remote:   Pattern: AKIA[0-9A-Z]{16}
remote:
remote: To override: git push --push-option=vetrix.allow-secrets
remote: (requires 'maintain' role — recorded in audit log)

Non-blocking mode

When configured to warn, the push succeeds but findings appear in the pipeline and Security tab.

Set the mode per-instance via admin settings:

# Block pushes with detected secrets
curl -X PUT https://<vetrix-host>/api/v1/admin/settings/security.secret_detection_mode \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '"block"'

# Warn only
curl -X PUT https://<vetrix-host>/api/v1/admin/settings/security.secret_detection_mode \
  -H "Authorization: Bearer <admin-token>" \
  -d '"warn"'

# Disable
curl -X PUT https://<vetrix-host>/api/v1/admin/settings/security.secret_detection_mode \
  -H "Authorization: Bearer <admin-token>" \
  -d '"off"'

Supported secret types

Category	Examples
Cloud provider keys	AWS, GCP, Azure, DigitalOcean
SCM tokens	GitHub, GitLab, Bitbucket
CI/CD tokens	CircleCI, Travis CI, Jenkins
Database connection strings	PostgreSQL, MySQL, MongoDB, Redis
Private keys	RSA, EC, OpenSSH, PGP
API keys (SaaS)	Stripe, Twilio, SendGrid, Slack, Mailgun
Generic patterns	High-entropy strings matching token formats

Remediation

If a secret was committed before blocking was enabled, or if a push was allowed via override:

1. Revoke the secret immediately. Assume it is compromised — it may have been indexed by bots.

2. Remove from git history:

   # Using git-filter-repo (recommended)
   pip install git-filter-repo
   git filter-repo --path config/database.yml --invert-paths
   
   # Or replace the value in history
   git filter-repo --replace-text <(echo 'AKIAIOSFODNN7EXAMPLE==>***REMOVED***')
   

3. Force-push the cleaned history. Requires admin bypass of branch protection.

4. Rotate all other secrets in the affected commits — bots often harvest entire files, not just the flagged token.

Allowlisting

To allow a specific pattern in a repository (e.g., test fixtures that look like secrets), add a .vetrix-secret-ignore file to the repo root:

# Each line is a regex matched against the full diff line
# Use sparingly — entries bypass scanning for that pattern

# Test fixture AWS key (not a real key)
AKIAIOSFODNN7EXAMPLE

Allowlist entries are scoped to the repository and require maintain role to add.

Audit trail

All secret detection events are written to the instance audit log:

• Push blocked due to secret detection
• Push allowed via --push-option=vetrix.allow-secrets override
• Allowlist entry added or removed