It might surprise some developers, but even widely used packages can turn rogue. These are small libraries or dependencies that, intentionally or after being compromised, exfiltrate data from the environment where they’re installed.
There have been many instances in real life where this type of situation has occurred; one day an application may be viewed solely as a convenience, and the next day it could be silently logging environmental variable(s) as well as API keys, and maybe even source code. It is similar to having an additional tenant in a common office space; they appear harmless at first until they have been copying sensitive documents all along, and I think that is what makes it so troubling.
Related Instances
1. Event-stream (npm, 2018):
An extremely popular JavaScript package that transitioned its maintenance to a new maintainer. A version of it added malicious code specific to Bitcoin wallets, and when developers unknowingly downloaded it, they were funneling their money to an attacker.
2. Node-ipc (npm, 2022):
The code within this application deleted files on computers operating within a given geographic area, demonstrating that nothing that gets added to a package via update can be assumed to be safe.
3. Typosquatting (npm & Python):
Attackers create fake version(s) of packages that have only one typo (i.e., a letter is slightly off) of the original package; developers who accidentally install these typos will be inadvertently exposing their environmental variables and Git tokens.
4. Malicious Python Forks:
In the case of some attackers who fork legitimate packages (examples being django-heroku) and injecting code into the fork, developers using those forks to install software could potentially expose sensitive API Keys and/or source code.
How Developer Data Gets Compromised
1. Environments Variables: Developers can gain access to data stored within the developer's "env" file(s). This typically includes sensitive information such as API keys, tokens, or passwords.
2. Git Tokens and Secrets: Attackers may utilize a package to read local Git config data and then transfer that data to a remote server where it can be used for malicious purposes.
3. Silent Exfiltration: The large majority of these packages work very quietly behind the scenes on the developer's machine, which means that developers generally won’t recognize the problem until significant damage is done to their data and intellectual property.
For an example, think about leaving the office open for a trusted vendor, in the past, this was considered safe. Now, it’s not uncommon for a vendor to have malicious intent. Therefore, it could be possible for them to take assets without your knowledge.
Five Ways to Ensure the Security of Your Project(s) Against External Threats
1. Verify Sources , Always ensure that the URL and maintainer associated with any package you install is legitimate.
2. Manage Your Dependencies , Create a package-lock.json or requirements.txt file to minimize unintended complications arising when you update your dependencies.
3. Audit Dependencies Regularly , Periodically audit all dependencies used in your projects using auditing tools (e.g. npm, pip) and identify any vulnerabilities in the dependencies used in your project.
4. Limit Access to Secrets , Limit the number of local development environments that can access cloud-based production secrets.
5. Increase Awareness Among Teams , To improve the protection of sensitive data, make your teams aware of how easily sensitive information can be exposed unintentionally through careless behaviour.
By treating every package you install as if it were a new hire, pleasant and to be monitored, teams should be able to avoid all but the rarest incidents.
© 2016 - 2025 Red Secure Tech Ltd. Registered in England and Wales under Company Number: 15581067