feat(SAFE-T1206): added [Credential Implant in Config]

[Ajao-Victor]

ADD SAFE-T1206 [Credential Implant in Config]

Brief description of what this PR adds/changes:
Add Detection Rule + Test Suite for Credential Implant in Config (MCP Supply‑Chain Attack)

Updates involved in this PR

1. Attack Technique Documented

This PR documents and implements detection logic for a supply‑chain attack technique known as Credential Implant in Config.

This technique occurs when an attacker secretly embeds API keys, access tokens, private keys, or other sensitive credentials into:

MCP configuration files (e.g., mcp_config.json, provider manifests)

Git commits or CI pipelines

Provider endpoint configuration

Runtime environments or secret mounts

The goal of the attacker is to subvert trust boundaries by inserting persistent credentials that grant unauthorized access to MCP capabilities or remote resources. This can enable lateral movement, data exfiltration, or impersonation of trusted components.

2. Why This Technique Is Relevant to MCP Security

MCP (Model Context Protocol) environments rely heavily on:

Signed configuration artifacts

Trusted provider manifests

CI/CD pipelines

Secure runtime secret provisioning

If any attacker implants credentials inside these configurations:

MCP clients or servers may unknowingly send privileged requests to attacker-controlled endpoints

Providers can be hijacked or spoofed

Runtime secrets can be misused for unauthorized operations

Trust boundaries (author verification, signed artifacts, allowed endpoints) collapse

Because MCP operates through structured config artifacts and extensible providers, a single implanted credential becomes a systemic compromise, similar to how supply‑chain attacks hit npm, Homebrew, and PyPI ecosystem packages.

Thus, detecting credential implants early is essential for maintaining:

Provider integrity

Endpoint authenticity

CI pipeline trust

Secure secret lifecycle

3. Research Conducted

To implement accurate detection and testing, I conducted structured research across:

🔹 MCP configuration & provider architecture

Understanding how:

Configs are loaded

Provider manifests define endpoints

Runtime secret provisioning works

Signature validation is performed

🔹 Known real‑world supply‑chain incidents

Studied similar attacks in:

CI/CD compromise (e.g., Codecov Bash uploader breach)

Credential leaks in config files (e.g., Uber 2016 AWS keys leak)

Provider endpoint swapping

Git signature bypass attacks

Runtime secret injection vulnerabilities in Kubernetes, AWS Lambda, GitHub Actions

Although not MCP‑specific, these attacks expose identical trust boundaries.

🔹 Analysis of common indicators of config‑based compromise

The rule detects:

Unauthorized writes to MCP config artifacts

Unverified authors modifying provider endpoints

Signature/hash failures on config load

Secret injection without approval

Permission escalation in manifests

This analysis informed the structure of both the detection rule and the test scenarios.

🔹 Test Coverage & Rule Behavior

Created a full test suite covering:

Malicious scenarios:

Unauthorized config write with secret diff

Provider endpoint swap in unverified commit

Runtime plaintext secret mount

Permission escalation in manifest

Benign scenarios:

Signed config reload

Benign static secret in repo with verified author

Also implemented performance testing at scale (2,000+ events).

Questions or Feedback section

I would appreciate feedback on:

A.Threat model alignment

Are these detection heuristics aligned with the official MCP threat model and provider trust boundaries?

B. Scope of secret detection

Should we expand secret‑indicator patterns (e.g., regex‑based entropy detection)?
Or keep it minimal to prevent false positives?

C. Runtime secret logic

Should the detection consider source of secrets (e.g., Vault, SSM, Kubernetes Secrets), or is approval‑ticket logic sufficient?

D. Provider endpoint validation

Should endpoint changes require stricter validation (e.g., domain allowlists, certificate pinning)?

CONTRIBUTOR : Victor Oluwatimileyin AJAO [ Victoroluwatimileyin3@gmail.com ]