VNX-SEC-060: Airtable personal access token

Reports a hard-coded Airtable personal access token (pat + 14 alphanumerics + . + 64 hex) or a legacy key-prefixed API key when Airtable is named on that line or up to three code lines above it, but not placeholders, ordinary key-prefixed identifiers or tokens read from the environment.

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

Overview

This rule reports an Airtable credential written into a file: a personal access token (pat + 14 alphanumerics + . + 64 hex) anywhere, and a legacy API key (key + 14 alphanumerics) only when Airtable (airtable, AIRTABLE_API_KEY, Airrecord) is named on that line or up to three code lines above it, because key followed by letters is an ordinary identifier. Each must stand alone and have enough entropy to be real. The snippet is redacted.

It does not report placeholder or low-entropy bodies, key-prefixed names on lines without Airtable context, tokens read from the environment, or test, fixture and vendored paths.

What Gets Flagged

# FLAGGED: personal access token passed to pyairtable
api = Api('pat<14 alphanumerics>.<64 hex>')

# FLAGGED: legacy API key on an Airrecord line
Airrecord.api_key = "key<14 alphanumerics>"

# NOT FLAGGED: an ordinary identifier that starts with "key"
cache_key = "keyAbc123Def456Gh"

Why This Matters

Hardcoded airtable personal access token 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-060
// nosec vnx-sec-060

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