Don’t bring exposed developer credentials to Black Hat

Black Hat is where the security industry gathers to compare notes on what works. In recent years, supply chain attacks have been a recurring topic, and the 2026 Verizon Data Breach Investigations Report shows security teams are struggling to find a solution. According to the report, third-party involvement increased by 60% over the last year and now accounts for 48% of all breaches. These breaches are often the result of insecure authentication, such as missing MFA or improper credential rotation, and a lack of least-privilege enforcement for users or service accounts. Teams have spent years shifting left by hardening their supply chain with SBOM (software bill of material) tooling, package signing, and dependency scanners, but the pattern continues. Supply chain attackers are successful because they know exactly where credentials land by default. For many organizations, API keys land in .env files because that’s how the documentation shows it. AWS credentials live in ~/.aws/credentials because the CLI writes them there by default. Developers aren’t choosing to be reckless; they’re working with the tooling, documentation, and goals laid out for them, which sometimes create trade-offs that prioritize efficiency over security. Once a credential is out there, rotation requires knowing every system using it and coordinating a cutover without causing an outage. That operational complexity makes rotation a project most teams never get to, leaving the credential lurking in the dark, quietly, until something finds it. Supply chain attackers have built their entire playbook around this reality. The malicious postinstall hook does not search. It enumerates hardcoded paths because every tool in the developer's stack writes credentials to the same location on every machine: .env in the working directory, ~/.aws/credentials, shell history, .npmrc, .pypirc. The compromised package installs cleanly, and the credentials are gone before your terminal prompt returns. These…