Lessons From the Nx NPM Package Poisoning Attack: Securing Your AWS Environment Against Supply Chain Threats

Last week, attackers poisoned the popular Nx build system on NPM with malicious versions that attempted to steal SSH keys, GitHub tokens, npm tokens, and AWS credentials. For many teams, that's a nightmare scenario. Let's look at what this attack tells us about securing AWS accounts against software supply chain threats.

Package poisoning attacks

These types of attack are not new of course. Attackers exploit the trust developers place in package repositories like NPM and PyPi. Code is downloaded and executed on the user's behalf with few restrictions - a perfect opportunity for abuse. And developers machines are particularly attractive, often containing credentials to code repositories and cloud environments. It's easy for these installation scripts to scan for important secrets and exfiltrate them to allow further attacks to be launched.

These attacks are deployed via different mechanisms, including:

• Compromised packages; attackers compromise legitimate maintainer accounts to inject malicious code into established packages.
• Typosquatting; attackers upload packages to a central registry with very similar names to popular packages, hoping that a typo will result in a developer installing the malicious version. For example, the popular python requests library was targeted by various typosquatting packages, including one called requesys.
• Namesquatting: similar to typosquatting, attackers take advantage of deleted projects or naming conventions to trick developers into downloading malicious packages.
• Dependency confusion; typically refers to situations where attackers upload packages under company internal names, creating the risk that malicious packages are downloaded if repositories are not configured correctly.
• AI package hallucination; sometimes an LLM will suggest a package that doesn't exist yet - so an attacker can upload a malicious package under that name to get victims to download it.

Regardless of the mechanism, the result is malicious code running on a developers machine with all the privileges of the current user.

Mitigating package poisoning threats

How can you protect yourself from these attacks? Firstly, we want to reduce the risk of downloading malicious packages in the first place:

• Only use dependencies from projects that take security seriously. The OpenSSF Scorecard project exists to help open source consumers judge whether their dependencies are safe. Look for practices such as branch protection, code reviews, signed releases, and the use of MFA from package maintainers.
• Cryptographically pin package versions. Pick a stable version and stick with it. Only upgrade for security fixes and for features you need. Avoid package declarations that automatically install the latest version. Instead, pin a specific version, and do it cryptographically if possible (e.g. via a sha256 hash). That way even if a package is compromised the installation will fail the cryptographic check. The malicious Nx versions were only available for about 8 hours - being selective about package upgrades reduces the risk of consuming malicious versions.
• Use trusted internal package repositories, where packages are validated before they are used, rather than using arbitrary repositories on the internet. If you do this well, for example through a git-ops, PR-based approval workflow and automated scanning you can virtually eliminate certain types of attack without introducing unnecessary developer friction.

Next, you'll want to limit the damage that can be caused if you do download a malicious package:

• No standing production access. Separate production and non-production accounts and restrict developer access to production environments by eliminating standing access, requiring an approval process to allow access for specific tasks.
• Grant least privilege access. Make sure that any configured credentials have only the access required. For example, if a certain project only requires Lambda, SQS and DynamoDB resources, don't grant privileges for EC2. Avoid admin policies, even for sandbox and dev accounts. Use IAM Access Analyzer to identify overly broad access.
• Use temporary credentials, not IAM Users. We often find long-lived IAM user keys still lurking in developer machines. Instead, use temporary credentials and limit session duration as far as possible. If you're lucky, your credentials won't be active when an attacker attempts to use them.
• Implement permission guardrails. Use permission boundaries to limit the maximum permissions an entity can have, and use Service Control Policies to explicitly deny dangerous operations so that if an attacker does manage to get hold of your credentials, they'll be limited to what they can do.

And finally, you need to be able to detect and respond to any potential compromise to your AWS accounts. Monitor, alert and respond to unusual activity,

• Monitor and alert on unusual API activity from an IAM identity. CloudTrail, CloudWatch and GuardDuty are all particularly useful here in identifying unusual activity that may indicate that an IAM identity has been compromised.
• Automate incident response to credential compromise. If credentials have been compromised, speed and accuracy of the response is critical. The response can often be fully automated from detection through to eradication, especially for non-production accounts where there is no risk of production impact. For example, an indicator of credential compromise could be used to automatically trigger the revocation of all sessions associated with a given IAM Role, making the exfiltrated credentials useless while all existing users just need to re-authenticate. Where end-to-end automation isn't feasible, responses should still be automated and made available to incident responders to execute after analysis wherever possible, increasing the speed of response and reducing the chance for mistakes to be made.

Protecting AWS Credentials on Developer Machines

One of the reasons the Nx package poisoning attack was so dangerous is that it targeted developer workstations. These machines often hold the keys to the kingdom: plaintext AWS credentials, SSH keys, GitHub tokens, and other sensitive secrets. If a malicious package can read those files, it can exfiltrate them and immediately start abusing your cloud environment.

The fact that AWS credentials are stored in plaintext on disk is a long-standing frustration of mine, especially given that most developer laptops today include dedicated secure hardware like Apple's Secure Enclave, designed to protect secrets with hardware-backed, unextractable keys and convenient access controls such as Touch ID.

Inspired by the excellent Secretive project, I built a simple credential_process plugin for the AWS CLI that creates IAM Role credentials using AWS SSO OIDC tokens encrypted with a Secure Enclave–backed key. The result:

• No plaintext AWS credentials on disk.
• Hardware-backed protection. Credentials can only be decrypted with the Secure Enclave key.
• User-friendly access control. Each decryption requires Touch ID authorisation, making it impossible for attackers to silently steal and reuse AWS credentials.

It's just a prototype for now, we'll share more when it's ready to use. But this is the sort of low-friction, secure-by-design solution we get excited about at Hyperscale.

Wrapping Up

The Nx package poisoning attack is another reminder that software supply chain compromises aren't abstract — they're happening right now, and they target the weakest links: developer machines and poorly managed credentials.

The good news is that you don't have to leave yourself exposed. By combining strong preventive practices (secure package workflows, least privilege, temporary credentials) with protective measures on developer endpoints (like Secure Enclave–backed keys), you can make these attacks far less damaging.

At Hyperscale, we help teams put these protections into place without slowing developers down. Our approach is grounded in the AWS Well-Architected Framework security best practices, and we've helped organisations across industries strengthen their AWS environments against exactly these kinds of threats.

If you'd like to understand how your AWS setup stacks up - or get help implementing practical protections against supply chain risks - get in touch with us. We'd be happy to start with a no-obligation security posture review.