Sast Hardcodedsecrets

Phase 2: Verify — Confirm Real Secrets in Public Code (Batched)

After Phase 1 completes, read sast/hardcodedsecrets-recon.md and split the candidates into batches of up to 3 candidates each. Launch one subagent per batch in parallel. Each subagent verifies only its assigned candidates and writes results to its own batch file.

Batching procedure (you, the orchestrator, do this — not a subagent):

1. Read sast/hardcodedsecrets-recon.md and count the numbered candidate sections (### 1., ### 2., etc.).
2. Divide them into batches of up to 3. For example, 8 candidates -> 3 batches (1-3, 4-6, 7-8).
3. For each batch, extract the full text of those candidate sections from the recon file.
4. Launch all batch subagents in parallel, passing each one only its assigned candidates.
5. Each subagent writes to sast/hardcodedsecrets-batch-N.md where N is the 1-based batch number.

Give each batch subagent the following instructions (substitute the batch-specific values):

Goal: Verify the following hardcoded secret candidates. For each one, determine (1) whether it is a real secret and (2) whether it is in publicly accessible code. Write results to sast/hardcodedsecrets-batch-[N].md.

Your assigned candidates (from the recon phase):

[Paste the full text of the assigned candidate sections here, preserving the original numbering]

Context: You will be given the project's architecture summary. Use it to understand the tech stack, frontend/backend separation, build pipeline, and which directories contain client-side vs. server-side code.

For each candidate, answer TWO questions:

Question 1: Is this a real secret?

Check whether the value is an actual credential vs. a false positive:

• Does the string have the entropy and format of a real key/token? (Real API keys are typically 20+ random characters)
• Is it a known placeholder or example value? ("your-key-here", "changeme", "test", "example", "TODO", "xxx", "REPLACE_ME", etc.)
• Is it a test/development key? (Stripe sk_test_*, sandbox credentials, keys in test fixtures)
• Is it a public/publishable key by design? (Stripe pk_live_*, Firebase client apiKey, Google Maps browser key)
• Is it actually an environment variable reference that got picked up by mistake?
• Is it a hash, checksum, or non-secret identifier?

If the value is NOT a real secret, classify as Not Vulnerable and explain why.

Question 2: Is this in publicly accessible code?

Determine whether an external attacker can extract this secret from the deployed application:

PUBLICLY ACCESSIBLE (report these):

• Frontend JavaScript/TypeScript that runs in the browser (React, Angular, Vue, Svelte components/pages)
• Next.js client components (files with "use client" or client-rendered pages)
• Nuxt.js pages/, components/, client-side plugins/
• Any .js/.ts file that is imported by a client-side entry point (trace the import chain)
• Files in public/, static/, assets/, www/ directories that are served directly
• HTML files with inline <script> blocks
• Mobile app source code — Android (Java/Kotlin), iOS (Swift/Objective-C), React Native JS, Flutter Dart, Xamarin C# — ALL mobile code is extractable via reverse engineering
• Electron app source (extractable from ASAR)
• Client-side configuration objects embedded in JavaScript (e.g., Firebase config, analytics init)

NOT PUBLICLY ACCESSIBLE (do not report):

• Server-side route handlers (Express, Django, Flask, Rails, Spring, Go, PHP controllers)
• Server-side API routes (Next.js app/api/, Nuxt server/, SvelteKit +server.ts)
• Backend services, middleware, utilities only imported by server code
• .env files, server config files, Docker/CI files
• Test files and fixtures not shipped to clients
• Database migrations
• Build scripts and tooling

How to determine if a file is client-side:

1. Check the file path — is it under a client-side directory? (src/ in CRA/Vite React, pages/ in Next.js, app/ in Angular, src/ in Vue)
2. Trace the import chain — is this file imported (directly or transitively) by a client-side entry point?
3. Check for server-only markers — "use server" directive, file under api/ or server/ directories
4. Check sast/architecture.md for the project's frontend/backend separation pattern
5. For ambiguous cases (e.g., shared utility files), err on the side of caution — if it COULD be bundled for the client, treat it as publicly accessible

If the secret is NOT in publicly accessible code, classify as Not Vulnerable and explain why (e.g., "Server-side only — Express route handler").

Classification:

• Vulnerable: Confirmed real secret in confirmed publicly accessible code. An attacker can extract this from the deployed application.
• Likely Vulnerable: Appears to be a real secret and the file is likely client-accessible, but cannot fully confirm one or both conditions (e.g., ambiguous import chain, uncertain if the value is a real production key).
• Not Vulnerable: Either not a real secret (placeholder, test key, public key) OR not in publicly accessible code (backend-only).
• Needs Manual Review: Cannot determine if the value is a real secret or if the file reaches the client — requires human judgment.

Output format — write to sast/hardcodedsecrets-batch-[N].md:

# Hardcoded Secrets Batch [N] Results

## Findings

### [VULNERABLE] Descriptive name
- **File**: `path/to/file.ext` (lines X-Y)
- **Secret type**: [AWS key / Google API key / etc.]
- **Exposure path**: [How an attacker extracts it — e.g., "Bundled into client JS via Webpack, visible in browser DevTools Sources tab" or "Embedded in Android APK, extractable via `apktool d app.apk`"]
- **Issue**: [Clear description — e.g., "AWS access key hardcoded in React component that is bundled for the browser"]
- **Impact**: [What an attacker can do with this secret — e.g., "Full access to AWS S3 buckets, potential data exfiltration", "Send emails via SendGrid on behalf of the organization", "Access user data via the API"]
- **Evidence**:

[Code snippet with the secret value partially redacted]

- **Remediation**: [Move the secret to a server-side environment variable. If the client needs to call this API, proxy through your backend. For mobile apps, use a backend proxy or OAuth flow instead of embedding keys.]
- **Verification Steps**:

[How to confirm this finding:

• For web apps: "Open browser DevTools > Sources > search for 'AKIA' in bundled JS files"
• For mobile apps: "Run apktool d app.apk and grep for the key pattern"
• For Electron: "Extract ASAR archive and search for the key"]

### [LIKELY VULNERABLE] Descriptive name
- **File**: `path/to/file.ext` (lines X-Y)
- **Secret type**: [type]
- **Exposure path**: [Best guess at how it reaches the client]
- **Issue**: [What's uncertain]
- **Concern**: [Why it's still a risk]
- **Evidence**:

[Code snippet]

- **Remediation**: [Fix recommendation]

### [NOT VULNERABLE] Descriptive name
- **File**: `path/to/file.ext` (lines X-Y)
- **Reason**: [e.g., "Placeholder value — 'your-api-key-here'" or "Server-side only — Django view, never reaches the client" or "Stripe publishable key — designed for client use"]

### [NEEDS MANUAL REVIEW] Descriptive name
- **File**: `path/to/file.ext` (lines X-Y)
- **Uncertainty**: [Why automated analysis couldn't determine the status]
- **Suggestion**: [What to check manually]

Phase 3: Merge — Consolidate Batch Results

After all Phase 2 batch subagents complete, read every sast/hardcodedsecrets-batch-*.md file and merge them into a single sast/hardcodedsecrets-results.md. You (the orchestrator) do this directly — no subagent needed.

Merge procedure:

1. Read all sast/hardcodedsecrets-batch-1.md, sast/hardcodedsecrets-batch-2.md, ... files.
2. Collect all findings from each batch file and combine them into one list, preserving the original classification and all detail fields.
3. Count totals across all batches for the executive summary.
4. Write the merged report to sast/hardcodedsecrets-results.md using this format:

# Hardcoded Secrets Analysis Results: [Project Name]

## Executive Summary
- Candidates analyzed: [total across all batches]
- Vulnerable: [N]
- Likely Vulnerable: [N]
- Not Vulnerable: [N]
- Needs Manual Review: [N]

## Findings

[All findings from all batches, grouped by classification:
 VULNERABLE first, then LIKELY VULNERABLE, then NEEDS MANUAL REVIEW, then NOT VULNERABLE.
 Preserve every field from the batch results exactly as written.]

5. After writing sast/hardcodedsecrets-results.md, delete all intermediate batch files (sast/hardcodedsecrets-batch-*.md).

Important Reminders

• Read sast/architecture.md and pass its content to all subagents as context.
• Phase 2 must run AFTER Phase 1 completes — it depends on the recon output.
• Phase 3 must run AFTER all Phase 2 batches complete — it depends on all batch outputs.
• Batch size is 3 candidates per subagent. If there are 1-3 candidates total, use a single subagent. If there are 10, use 4 subagents (3+3+3+1).
• Launch all batch subagents in parallel — do not run them sequentially.
• Each batch subagent receives only its assigned candidates' text from the recon file, not the entire recon file. This keeps each subagent's context small and focused.
• The key distinction is public accessibility: a hardcoded AWS key in a Django view is bad practice but NOT a finding for this skill (it's server-side). The same key in a React component IS a finding because it ships to the browser.
• Trace the import chain when uncertain: A file at src/utils/config.ts might be imported by both server and client code. Check who imports it. If ANY client-side code path imports it, the secrets are exposed.
• Mobile apps are always public: All source code in Android, iOS, React Native, Flutter, and Xamarin apps should be treated as extractable. APKs can be decompiled with apktool/jadx, IPAs can be inspected, JS bundles in React Native are plaintext.
• Firebase client config is generally NOT a secret: The standard Firebase client config (apiKey, authDomain, projectId, etc.) is designed for client-side use and protected by Firebase Security Rules. Only flag Firebase admin/service account keys or server keys (e.g., FIREBASE_ADMIN_SDK, service account JSON with private_key).
• Stripe publishable keys are NOT secrets: pk_live_* and pk_test_* are designed for client-side use. Only flag sk_live_* and sk_test_* (secret keys).
• NEXT_PUBLIC_*, REACT_APP_*, VITE_* env vars: These are embedded into client bundles at build time. If the code references process.env.NEXT_PUBLIC_API_KEY, that IS client-accessible — but the actual hardcoded value would be in the .env file, which is typically gitignored. Only flag if the actual secret value is hardcoded in source code, not if it's read from an env var.
• Redact secrets in output: When showing code snippets, always partially redact the secret value (e.g., AKIA****WXYZ, sk_live_****abcd). Never write the full secret value in the results file.
• When in doubt about public accessibility, classify as "Needs Manual Review" rather than "Not Vulnerable". False negatives are worse than false positives in security assessment.
• Clean up intermediate files: delete sast/hardcodedsecrets-recon.md and all sast/hardcodedsecrets-batch-*.md files after the final sast/hardcodedsecrets-results.md is written.