VNX-SEC-033: AWS Bedrock API key (long-lived)
Reports an AWS Bedrock long-term API key: the ABSK prefix followed by 109 to 269 base64 characters, standing alone (not embedded in a longer base64 run). Placeholder and example values, test and fixture paths, and short-term bedrock-api-key- tokens (which expire within hours) are not reported.
| Field | Value |
|---|---|
| Rule ID | VNX-SEC-033 |
| 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 aws bedrock credentials |
| Source | internal/sast/rules/vnx-sec-033.rego |
Overview
This rule detects AWS Bedrock long-lived API keys matching the ABSK[A-Za-z0-9+/]{109,269}={0,2} pattern hardcoded anywhere in source files. Bedrock long-lived keys are valid until explicitly revoked and grant full programmatic access to every foundation model the IAM principal is allowed to call. Combined with prompt-injection attacks, a leaked Bedrock key can be abused to run up large bills, exfiltrate user data sent to the model, or train downstream attackers on a competitor’s prompts.
Why This Matters
Anthropic, Cohere, Meta Llama, Mistral, Stability, and Amazon Titan models are all served through Bedrock. A leaked key lets any attacker who finds it run inference, fine-tune models, and consume provisioned throughput, the cost of which is charged to your AWS account. Unlike AKIA access keys, Bedrock keys are not surfaced by GitHub Secret Scanning’s partner program, so they often linger in public repos for weeks before revocation.
What Gets Flagged
Flagged (a standalone ABSK token of 109 to 269 base64 characters):
AWS_BEARER_TOKEN_BEDROCK=ABSKQmVkcm9ja0FQSUtleS<...base64 body...>
Not flagged: os.environ["AWS_BEARER_TOKEN_BEDROCK"], an ABSK run inside a longer base64 blob, ABSKxxxx… placeholders, files under test or fixture paths, and short-term bedrock-api-key- tokens.
Remediation
- Revoke the key in IAM → Users → Security credentials → API keys. Treat it as compromised even if you only saw the leak in a private scanner report.
- Replace with short-lived credentials. Bedrock supports IAM Identity Center (SSO) tokens and SigV4-signed requests from an assumed role. Both avoid static keys entirely.
- Set up a usage alarm. CloudWatch metric
CallCountforbedrock-runtime:InvokeModelwill fire on any anomalous call from a new region or service. - Purge from git history with
git filter-repoor BFG, then re-scan the cleaned repo withgitleaks detect --source .. - Enable AWS CloudTrail Lake integration with this repo to confirm whether the key was used by an attacker.
References
- AWS Bedrock Authentication and access control
- AWS long-term vs short-term credentials
- CWE-798: Use of Hard-coded Credentials
- gitleaks, uses the same
aws-amazon-bedrock-api-key-long-livedrule - truffleHog, verifier for AWS keys
- MITRE ATT&CK T1552.001 – Credentials In Files
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-033
// nosec vnx-sec-033
Or record an ignore rule: vulnetix ignore add --rule vnx-sec-033 --reason "...". See Suppressing findings.