Harness Secrets

Secret detection, credential hygiene, and vault integration. Find exposed secrets, classify risk, and enforce externalization before they reach production.

When to Use

• When scanning source code for hardcoded secrets, API keys, or credentials
• When auditing environment variable hygiene and

  .env

  file management
• On PRs that modify configuration files or add new service integrations
• NOT for general application security review (use harness-security-review)
• NOT for infrastructure credential management (use harness-infrastructure-as-code)
• NOT for CI/CD secret injection (use harness-deployment)

Process

Phase 1: SCAN -- Detect Secrets in Source Code

1. Scan source files for secret patterns. Search for common secret formats:

   • API keys: Patterns matching

     sk-

     ,

     pk_

     ,

     AKIA

     ,

     AIza

     ,

     ghp_

     ,

     glpat-

     ,

     xoxb-

   • Connection strings: Database URIs with embedded credentials (

     postgres://user:pass@

     )
   • Private keys:

     -----BEGIN RSA PRIVATE KEY-----

     ,

     -----BEGIN EC PRIVATE KEY-----

   • JWT tokens: Base64-encoded strings matching

     eyJ

     header pattern
   • Generic secrets: Variables named

     password

     ,

     secret

     ,

     token

     ,

     api_key

     with literal string values

2. Scan configuration files. Check files that commonly contain secrets:

   • .env

     ,

     .env.local

     ,

     .env.production

     (should be gitignored)

   • config/*.json

     ,

     config/*.yaml

     with credential fields

   • docker-compose.yml

     with inline environment values

   • application.properties

     ,

     appsettings.json

     with connection strings
   • CI/CD pipeline files with hardcoded values

3. Check

   .gitignore

   coverage. Verify that sensitive files are excluded from version control:

   • .env*

     files (except

     .env.example

     )

   • *.pem

     ,

     *.key

     private key files

   • credentials/

     ,

     secrets/

     directories
   • Service account JSON files (

     *-credentials.json

     )
   • IDE-specific files that may cache environment variables

4. Scan git history for leaked secrets. Check recent commits:

   • Run

     git log --diff-filter=A --name-only

     for recently added files
   • Check if any

     .env

     or credential files were committed and later removed
   • Flag files that appear in git history but are now gitignored (the secret is still in history)

5. Present scan results:

   Secret Scan: 7 findings in 5 files
   
   CRITICAL (2):
     src/config/database.ts:8 -- Hardcoded PostgreSQL connection string with password
     src/services/stripe.ts:3 -- Stripe secret key (sk_example_...)
   
   HIGH (3):
     docker-compose.yml:15 -- MySQL root password in plaintext
     src/config/aws.ts:12 -- AWS access key pattern (AKIA...)
     .env.production:1 -- File committed to git (should be gitignored)
   
   MEDIUM (2):
     src/utils/auth.ts:45 -- JWT secret as string literal
     config/app.json:22 -- Generic "apiKey" field with literal value
   

Phase 2: CLASSIFY -- Categorize by Risk and Type

1. Assign severity levels. Classify each finding:

   • CRITICAL: Live production credentials, private keys, cloud provider access keys. Immediate rotation required.
   • HIGH: Secrets in committed files, database passwords, service API keys. Rotation strongly recommended.
   • MEDIUM: Development-only secrets in source, JWT signing keys, generic tokens. Should be externalized.
   • LOW: Example values that look like secrets but are placeholders (

     YOUR_API_KEY_HERE

     ), test-only credentials in test fixtures.

2. Identify secret type. Categorize each finding:

   • Cloud provider credentials (AWS, GCP, Azure)
   • Database credentials (connection strings, passwords)
   • Third-party API keys (Stripe, SendGrid, Twilio)
   • Authentication secrets (JWT keys, OAuth client secrets)
   • Encryption keys (symmetric keys, private keys)
   • Internal service tokens (inter-service auth)

3. Assess blast radius. For each CRITICAL and HIGH finding:

   • What systems does this credential access?
   • Is the credential scoped (read-only, limited permissions) or broad (admin)?
   • Is the credential shared across environments?
   • When was the credential last rotated?

4. Check for false positives. Verify findings are actual secrets:

   • Example/placeholder values in documentation
   • Test fixtures with fake credentials
   • Base64-encoded non-secret data matching JWT patterns
   • Hash values that match key patterns but are not keys

5. Generate classification report:

   Classification:
     CRITICAL: 2 (require immediate rotation)
     HIGH: 3 (require rotation within 24 hours)
     MEDIUM: 2 (require externalization)
     LOW: 0
     False positives: 1 (removed from findings)
   
   Affected systems:
     - PostgreSQL database (production)
     - Stripe payment processing
     - AWS S3 storage
   

Phase 3: REMEDIATE -- Extract and Secure Secrets

1. Recommend secret externalization. For each finding, provide the remediation:

   • Replace hardcoded value with environment variable reference
   • Add the variable to

     .env.example

     with a placeholder value
   • Add the actual value to the deployment secret store
   • Verify

     .gitignore

     includes the actual

     .env

     file

2. Recommend secret management integration. Based on the project's infrastructure:

   • HashiCorp Vault: Dynamic secrets, lease-based rotation, transit encryption
   • AWS Secrets Manager: Native AWS integration, automatic rotation for RDS
   • Google Secret Manager: GCP-native, IAM-based access control
   • Azure Key Vault: Azure-native, HSM-backed key storage
   • dotenv + CI secrets: Minimum viable approach for smaller projects

3. Recommend rotation procedure. For each CRITICAL and HIGH finding:

   • Generate a new credential in the source system
   • Update the secret store with the new value
   • Deploy the updated configuration
   • Verify the service works with the new credential
   • Revoke the old credential
   • Confirm no systems depend on the old credential

4. Provide code transformation examples. Show before/after for each finding:

   // BEFORE (hardcoded)
   const stripe = new Stripe('sk_example_abc123...');
   
   // AFTER (externalized)
   const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
   

5. If

   --fix

   flag is set, apply automatic transformations:
   • Extract hardcoded values to environment variables
   • Add

     .env.example

     entries with placeholder values
   • Update

     .gitignore

     if

     .env

     files are not excluded
   • Present the diff for review before committing

Phase 4: VALIDATE -- Verify Remediation Completeness

1. Re-scan after remediation. Run the same scan from Phase 1 to verify:

   • All CRITICAL and HIGH findings are resolved
   • No new secrets were introduced during remediation
   • Environment variable references resolve correctly

2. Verify

   .gitignore

   coverage. Confirm:
   • All

     .env

     files (except

     .env.example

     ) are gitignored
   • Private key files are gitignored
   • The gitignore patterns are specific enough (not overly broad)

3. Verify

   .env.example

   completeness. Check that:
   • Every environment variable referenced in code has an entry
   • Values are placeholders, not actual secrets
   • Each entry has a comment describing the variable's purpose
   • Required vs. optional variables are clearly marked

4. Check git history for residual exposure. If secrets were previously committed:

   • Warn that the secret exists in git history even after removal
   • Recommend

     git filter-repo

     or BFG Repo-Cleaner for history rewriting
   • Emphasize that rotation is required regardless of history cleanup
   • Note that force-push to remote may be required after history rewrite

5. Generate validation report:

   Secret Validation: [PASS/WARN/FAIL]
   
   Rescan: PASS (0 CRITICAL, 0 HIGH findings)
   .gitignore: PASS (all sensitive patterns covered)
   .env.example: WARN (missing STRIPE_WEBHOOK_SECRET entry)
   Git history: WARN (2 secrets exist in history -- rotation required)
   
   Actions remaining:
     1. Add STRIPE_WEBHOOK_SECRET to .env.example
     2. Rotate PostgreSQL password (exposed in commit abc1234)
     3. Rotate Stripe key (exposed in commit def5678)
     4. Consider git history rewrite after rotation
   

Harness Integration

• harness skill run harness-secrets

  -- Primary invocation for secret scanning and remediation.

• harness validate

  -- Run after remediation to verify project health.

• harness check-security

  -- Complementary mechanical security scan that includes basic secret detection.

• emit_interaction

  -- Present findings and gather decisions on remediation approach.

Success Criteria

• All source files are scanned for secret patterns
• Findings are classified by severity with accurate false-positive filtering
• CRITICAL and HIGH findings have specific rotation recommendations
• Environment variable externalization is verified

• .gitignore

  covers all sensitive file patterns

• .env.example

  is complete with placeholder values
• Git history exposure is flagged with rotation guidance

Examples

Example: Express.js API with Hardcoded Stripe Keys

Phase 1: SCAN
  Scanned: 86 files
  Findings: 4

  CRITICAL: src/payments/stripe.ts:5 -- sk_example_EXAMPLE_KEY_REDACTED_0000
  HIGH: docker-compose.yml:22 -- POSTGRES_PASSWORD=supersecret
  MEDIUM: src/config/jwt.ts:3 -- JWT_SECRET = "my-jwt-secret-key"
  LOW: tests/fixtures/auth.ts:8 -- fake-api-key-for-testing (false positive)

Phase 2: CLASSIFY
  CRITICAL: 1 (Stripe production secret key -- full payment access)
  HIGH: 1 (PostgreSQL password -- database access)
  MEDIUM: 1 (JWT secret -- token forgery risk)
  False positives: 1 (test fixture removed from findings)

Phase 3: REMEDIATE
  1. Stripe key -> process.env.STRIPE_SECRET_KEY
  2. Postgres password -> ${POSTGRES_PASSWORD} in compose, actual value in .env
  3. JWT secret -> process.env.JWT_SECRET
  Added 3 entries to .env.example
  Updated .gitignore with .env* pattern

Phase 4: VALIDATE
  Rescan: PASS (0 findings)
  .gitignore: PASS
  .env.example: PASS (all 3 variables documented)
  Git history: WARN (Stripe key in commit history)
  Result: WARN -- secrets externalized, rotation required for Stripe and Postgres

Example: Django Application with AWS Credentials

Phase 1: SCAN
  Scanned: 124 files
  Findings: 5

  CRITICAL: settings/production.py:45 -- AWS_ACCESS_KEY_ID = "AKIA..."
  CRITICAL: settings/production.py:46 -- AWS_SECRET_ACCESS_KEY = "wJal..."
  HIGH: .env.production committed to git (12 secrets inside)
  MEDIUM: settings/base.py:88 -- SECRET_KEY = "django-insecure-..."
  MEDIUM: settings/base.py:92 -- DATABASE_URL with embedded password

Phase 2: CLASSIFY
  CRITICAL: 2 (AWS IAM credentials -- full account access)
  HIGH: 1 (.env.production in git -- 12 leaked values)
  MEDIUM: 2 (Django secret key and database URL)

Phase 3: REMEDIATE
  1. AWS credentials -> boto3 credential chain (env vars or IAM role)
  2. Remove .env.production from git, add to .gitignore
  3. Django SECRET_KEY -> os.environ["DJANGO_SECRET_KEY"]
  4. DATABASE_URL -> os.environ["DATABASE_URL"]
  Recommend: Switch to django-environ for all settings
  Recommend: Use IAM roles instead of access keys for production

Phase 4: VALIDATE
  Rescan: PASS
  .gitignore: PASS
  .env.example: PASS
  Git history: CRITICAL (AWS keys and .env.production in history)
  Result: FAIL -- rotation required before deployment, history rewrite recommended

Rationalizations to Reject

git log -p

Gates

• No CRITICAL findings may remain unaddressed. Production credentials exposed in source code are blocking. Execution halts until the credential is rotated and the code is remediated.
• No

  .env

  files with actual secrets committed to git. A committed

  .env

  file containing real credentials is a blocking finding, even if the file is later gitignored.
• No secrets in git history without rotation. If a secret was previously committed, it must be rotated regardless of whether it was removed from the current tree.
• No remediation without verification. The

  --fix

  flag must be followed by a rescan to confirm all findings are resolved.

Escalation

• When a production credential is exposed in a public repository: This is an emergency. Immediately recommend rotating the credential, then address code remediation. Do not wait for a PR review cycle -- rotation must happen within minutes.
• When git history contains secrets and the repo is public: Recommend making the repo private temporarily, rotating all exposed credentials, running BFG Repo-Cleaner, and force-pushing. Note that GitHub caches may retain the data -- contact GitHub support if needed.
• When the team has no secret management infrastructure: Recommend starting with CI/CD platform secrets (GitHub Secrets, GitLab CI variables) as a minimum viable approach. Design a migration path to a dedicated secret manager for later.
• When false positive rate is high: Adjust scan patterns for the project's domain. Add a

  .harness/secret-scan-ignore

  file with documented exceptions for known false positives (test fixtures, example values, hash constants).