What Happened
An attacker compromised the maintainer account for the Ruby gem 'strong_password' and published version 0.0.7 containing remote code execution capabilities. Rubygems.org reported 537 downloads before the malicious version was removed. The vulnerability, assigned CVE-2019-13354, was discovered through manual code review by the owner of withatwist.dev—not through automated scanning tools.
The compromised gem was in production repositories for an unknown period. Any application that updated to version 0.0.7 during that time pulled in code that could execute arbitrary commands on the host system.
Timeline
Initial compromise: Attacker gains access to maintainer credentials on Rubygems.org.
Malicious publish: Version 0.0.7 released with remote code execution payload.
Download window: 537 installations occur across an unknown number of organizations.
Discovery: Manual changelog audit by withatwist.dev owner identifies anomalous code.
Response: Malicious version removed from Rubygems.org.
Advisory: CVE-2019-13354 published.
The gap between publish and discovery represents the critical exposure window. The 537 downloads suggest the malicious version was available for days or weeks, not hours.
Which Controls Failed or Were Missing
Dependency pinning: Teams using flexible version constraints (~> 0.0) automatically pulled the malicious version. Lockfiles provided no protection if developers ran bundle update.
Maintainer account security: The attacker compromised a single account. There was no evidence of multi-factor authentication enforcement or anomaly detection on the publish action.
Automated vulnerability scanning: Tools like Snyk didn't flag the malicious version immediately. The discovery came from a human reading the actual code changes, not from signature-based detection.
Code review of dependency updates: Most teams treat bundle update as routine maintenance. Nobody was reading the diff for a password validation library.
Network egress controls: The remote code execution payload required outbound network access to be useful to the attacker. If compromised applications ran in environments with strict egress filtering, the impact would be contained.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management."
You need a software bill of materials (SBOM). When a supply-chain incident hits, you must answer "are we affected?" in minutes, not days. That requires knowing every dependency, in every application, at every version.
OWASP Top 10 2021 - A06:2021 Vulnerable and Outdated Components: "You do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies."
The strong_password incident demonstrates exactly this failure mode. Teams knew they used the gem but didn't track when updates occurred or what changed between versions.
NIST 800-53 Rev 5 Control SA-10 (Developer Configuration Management): "The organization requires the developer of the information system, system component, or information system service to perform configuration management during system, component, or service development, implementation, and operation."
This applies to your dependency management process. You're integrating third-party code into your system—that integration point needs configuration management discipline.
ISO 27001 Annex A.8.30 (Outsourced development): "The organization shall supervise and monitor outsourced system development activities."
When you pull in a RubyGem, you're outsourcing development. The standard expects you to monitor what that code does, not blindly trust it.
Lessons and Action Items for Your Team
Pin exact versions in production. Your Gemfile should specify gem 'strong_password', '0.0.6', not ~> 0.0. This creates maintenance overhead, but it's the cost of supply-chain security. Use bundle update deliberately, not automatically.
Generate and maintain an SBOM. Tools like cyclonedx-ruby can produce a complete dependency graph. Store this alongside your deployment artifacts. When CVE-2019-13354 drops, you query your SBOM inventory and know your exposure in under five minutes.
Review changelogs before updating dependencies. Create a policy: no dependency update merges without a human reading the upstream changelog. For the strong_password incident, the malicious code would have been obvious to anyone who looked. The problem was that nobody looked.
Implement automated dependency scanning with realistic expectations. Snyk, Dependabot, and similar tools catch known vulnerabilities. They don't catch zero-day supply-chain compromises. Use them as your first line of defense, not your only defense.
Monitor package manager security advisories. Subscribe to security@ mailing lists for your package ecosystems. RubyGems, npm, PyPI all publish advisories. You want to know about incidents like strong_password within hours, not when your scanner updates its database.
Apply network segmentation to limit RCE impact. If your application servers can't initiate outbound connections except to specific approved destinations, an RCE payload has nowhere to phone home. This doesn't prevent the compromise, but it contains the blast radius.
Audit maintainer account security on your own published packages. If your team publishes internal gems or npm packages, enforce MFA on those accounts. Review access lists quarterly. One compromised account can poison your entire organization's supply chain.
The strong_password incident had a small blast radius—537 downloads, quickly caught, rapidly remediated. The next one might not be caught by manual review. The next one might have 537,000 downloads before anyone notices.
Your dependency management process is either ready for that scenario, or it isn't. The controls listed above move you from "isn't" to "is."
