[REVIEW] secrets-management: add AWS STS temporary credential coverage

[GiazaiGia]

Skill Being Reviewed

Skill name: secrets-management
Skill path: skills/devsecops/secrets-management/

False Positive Analysis

Benign code that should not be treated as an active leaked AWS credential:

env:
  AWS_ACCESS_KEY_ID: "ASIA<temporary-access-key-placeholder>"
  AWS_SECRET_ACCESS_KEY: "<redacted-temporary-secret>"
  AWS_SESSION_TOKEN: "<redacted-session-token>"

Why this is a false positive risk:

Temporary credential examples, redacted values, and documented placeholders should not be counted as active leaked credentials. However, the current skill only documents AKIA* as an AWS access key prefix, so reviewers may overfit on long-lived keys and lack guidance for distinguishing real ASIA* STS credentials from placeholder training examples. The skill should make ASIA* reportable when real, while preserving its existing placeholder and entropy checks.

Coverage Gaps

Missed variant 1: AWS STS temporary access key is leaked in CI logs or artifacts

AWS_ACCESS_KEY_ID=ASIA****************
AWS_SECRET_ACCESS_KEY=<40-character secret>
AWS_SESSION_TOKEN=<long base64-like session token>

Why it should be caught:

AWS STS access keys use the ASIA prefix rather than AKIA. A leaked STS tuple is usable until it expires and may reveal that CI logs, build artifacts, screenshots, or support bundles are exposing credentials. The current sample patterns only call out AKIA, so a reviewer following the skill literally can miss temporary AWS credentials.

Missed variant 2: session token is leaked without the access key in nearby text

aws_session_token=<long base64-like session token>

Why it should be caught:

The session token is part of the credential tuple for temporary AWS credentials. Even if the access key or secret key is elsewhere in the same artifact, a leaked session token is still sensitive evidence and should be recorded as a secret exposure without printing the value.

Missed variant 3: short-lived cloud credentials are dismissed as safe because they expire

Credential source: OIDC exchanged into STS
Token lifetime: 60 minutes
Exposure location: GitHub Actions log retained for 90 days

Why it should be caught:

Short lifetime reduces blast radius, but it does not make the exposure safe. A valid token can be abused within its lifetime, and a retained log proves that the system leaked sensitive material. The finding should verify lifetime, scope, and revocation/session invalidation rather than dismissing it.

Edge Cases

• ASIA placeholders in documentation should remain non-findings when values are clearly redacted or non-random.
• STS credentials are usually a tuple; if one part is found, reviewers should check adjacent logs/config for the matching access key, secret key, and session token without reproducing any value.
• Expired temporary credentials may no longer require key rotation, but still require remediation of the leak path and log/artifact retention.
• OIDC-based cloud authentication is preferred over long-lived keys, but exchanged temporary credentials can still leak if tooling prints the environment.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add AWS STS detection guidance: include ASIA* access keys, aws_session_token / AWS_SESSION_TOKEN / AWS_SECURITY_TOKEN, and explicit guidance that temporary credentials remain reportable secret exposures while valid.

Comparison to Other Tools

Tool	Catches this?	Notes
Gitleaks	Yes	Built-in/default rules commonly cover AWS access keys including STS-style prefixes and session token names.
TruffleHog	Yes	Detects AWS credential material and can verify live credentials when configured to do so safely.
detect-secrets	Partial	Can catch high-entropy token-like values, but named STS patterns improve precision.
Current skill	Partial	Covers AKIA and aws_secret_access_key, but not ASIA or AWS session token names.

Overall Assessment

Strengths:

• Strong guidance on not printing secret values, filtering placeholders, and keeping findings scoped to actual credential material.
• Good coverage of secret managers, rotation, agent-specific credential handling, and git history scanning.

Needs improvement:

• Include AWS STS temporary credential patterns, not only long-lived AWS access keys.
• State explicitly that short-lived credentials are still sensitive while valid.
• Add triage guidance for expired-but-retained temporary credential leaks.

Priority recommendations:

1. Expand AWS access key detection from AKIA to AKIA|ASIA.
2. Add AWS session token variable-name patterns.
3. Add a false-positive note that redacted ASIA examples are not findings, while real temporary credential leaks still are.

Sources Checked

• AWS IAM temporary security credentials: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html
• AWS CLI environment variables (AWS_SESSION_TOKEN, AWS_SECURITY_TOKEN): https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html
• Gitleaks AWS access token detector reference: https://github.com/gitleaks/gitleaks
• TruffleHog AWS detector reference: https://github.com/trufflesecurity/trufflehog

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: to be provided privately after acceptance

[Alex-Parejo]

Implemented in PR #181: #181

[JamesJi79]

Review: Issue #163 — secrets-management: Add AWS STS Temporary Credential Coverage

Reviewer: Hermes Agent (automated review)
Date: 2026-06-03
Bounty: $25
Skill: /private/tmp/SecuritySkills/skills/devsecops/secrets-management/SKILL.md
Base commit: cc9c5ea (version 1.0.1 on main)

---

Summary

Issue #163 asks for AWS STS temporary credential coverage in the secrets-management skill. There are 4 PRs that attempt to address this, all branching from the same base commit and all modifying SKILL.md — meaning they conflict with each other and cannot be merged as-is without reconciliation.

PR	Ref	Author	Changeset
#20	origin/pr/20	yunrongy424-oss	3 commits: token patterns + scanner output redaction + severity adjustments
#165	origin/pr/165	GiazaiGia	1 commit: regex patterns + rule #4 + changelog
#166	origin/pr/166	dannielmv	1 commit: regex + full Section 2.3 (AWS Temporary Credential Triage)
#181	origin/pr/181	Alex-Parejo	1 commit: regex + rules #4/#5 + Section 3.3 + classification/output table updates

---

Per-PR Analysis

PR #20 (yunrongy424-oss) — Broadest scope, but lowest STS focus

Changes:

• Adds (?:AKIA|ASIA) to access key regex
• Adds (?:aws_session_token|AWS_SESSION_TOKEN)\s*[= :]\s*[A-Za-z0-9/+=]{100,} for session tokens
• Adds github_pat_* to GitHub PAT regex and known prefix list
• Adjusts severity: "no secret detection tooling" downgraded from Critical to High
• Adds Section 2.4: Scanner Output Redaction (new section)
• Updates severity table language

Issues:

1. Session token regex minimum {100,} is too restrictive. Real AWS STS session tokens are typically 350–500+ base64 chars, but some environments (MinIO, S3-compatible, test fixtures) use shorter tokens. A bound of 80+ is safer (matches what Gitleaks/trufflehog actually use).
2. Character class [= :] is broken/odd. Standard AWS session env vars use = as separator (e.g., AWS_SESSION_TOKEN=...). The [= :] allows a space as separator which doesn't occur in practice and could match unintended content.
3. Missing AWS_SECURITY_TOKEN in the session token regex. This is a legacy but still-used environment variable name.
4. No ['"]? optional quote handling around the value.
5. Changelog entry has a formatting bug: Literal `n text appears instead of a newline.
6. Scope creep: Adds GitHub token formats, scanner output redaction, and severity adjustments that are outside the issue [REVIEW] secrets-management: add AWS STS temporary credential coverage #163 scope (AWS STS only). These are valuable but should be separate PRs.
7. No new sections or guidance specific to STS temporary credential handling beyond the regex itself.

Recommendation: REJECT for #163 scope. The non-STS changes should be split into separate PRs.

---

PR #165 (GiazaiGia) — Minimal, clean, focused

Changes:

• Adds (?:AKIA|ASIA)[0-9A-Z]{16} for access key IDs
• Adds (?:aws_session_token|AWS_SESSION_TOKEN|AWS_SECURITY_TOKEN)\s*[=:]\s*['"]?[A-Za-z0-9/+=]{80,}['"]? for session tokens
• Adds rule Enhance all 45 skills per 7-rule audit evaluation #4: "Do not dismiss temporary credentials as safe"
• Renumbers old rule Enhance all 45 skills per 7-rule audit evaluation #4 → intel: appsec research + community updates 2026-03-22 #5
• Updates known prefix list with ASIA*
• Changelog entry

Strengths:

• Best regex of all PRs: includes all 3 env var names, {80,} minimum, optional ['"]? quote handling
• Clean, minimal scope — only STS-related changes
• Good rule wording for rule Enhance all 45 skills per 7-rule audit evaluation #4

Weaknesses:

• Too minimal for the $25 bounty. Only adds detection patterns + one rule. Does not add:
  • Triage guidance section
  • CI logs/artifact exposure section
  • Updated Findings Classification table
  • New output tables for temp credentials
  • Session inventory sample rows
• No placeholder-filtering guidance specific to temp credentials (rule intel: appsec research + community updates 2026-03-22 #5 from PR Improve secrets-management STS credential coverage #181)
• Renumbers old rules but doesn't add explicit guidance like PR Improve AWS STS secret detection guidance #166's Section 2.3

Recommendation: ACCEPT as a foundation, but COMBINE with elements from PR #166 and PR #181 to reach full value.

---

PR #166 (dannielmv) — Strongest triage guidance

Changes:

• Adds (?:A[KS]IA)[0-9A-Z]{16} for access key IDs (broadest match)
• Adds (?:aws_session_token|AWS_SESSION_TOKEN|AWS_SECURITY_TOKEN)\s*[=:]\s*[A-Za-z0-9/+=]{80,} for session tokens
• Creates Section 2.3: AWS Temporary Credential Triage — detailed guidance with:
  • Reportable examples showing the STS triple (access key, secret, session token)
  • Non-finding examples (redacted/placeholder)
  • Triage guidance for inspecting adjacent context
• Renumbers old Section 2.3 → 2.4
• Updates known prefix list
• Changelog

Strengths:

• Best triage guidance — the most practical section for reviewers
• Reportable vs non-finding examples are very clear
• Uses (?:A[KS]IA) which catches both AKIA and ASIA (and is more future-proof)
• Session token regex {80,} is appropriate
• Includes AWS_SECURITY_TOKEN

Weaknesses:

• Missing ['"]? optional quote handling in the session token regex
• No CI logs/artifact exposure section (PR Improve secrets-management STS credential coverage #181 has this)
• No updated Findings Classification table
• No new output tables
• No placeholder-filtering rule addition (rule intel: appsec research + community updates 2026-03-22 #5 from PR Improve secrets-management STS credential coverage #181)
• The (?:A[KS]IA) regex, while broad, could potentially match non-AWS patterns (unlikely but theoretically broader)

Recommendation: STRONGLY CONSIDER adopting the Section 2.3 content. This is the highest-quality triage guidance of all PRs.

---

PR #181 (Alex-Parejo) — Most comprehensive structure

Changes:

• Adds (?:AKIA|ASIA)[0-9A-Z]{16} for access key IDs
• Adds (?:aws_session_token|AWS_SESSION_TOKEN|AWS_SECURITY_TOKEN)\s*[=:]\s*[A-Za-z0-9/+=]{40,} for session tokens
• Adds rule Enhance all 45 skills per 7-rule audit evaluation #4: "Treat temporary AWS credentials as sensitive while valid"
• Adds rule intel: appsec research + community updates 2026-03-22 #5: "Preserve placeholder filtering for temporary credentials"
• Renumbers old rules Enhance all 45 skills per 7-rule audit evaluation #4 → intel: devsecops/compliance social updates 2026-03-25 #6, intel: appsec research + community updates 2026-03-22 #5 → intel: appsec community updates 2026-03-29 #7
• Creates Section 3.3: CI Logs and Artifact Exposure for Temporary Credentials
• Updates Findings Classification table (High/Medium entries)
• Adds STS row to Secrets Inventory example table
• Adds Temporary Credential Exposure Checks output table
• Changelog

Strengths:

• Most comprehensive — touches all the required areas
• Rule Enhance all 45 skills per 7-rule audit evaluation #4 and intel: appsec research + community updates 2026-03-22 #5 are well-written with clear guidance
• Section 3.3 addresses a real gap (temp creds leak via CI logs/artifacts, not just source)
• Updated Findings Classification is appropriate
• New output table ("Temporary Credential Exposure Checks") is useful
• Including STS row in the example inventory is good

Weaknesses:

• Session token regex {40,} is too short. An AWS STS session token is typically 350–500+ base64 chars. Setting {40,} would match many non-secret base64-like strings and generate false positives. Should be {80,} to match Gitleaks/trufflehog conventions. Or better, match the ASIA prefix-based approach (requiring the session token to be adjacent to an ASIA-prefixed access key).
• No ['"]? optional quote handling in the session token regex
• Does not include the triage section with examples (PR Improve AWS STS secret detection guidance #166's Section 2.3)
• The rule renumbering (4→6, 5→7) is correct but means PR Add AWS STS credential coverage #165 also renumbers differently, creating a conflict

Recommendation: ACCEPT as the best structural approach but FIX regex lower bound from {40,} to {80,} and add ['"]? optional quoting.

---

Comparison Table: Regex Patterns

Aspect	PR #20	PR #165	PR #166	PR #181	Best
Access key regex	(?:AKIA|ASIA)	(?:AKIA|ASIA)	(?:A[KS]IA)	(?:AKIA|ASIA)	Tie (PR #165/181)
Session token vars	2 of 3	All 3	All 3	All 3	PR #165/166/181
Session token min chars	{100,}	{80,}	{80,}	{40,}	{80,} (PR #165/166)
Optional quotes	No	['"]?	No	No	PR #165
AWS_SECURITY_TOKEN	No	Yes	Yes	Yes	PR #165/166/181

---

Cross-PR Conflicts

All 4 PRs branch from cc9c5ea and cannot be merged simultaneously:

1. Version collision — All bump to 1.0.2
2. Rule renumbering — PR Add AWS STS credential coverage #165 adds rule 4 (old 4→5), PR Improve secrets-management STS credential coverage #181 adds rules 4+5 (old 4→6, 5→7). These are incompatible.
3. Section renumbering — PR Improve AWS STS secret detection guidance #166 inserts Section 2.3 (old 2.3→2.4). PR Improve secrets-management STS credential coverage #181 does not. Different resulting structures.
4. Regex differences — 4 different implementations of the same patterns
5. Changelog conflicts — 4 different changelog entries for the same version

---

Recommended Resolution

The ideal solution combines the best elements:

Accepted from PR #165:

• Refined access key regex (?:AKIA|ASIA)[0-9A-Z]{16}
• Session token regex with {80,} minimum AND ['"]? optional quoting
• Inclusion of AWS_SECURITY_TOKEN
• Rule Enhance all 45 skills per 7-rule audit evaluation #4 wording about not dismissing temporary credentials

Accepted from PR #166:

• Full Section 2.3 (AWS Temporary Credential Triage) with reportable/non-finding examples and triage guidance
• Restructure: insert as new Section 2.3, renumber old 2.3→2.4

Accepted from PR #181:

• Rule intel: appsec research + community updates 2026-03-22 #5 (placeholder filtering for temporary credentials)
• Full Section 3.3 (CI Logs and Artifact Exposure)
• Updated Findings Classification table
• New Temporary Credential Exposure Checks output table
• STS row in Secrets Inventory example

Rejected from PR #20 (for this issue):

• GitHub PAT token format changes (github_pat_*) — separate PR
• Severity downgrade for "no detection tooling" — separate discussion
• Section 2.4 Scanner Output Redaction — separate PR
• Broken [= :] character class
• {100,} minimum length

---

Final Verdict

None of the 4 PRs is complete or correct on its own. The best approach is to:

1. Accept the structural additions from PR Improve secrets-management STS credential coverage #181 (most comprehensive, adds CI logs section, output tables, classification updates)
2. Fix PR Improve secrets-management STS credential coverage #181's regex — change {40,} to {80,} and add ['"]? optional quoting
3. Adopt the triage section from PR Improve AWS STS secret detection guidance #166 (Section 2.3 with examples)
4. Rebase into a single clean PR that merges without conflicts
5. Reject PR Improve secrets management token patterns and scanner severity #20 for this issue — its non-STS changes belong elsewhere

Estimated blended value: $25 — the combined work across all 4 PRs achieves the issue goal, but no single PR earns the full bounty alone. Recommend awarding $25 split across contributors or requesting a single rebased PR incorporating the best elements identified above.