Weak passwords and developer misconfigurations consistently lead to source code leaks from third-party repositories, even at large companies with robust security programs, such as Nissan North America. The consequences are often dramatic and long-lasting, including loss of competitive advantage and consumer confidence, depending on the nature and criticality of the source code.
While customer details may not get exposed, personally identifiable information (PII) often serves as the tip of the iceberg as previously unknown vulnerabilities and account takeover methods are revealed. Bad actors can then exploit the code in any number of ways, including creating counterfeit applications that undermine brand reputation.
Developers are at the core of revenue generation for many enterprises, including at Nissan where source code associated with business applications leaked. Risks associated with intellectual property leaks are not limited to the automotive industry. It happens more often than we’d like to admit.
Common developer mistakes
Typically, no punishment exists if developers, sales, or marketing teams circumvent their organization’s information technology or security protocols and stand up their own infrastructure. This occurs all the time, for the simple reason that it’s a faster way to support revenue generation. Likewise, leaks are often the byproduct of an unwitting developer in one of the following scenarios:
- Save code in the wrong place. GitHub runs a popular code repo, but many organizations maintain private instances which are not properly mapped out for developers.
- Inexperienced developers. Busy coders can overlook the importance of maintaining company code in a predetermined location. Not grasping the importance of source code for a company, they might offload proprietary code to other destinations for their personal resume – accidentally including company API and crypto keys in this less-than-secure location.
- Collaboration interferes with security. Lax security controls may exist around the coding environment when an organization relies on a distributed team of coders, including geographically diverse contractors who may be concurrently creating code for other companies.
- Lack of attention to detail, or an actual intent to dox proprietary code. While far less common, developers’ poor job satisfaction can create a breeding ground for insider threats, including a desire to out a company’s perceived lack of security controls.
Adversaries are ready to take full advantage when stumbling upon open source code repositories. Attackers frequently identify previously unknown vulnerabilities, learn how to bypass security mitigations, and expose sensitive cryptographic keys or hardcoded passwords to discovery. Such access to a victim’s code can also teach adversaries how to tailor attacks to mimic legitimate traffic. Of course, some bad actors simply look to sell access to sensitive, exposed code on the black market – taking a quick profit and enabling others to abuse and monetize.
Ways to safeguard source code
Many procedures, technologies, and services exist for security teams across enterprises to prevent source code leaks on third party repositories. Along with the best practice of extending bug bounties as a catchall for when those leaks actually occur companies can do the following:
- Detail processes and procedures for checking out code of corporate repositories. In addition, train and educate developers not to download code locally and store on private servers. Developers should also store code in a secure location and never use public repositories for proprietary code.
- If the company has to store code locally, implement a combination of virtual desktop, RDP, and VPN infrastructure to ensure proper segmentation.
- Cyber threat intelligence should automatically scrape for proprietary source code on third-party sites to alert security teams before it becomes public. The methods security teams use to scrape repos are the same way every security team, third-party security researcher, and malicious attacker indexes the internet. The automation can catch the code, but organizations need expert analysis to take action on the code, request to take down the code from the repo, and inform the person posting the code they need to remove it. Third-party repos generally do not have an automatic takedown for these requests. If an analyst catches the automatic detection, they pray the coder has paid attention, and perhaps the takedown can occur within 30 minutes. If a security team must rely on the third-party repo, it can take up to 48 hours.
If a source code leak happens, it’s critical for the organization to take defensive action against exposed information. Failure to do so can carry serious consequences, especially when PII becomes involved. Start remediation by understanding whether the code that was exposed contained private keys, potential access to PII, or critical data. The team also need to notify the organization’s legal team to evaluate whether the incident requires notification of regulators or law enforcement. The legal team can also determine whether it’s necessary to notify customers or partners. The company may also need to notify the board of any incidents, depending on the leak’s criticality.
From there, a security team can quickly begin establishing a defensive mechanism or parameter for the code that was exposed. For example, if the code functions as an internal application, reject inbound API calls – at least temporarily. For external exposure, notify the organization that protects web applications that the company needs additional monitoring and why. Good practitioners also know to begin rotating all cryptographic keys, passwords and API keys, an undertaking which can take days to months. Dedicate resources to complete the rotation and document every step of the way if there’s no readily available documentation. Finally, it’s useful to obtain code repository logs to determine any cloning activity, in case there are follow-on unauthorized access attempts.
While the stakes of code repository exposure are high, these third-party platforms are an inextricable part of more organizations’ business and operations. Above all, cyber risk managers must stay flexible and stay proactive, open the lines of “no fault” communications with developers and others. Fix security issues now so that attackers have less of a chance to establish an unauthorized foothold.
Landon Winkelvoss, co-founder, vice president of security strategy and content, Nisos