Secret and PII scanning
belongs in the IDE.

Why CI/CD secret scanning is too late

This is the uncomfortable truth about CI/CD-only secret scanning: even if the pipeline catches a secret and blocks the merge, the secret has already been committed to the developer's local repository, pushed to the remote origin, and is now visible to anyone with repository access — including CI runners, log aggregation, and anyone who cloned during that window.

The scenario plays out constantly in practice:

1. Developer commits a file containing an API key (accidentally, or "just for testing")
2. Pushes to a feature branch
3. CI detects the secret, fails the pipeline
4. Developer removes the secret and force-pushes — but the original commit is in the remote's reflog
5. Key is now compromised, must be rotated regardless

Git history is (effectively) permanent

Developers believe that deleting a file or using git rebase removes a secret from history. It does not. Git is designed for immutability — every object is content-addressed by its SHA-1/SHA-256 hash.

• git rm removes the file from the working tree but not from the commit that added it
• git rebase -i rewrites history locally but does not affect any remote clones or forks
• Force push rewrites the remote branch, but GitHub/GitLab retain the original objects in reflog for weeks
• Any user who cloned or fetched during the exposure window has a local copy

PII vs secrets: different risks, same prevention

Secrets (API keys, tokens, private keys) and PII (names, emails, phone numbers, SSNs) require the same prevention control — detect before commit — but for different reasons:

• Secrets: Security risk. A leaked API key gives an attacker direct access to your infrastructure, accounts, or data.
• PII in code or config: Compliance risk. Real customer data in test fixtures, hardcoded in migrations, or committed in log samples is a GDPR/CCPA violation regardless of whether the repository is private.

IDE scanning: catch secrets as you type

IDE-level secret detection fires when a high-entropy string or known credential pattern is written to a file — before it is staged or committed. Tools with IDE support:

• AquilaX IDE extension: Real-time secret detection with pattern matching for 500+ credential formats (AWS keys, GitHub tokens, Stripe keys, SSH private keys, etc.)
• GitGuardian VS Code extension: Highlights secrets inline as you type
• SonarLint: Detects hardcoded credentials across 15+ languages

Pre-commit hooks: the essential second layer

Even with IDE scanning, pre-commit hooks are essential. Not all developers use the IDE extension; some edit files outside the IDE; some use automated tools that generate files. A pre-commit hook is a local Git hook that runs before every commit and blocks commits that contain secrets.

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks

  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

# Install pre-commit framework
pip install pre-commit

# Install hooks from .pre-commit-config.yaml
pre-commit install

# Test on all files (first-time run)
pre-commit run --all-files

# Enforce via CI if a developer bypasses locally
# Run in pipeline: pre-commit run --all-files

CI/CD scanning: the necessary backstop

Pre-commit hooks can be bypassed with git commit --no-verify. IDE scanning is optional. CI/CD scanning is the enforcement layer that cannot be bypassed by individual developers — it is the backstop, not the primary prevention control.

Run secret scanning in CI with full history scanning on every push:

- name: Full history secret scan
  uses: gitleaks/gitleaks-action@v2
  with:
    config-path: .gitleaks.toml
  env:
    GITHUB_TOKEN: ${{{ secrets.GITHUB_TOKEN }}}
    GITLEAKS_LICENSE: ${{{ secrets.GITLEAKS_LICENSE }}}

Compliance implications: GDPR and SOC 2

For organisations subject to GDPR, CCPA, or SOC 2, PII in a repository is not just a security problem — it is a compliance event that may require notification to regulators and affected individuals.

• GDPR Article 33: Personal data breaches must be reported to supervisory authorities within 72 hours. PII committed to a repository and exposed to CI systems or external collaborators may qualify.
• SOC 2 CC6.7: Requires controls to prevent unauthorised disclosure of sensitive data. Pre-commit PII scanning is a demonstrable preventive control.
• Evidence for auditors: Pre-commit hook configuration, CI scanning job logs, and AquilaX scanning history all serve as audit evidence that preventive controls exist.