VNX-SEC-072: Generic high-entropy API key / secret

Detects high-entropy literals (20+ characters, letters and digits) assigned to a name that ends in a credential word such as api_key, secret, token or password.

Field	Value
Rule ID	`VNX-SEC-072`
Severity	High
SARIF level	`error`
Kind	`secrets`
Languages	Any file
CWE	CWE-798
CAPEC	CAPEC-191
ATT&CK	T1552.001
CWSS vector	`CWSS:1.0/TI:H/AP:A/AL:A/IC:N/FC:LT/RP:N/RL:A/AV:I/AS:N/IN:A/SC:A/BI:H/DI:H/EX:H/EC:N/P:H`
Tags	`secrets` `generic` `high-entropy` `credentials`
Source	`internal/sast/rules/vnx-sec-072.rego`

Overview

This rule reports a literal assigned to a name that ends in a credential word (api_key/apiKey, secret, secret_key, client_secret, token, access_token, password, passwd, credentials, creds, private_key, access_key): an assignment, constant, object or JSON key, keyword argument, typed declaration (Go string, TypeScript : string, Kotlin/Swift : String, Rust : &str) or XML setting (<add key="PaymentApiKey" value="..."/>, Android <string name="maps_api_key">) whose quoted value (or unquoted value in .env, YAML, .properties, .ini, .conf and .cfg files) is at least 20 token characters, mixes letters and digits, and has Shannon entropy of at least 3.5. The value is masked in the snippet.

It does not report values read from the environment or configuration, names that only contain a credential word (TOKEN_URL, passwordField, secretName, tokenizer, nextPageToken), comparisons, placeholders and low-entropy values (YOUR_API_KEY..., 0000..., changeme, word phrases), dotted identifiers, lowercase word lists, sha256- integrity hashes, lowercase secret-store paths (projects/p/secrets/db-password/versions/3), comment lines, prose and HTML files, examples/, samples/, demo/ and docs/ directories, and test, fixture, vendored and generated files.

What Gets Flagged

API_KEY = "<40 random letters and digits>"

service:
  api_key: <40 random letters and digits>

Not flagged:

API_KEY = os.environ["API_KEY"]
TOKEN_URL = "https://auth.acme-corp.io/oauth2/v3/token"

Why This Matters

Hardcoded generic high-entropy api key / secret values are routinely scraped by automated bots within minutes of a public push, and then used to access the account, exfiltrate data, or pivot into downstream services. Once the credential is in git history it is permanently in third-party hands.

Remediation

Revoke the leaked credential in the provider’s console immediately.
Replace with a short-lived alternative, OAuth 2.0 access tokens, IAM role assumption, OIDC federation, wherever the platform supports it.
Store the new credential in a secrets manager (AWS Secrets Manager, HashiCorp Vault, GitHub Actions secrets, Doppler).
Audit the provider’s access logs for activity you did not initiate between the leak and the revocation.
Purge from git history with git filter-repo or BFG, then re-scan with gitleaks/truffleHog to confirm no other secrets remain.
Enable push protection so future commits are blocked at the developer machine.

References

Suppressing this rule

Put a nosec comment on the line, or on line 1 to cover the whole file. Use the comment marker of the file’s language (#, //, -- or ;):

# nosec vnx-sec-072
// nosec vnx-sec-072

Or record an ignore rule: vulnetix ignore add --rule vnx-sec-072 --reason "...". See Suppressing findings.