Skip to main content

Review: GitGuardian's State of Secrets Sprawl 2026 Turned into Secret-Handling Guardrails for Drupal and WordPress Teams Using AI Coding Tools, CI/CD, and Hosting Platforms

· 8 min read
Victor Jimenez
Victor Jimenez
Software Engineer & AI Agent Builder

GitGuardian's State of Secrets Sprawl 2026 is not really a report about "developers making mistakes." It is a report about credential volume outrunning governance. For Drupal agencies, WordPress product teams, and mixed CMS platform groups now using AI coding tools, that distinction matters.

My read is simple: if your Drupal or WordPress workflow still treats secrets as repo-level variables plus a scanner in CI, you are behind the threat model described in the report.

The Signals That Matter Most​

GitGuardian's report page, published on March 17, 2026, highlights several numbers that should change how CMS teams operate:

  • 28,649,024 new secrets were detected in public GitHub commits in 2025, up 34% year over year.
  • AI-assisted commits leaked secrets at roughly 2x the baseline across public GitHub commits.
  • GitGuardian found 24,008 unique secrets in MCP configuration files.
  • Internal repositories were 6x more likely than public repositories to contain hardcoded secrets.
  • About 28% of secrets sprawl happened outside code repositories, in collaboration or productivity tooling.
  • Of valid secrets first seen in 2022, 64% were still active four years later.

For Drupal and WordPress teams, those numbers point to one conclusion: secret handling has to become a workflow control system, not a scanning afterthought.

What This Changes for Drupal and WordPress​

The CMS angle is not hypothetical.

  • Drupal teams routinely keep environment-specific values outside config/sync, but many still let API keys, DSNs, and integration tokens drift into settings*.php, local override files, install docs, or agent config.
  • WordPress teams often avoid committing production credentials, but then reintroduce risk through wp-config.php edits, plugin settings exports, local .env files, deployment scripts, and screenshot-driven support workflows.
  • Both ecosystems increasingly use AI assistants, MCP servers, GitHub Actions, hosting dashboards, and shared staging environments. That creates more service tokens, more machine identities, and more places for leakage to occur.

The report is best understood as a warning that your secret boundary is no longer just "the repo." It is the whole delivery path: workstation, AI tool config, CI runner, host, ticketing system, and support chat.

Concrete Guardrails​

1. Treat AI tool configuration as secret-bearing infrastructure​

This is the most immediate change. If your team uses Claude Code, Cursor, MCP servers, OpenAI-compatible proxies, search APIs, or scraping tools, assume those configs will accumulate real credentials.

Guardrails:

  • Ban plaintext secrets in committed MCP or agent config files such as .mcp.json, .cursor/*, claude_desktop_config.json, and repo-level AI helper scripts.
  • Require AI tools to read credentials from host-managed environment variables or short-lived brokered tokens, not inline JSON.
  • Create a dedicated review rule for changes touching AI tool config, the same way you would review workflow files.
  • Add secret scanning coverage for agent config directories, not only src/ and config/.

Drupal/WordPress implication:

  • If a Drupal maintainer keeps a local MCP server that can query production content or a WordPress team wires AI tooling to WooCommerce, CRM, or search APIs, those access paths now belong inside the same control perimeter as deploy credentials.

2. Keep secrets out of CMS configuration exports entirely​

This should already be standard, but the report's leak-growth numbers make partial compliance inadequate.

Guardrails:

  • For Drupal, keep secrets in environment-backed settings layers, never in config/sync, install profiles, recipes, or exported YAML.
  • For WordPress, inject secrets through environment-backed constants in wp-config.php or the host platform's secret store, never through committed plugin defaults or serialized exports.
  • Reject pull requests that add credential-shaped values to example configs, README snippets, shell commands, or test fixtures.

My inference from the report is that teams lose this battle less through one big mistake than through repeated "temporary" exceptions.

3. Move CI/CD away from long-lived deploy secrets​

The report argues that workstation theft and CI/CD exposure are both major parts of the problem. For Drupal and WordPress teams, that means static deploy keys in GitHub Actions secrets are now a legacy pattern, not a mature one.

Guardrails:

  • Prefer OIDC or equivalent short-lived federation for cloud and artifact access instead of long-lived secrets stored in CI.
  • Scope environment secrets to the exact deployment environment and approval boundary that needs them.
  • Use ephemeral runners for sensitive jobs where possible; if you must use self-hosted runners, keep them single-purpose and aggressively recycled.
  • Separate build, test, and deploy identities so a compromised lint job cannot also publish or deploy.

Drupal/WordPress implication:

  • The same repo may build a Drupal distribution, push a WordPress plugin ZIP, deploy to a host, and hit purge or search APIs. Those should not all share one token or one runner identity.

4. Treat hosting platforms as secret authorities, not convenience vaults​

The report's main lesson is governance, not storage. A secret store without rotation discipline is just a better hiding place for long-lived credentials.

Guardrails:

  • Keep production credentials in the hosting platform or cloud secret manager, not in git, not in copied .env files, and not in team wiki pages.
  • Separate production, staging, and preview credentials by environment and by capability.
  • Eliminate shared "super tokens" that can read databases, flush caches, deploy code, and call third-party APIs at once.
  • Record who owns each secret, what it unlocks, and what breaks when it rotates.

For Drupal and WordPress teams on Pantheon, Acquia, Platform.sh, WP Engine, VIP, or container platforms, the question is not "do we have env vars?" The question is whether each secret has clear ownership, scope, and rotation history.

5. Scan outside repositories because the report says the leaks are there​

One of the most important findings is that about one quarter of leaks originate outside source code repositories.

Guardrails:

  • Add scanning or review controls for tickets, docs, paste tools, chat exports, CI logs, and support runbooks.
  • Prohibit posting full connection strings, bearer tokens, or signed URLs in issue trackers.
  • Redact secrets from screenshots and screen recordings used for Drupal admin or WordPress dashboard support.
  • Treat generated debug bundles and database migration notes as sensitive artifacts.

This is especially relevant in CMS work because operational troubleshooting often happens in screenshots, copied SQL snippets, and "quick fix" support threads.

6. Stop prioritizing only secrets that are easy to validate​

GitGuardian says 46% of critical leaked secrets lack validation checkers. That matters because Drupal and WordPress teams often give lowest priority to vague-looking passwords, private keys, or generic tokens if a scanner cannot confirm live validity.

Guardrails:

  • Triage by exposure path, privilege, environment, and blast radius, not only by whether a detector can validate the credential.
  • Treat database connection strings, SSH keys, private keys, generic bearer tokens, and signing material as high-risk even when automated validation is unavailable.
  • Build incident runbooks around "what can this unlock?" rather than "did the scanner prove it works?"

7. Make rotation an SLA, not an aspiration​

The report's most uncomfortable data point may be the remediation failure: many exposed secrets remain usable for years.

Guardrails:

  • Define rotation SLAs by secret class: production deploy credentials, database access, third-party SaaS tokens, AI provider keys, and internal service identities.
  • Require a named owner and replacement plan before any new secret is issued.
  • Maintain a break-glass path for urgent deploys, but log it and expire it fast.
  • Measure mean time to rotate after exposure, not just number of incidents opened.

For Drupal and WordPress teams, this is where most "we scan already" programs fail. They detect, create a ticket, and then keep shipping on the same credential.

A Practical Baseline for CMS Teams This Quarter​

If I had to turn the report into a minimum baseline for a Drupal or WordPress engineering team this quarter, it would be:

  1. No plaintext secrets in repo-tracked AI or MCP configuration.
  2. No secrets in Drupal config exports or WordPress plugin/theme defaults.
  3. Secret scanning on commits, pull requests, workflow files, and AI config directories.
  4. Short-lived CI deploy identity wherever the platform supports it.
  5. Environment-separated secrets for preview, staging, and production.
  6. Secret review coverage for tickets, docs, screenshots, and CI logs.
  7. Rotation SLAs with named ownership for every production-grade credential.

That baseline is not "enterprise gold plating." It is the minimum credible response to a world where AI-assisted commits are increasing leak rates, internal repos are dense with secrets, and MCP files are already becoming a new leak category.

Bottom Line​

GitGuardian's 2026 report is useful because it forces the right architectural conclusion: secrets sprawl is now a systems problem spanning AI tooling, CI/CD, collaboration software, and hosting.

For Drupal and WordPress teams, the actionable takeaway is not merely "install secret scanning." It is:

  • remove secrets from agent configs,
  • keep CMS config exports clean,
  • replace long-lived CI credentials,
  • enforce environment separation on hosts,
  • scan beyond code,
  • and measure rotation speed as aggressively as you measure build health.

Anything less is still treating secrets as isolated mistakes in a workflow that now mass-produces them.

References​