Rapid7 has disclosed that the attackers behind the Codecov breach had accessed some of the company's source code using a previously compromised Bash Uploader script from Codecov.

On April 15, 2021, Codecov, a provider of code coverage solutions, announced a supply chain incident in which a malicious party gained access to Codecov’s Bash Uploader script and modified it, enabling the attacker to export data stored in environment variables on Codecov customers’ continuous integration (CI) systems to an attacker-controlled server. Codecov’s disclosure with more details is available at https://about.codecov.io/security-update/.

In a statement, Rapid7 said, "When we learned of this incident, we immediately kicked off our security incident response process. Our use of Codecov’s Bash Uploader script was limited: it was set up on a single CI server used to test and build some internal tooling for our Managed Detection and Response (MDR) service. We were not using Codecov on any CI server used for product code."

Rapid7's investigation determined that a small subset of their source code repositories for internal tooling for their MDR service was accessed by an authorized party outside of Rapid7. These repositories contained some internal credentials, which have all been rotated, and alert-related data for a subset of their MDR customers.

No other corporate systems or production environments were accessed, according to Rapid7, and no authorized changes to these repositories were made. John Bambenek, Threat Intelligence Advisor at Netenrich, a San Jose, Calif.-based Resolution Intelligence provider, explains, “It appears according to Rapid7’s disclosure that the impact to customers is limited. Every MDR firm has their own custom tooling to help make their teams more effective and efficient. To the extent those tools have customer information, it should be limited, and would like relate to internal network information and applications a customer may have. For any of those customers, make sure they heed the information given to them by Rapid7 and to have increased vigilance around those systems that may have had sensitive information disclosed via this breach.”

Kevin Dunne, President at Pathlock, a Flemington, New Jersey-based provider of unified access orchestration, says, "Rapid7 is the latest company to be severely impacted by security supply chain related attacks. Security vendors are often high value targets, as they have deep, trusted access to networks that can provide an effective trojan horse for bad actors. Though the impact to Rapid7 customers seems minimal at the moment, customers should stay on high alert. Specifically, they will want to make sure they work closely with Rapid7's support and incident response teams to make any necessary updates required to reduce their risk exposure. In the meantime, they should monitor activity on their network, applications, and devices to highlight any suspicious behavior coming from Rapid7's software and mitigate any potential threats."

In the disclosure, Rapid7 says that cybersecurity is a top priority for the company, and "when there is an incident that may pose a risk to our customers, we are transparent about it. We also believe that providing this level of transparency ultimately helps the security community better address potential pending threats and safeguard themselves from future attacks."

Setu Kulkarni, Vice President, Strategy at WhiteHat Security, a San Jose, Calif.-based provider of application security, says, "Rapid7’s commentary on the issue they faced is another wakeup call for the entire industry. And also an example of transparency and accountability on behalf of Rapid7’s team."

Kulkarni adds, "Even though the use of the script was limited to one CI server to test and build some internal tooling in a non-production setup –even that narrow exposure resulted in outside actors accessing Rapid7’s code repos which had credentials and alert-related data for their MDR customers. For those small subset of customers that are affected – they have potentially critical alert-data that is now out there that could accurately point back to vulnerable systems in the customers’ enterprises.

He notes, "Broadly though it does highlight why customer related data should not be stored in code repos and if anything, using dummy anonymized data should be used for testing. The bottom line is that it does not matter if the weakness is in an obscure non-production solitary system meant to perform non-critical backend administrative functions because that system is in turn connected to a critical system somewhere – in this case the code repos with creds and alert-related data.”