Pelle Wessman

Today, Socket helps tens of thousands of developers to ship faster and spend less time on security busywork by helping them safely find, audit, and manage open source software at scale. Most developers use Socket through our popular GitHub integration – 

But what if you use another source code management system like GitLab or BitBucket? Or what if you want to integrate Socket into custom test or CI scripts? Or what if you just like using the command line?

That's why we're so excited to preview a brand new way to use Socket today. Introducing the 

In this preview release of the Socket CLI, we are shipping a subset of the commands that we aim for in our 

, but the commands we support today already work well, so we call it a 

"Wait? You're releasing an unpolished beta-style tool? Can we do that in an Apple-esque world of polished experiences?"

We're developers. You're developers. We commit early, we commit often, we iterate, and we know that nothing can ever be fully complete. Everything can always be rewritten and improved – if we wait for it to be "complete" then we'll never ship. To build the best tool, we know we need to dogfood and gather community feedback.

In this very first release we present you two commands:

 – this is the star of the show here. It enables you to create a Project Health Report on 

 for your project's dependencies. Running this command will upload just your 

 files – we of course don't want your source code or other sensitive files. You can use this command to automate Socket in your CI, no matter if you use 

 or something else. And you of course can use it manually as well.

 – this is a glimpse into the next step for the CLI. The 

 command enables you to look up all the supply chain risks and other package "issues" that Socket has detected for given version of a package. It mainly gives you a short summary, but it already also supports outputting the raw JSON response from our API. For 

 or others. This truly enables you to build your own tooling. More on that later.

A Socket Project Health Report contains a full listing of all package issues present in the project, as well as individual health scores for each package and average scores for the whole project.

There's a lot of incredible information about your packages in here:

 command does nothing more than giving you some help information, the rest of the magic is in the individual commands.

, will likely get accompanied by more in the future. On top of that, 

 and will for sure get more sub-commands going forward.

All commands describe themselves if you ask them using 

 and the commands support mostly the same flags:

 supports running the command without actually uploading anything. All CLI tools that perform an action should have a dry run flag

 - outputs result as json which you can then pipe into 

 - outputs result as markdown. This can then be copied into GitHub, Linear etc to easily share the result with your colleagues. Useful when you eg. feel the need to create an issue or PR because you found a package with quite a few issues.

 - outputs additional debug output. Great for debugging, geeks and us who develop. Hopefully you will never 

 - prints the help for the current command. All CLI tools should have this flag

 - prints the version of the tool. All CLI tools should have this flag

We use our new API and SDK in this (announcement to follow) and currently you have to ask us for an API key to get one. Bummer, we know, we're working on a self-service tool at this very moment but didn't want to wait for it.

Anyone can install the CLI tool though and explore. It will ask you for the API key and fail if you don't give it one. Install it like this:

And if you don't like to be asked for the API key (lets say you're in a CI environment), then put it in a 

If you want to add it for a local project but don't want to add it globally, then 

We're committing early and often, iterating, rewriting, and listening to your feedback. We will ship updates to the CLI frequently in the coming weeks in response to your feedback. 

 and a watch on GitHub to ensure you're on top of it all.

Next up, we'll be announcing our API and SDK on this blog, and then even more exciting things are in the pipeline!

Get started with the Socket CLI today by running 

We're excited to preview a brand new way to use Socket, a CLI tool! This will be especially useful to those of you not using GitHub or those who want more control over how you interact with Socket..

Announcing: Socket CLI Preview

Bret Comnes

This feature allows developers to detect 

 in open source packages—including supply chain, quality, maintenance, and license issues—directly from their GitHub workflow.

With our release today, teams can create an 

 that works best for their team and development style, factoring in what is most important for their own apps. 

By default, Socket for GitHub alerts developers about the most important supply chain risk signals—typo squats, install scripts, telemetry, malware, protestware, and more.

For example, if a dependency you've been using for years suddenly adds a risky 

 – a technique used by the majority of malware – Socket will detect it and let the developer and security team know in real-time.

 because they or npm has deleted it. Socket will let you know.

, which the Socket team recently shed light on, then Socket will let you know.

But, say that you don't care about specific threats – protestware, or native code – and don't want to be alerted when new or updated dependencies contain these issues. Whatever the reason, you are now able to individually toggle issues types from a 

Socket is designed to preemptively bring attention to the open source security and quality issues that matter most to 

. As always, our goal is to help developers can ship faster and spend less time on security busywork.

It's super easy to control which issues Socket will send you alerts for. Just create a 

In this example, Socket for GitHub will no longer alert you of new Git dependencies or missing author issues, but will alert you about any new dependencies with critical CVEs being introduced, in addition to the default set of issues we enable. 

See the full list of categories that are enabled by default in our 

We don't yet recommend turning on all issues yet. Doing so might potentially be very noisy and also generate more data than can be expressed in a GitHub comment. If you are interested in an on-depth overview of all issues in your project, we still recommend looking at the 

 generated along side your pull request alerts which will contain the same data plus a whole lot more. 

Ideally you will never need to disable issue types in your alerts, but now if you need to, the tools to do so are available. This is the first feature in a line of features we are adding that allow teams to fine tune the information we surface in pull request alerts.

Stay tuned for more update soon, and have fun customizing Socket!

 which takes just a few minutes to install, and get protected today!

Socket for GitHub has added the option to customize which issue alerts your pull request receives.

Customize your GitHub Issue Alerts

Ax Sharma

A community of Chinese devs that calls itself 'ApacheCN' is using open source platforms like GitHub and npm to store 1000s of eBooks.

Last week, Socket's automated npm analysis engine flagged a package called "

yingwen-lianmeng-erlingyiqilingjiu-erlingereryiling

" among a list of those missing license information.

On taking a closer look, Socket's senior software engineer 

 noticed something interesting: The unpacked npm package is 79 MB in size as it contains an 

As for the contents of the EPUB itself, it contains different editions of 

 one of the mainstream media sites to have joined the 

Some editions contained in the package are as recent as October 2022:

We noticed, at the top of every black-and-white edition packed within the EPUB, there's a link beginning with 

which takes you to a fuller, better quality color copy:

Other eBooks were riddled with multiple pages with giant QR code directing members to QQ/WeChat chat groups and niche websites.

 ('wizardforcel') had published upwards of 2,900 identical packages. As of Tuesday, November 1st this count jumped up to 

This set of 1000s of npm packages are quite diverse in terms of content.

Some of these pack Chinese translations of developer docs of popular open source frameworks. Others are eBook translations of works that may be censored in certain jurisdictions. And yet others seemed to cast doubts on their copyright status—are the repo owners engaging in piracy, whether unknowingly or intentionally?

,' a GitHub organization that claims to be a "non-profit project document and tutorial translation project established by iBooker" with a cheeky 

 that roughly translates to "We don't want to know friends who don't pretend to be coercive."

 makes it clear that the group "have no relationship with [Apache Software Foundation]!"

Despite claiming to be an "open source organization" who are stewards of a "non-profit" knowledge sharing project, it's hard to box ApacheCN aka iBooker into a single category.

It isn't exactly clear what iBooker is attempting to achieve. In its purported quest to establish a Chinese open information sharing platform, the contributors may have crossed a thin line between what constitutes "fair use" under international copyright law and online piracy.

We've tried contacting ApacheCN organization and repo owners multiple times in advance but haven't heard back.

 that appeared to have originated from domains of Chinese universities.

While we were busy scratching heads over the legality of these thousands of EPUBs posted by this group on both npm and GitHub, we came across another uncanny finding: a '

] maintained by the group riddled with sexist connotations. You be the judge, but the placement of such content itself on GitHub repo of the group is rather unsettling.

Note, we have not manually analyzed each of these 3,000+ packages and the analysis of individual EPUBs themselves is beyond the scope of this article. 

Although these packages may not be outright malicious, they do put software distribution and version control tools to novel use, in ways deviating from the traditional use case of GitHub and npm.

At the very least, these packages pose a problem when it comes to ensuring hygiene of the open source software ecosystem.

 which can detect missing licenses, software hygiene issues among 

Circumventing Chinese censorship: Plethora of eBooks pervade these GitHub and npm repositories containing contents of banned websites like 'The Economist' 

These Chinese devs are storing 1000s of eBooks on GitHub and npm

Today we are enabling 5 new critical pull request issue types in our 

: A dependency that is being added or updated contains a dependency that references a mutable git address
- 

: A dependency that is being added or updated contains a dependency that references a mutable http address
- 

: The author of a dependency no longer exists for some reason. (UPDATE: This issue has been temporarily disabled by default while we tune sensitivity)
- 

: A dependency in your tree has an invalid package.json and will cause install problems.
- 

: A dependency is importing a package that it cannot resolve.

UPDATE 2022-11-07: We disabled the non-existent author notification while we tune issue sensitivity as it was creating too many alerts. 

Dependencies that are specified with git or http urls are sometimes a necessary part of developing with dependencies. Perhaps you are waiting for upstream to merge a change. Perhaps you need to float a longer term patch over a dependency and you don't want to fully commit to forking and maintaining a dependency. (In these cases we, recommend 

git (or less often, http) dependency specifier

 in place of an official semver number can sometime be necessary. Issues can arise when this feature sneaks into your dependency tree when a transitive dependency utilizes this feature. Besides slowing down install times, these dependencies end up losing various security guarantees that packages published to npm have such as immutability or publishing policies around malware. This means that the mutable transitive dependency could selectively inject different package code depending on who is making the request, or the host is slow or unresponsive to requests to remove malware.

 or has imports that are broken, hopefully your CI tests will pick up the issue in the pull request when the broken version is added to your project. Either way, the 

 alerts will help you diagnose why and where you might find broken dependencies in your pull requests. 

 has some failsafes in place to prevent these kinds of things from getting published, however they do make it into the registry from time to time, and can be annoying to debug. We hope this info can help save you some time when you do come across them.

Here is a scenario: you start a new project, and you install some of your long time favorite dependencies. You are using the dependency but notice an error. You decide to be a good open source citizen and debug the issue and upstream a patch. You go through the work of writing that patch. When you go to submit it, the upstream repo/author account is no longer there! It turns out, your favorite dependency has been abandoned. If you had gotten a 

 alert in your pull request when adding the dependency, you could have found this out sooner, and discovered that there are now 3 community forks of this dependency where the bug is fixed already. You could have saved hours of debugging time if you had just gotten this information sooner. In addition to a number of other implications around packages with non-existant authors, we hope that this alert will assist in dealing with this unfortunate situation.

These issues themselves are usually not signs of a supply chain attack, but can cause issues if merged into your project and would typically require a lot of manual labor to locate from just a git diff on a 

We hope these new issues continue to surface interesting (smelly?) dependency mutations in your pull requests!

We added 5 new issues to our GitHub pull request alerts.

5 New Critical Issue Alerts 

Last week, when reviewing multiple packages flagged by Socket’s sleek GitHub App, a finding that stood out was an npm package called, ‘

’ which, at the time of writing, has received almost 

We’ve previously seen various statistical tools written in NodeJS including simple “visit” counters but a “state-counter,” you say?

In addition to containing obfuscated code, the package hits several 

 that warranted us to take a closer look:

Not Twitter, not StatCounter, it’s adware

Nearly all versions of ‘state-counter’ contain tightly packed obfuscated code in the “

” file. Interestingly, comments left by the package author in the JavaScript file mislead you to believe the package is indeed a “stat” counter—or related to the legitimate 

A classic technique exhibited by malicious open source packages leveraging 

Moreover, the copyright banner attributing the code to Twitter is even flimsier as neither the code contained in the package nor the company StatCounter have anything to do with Twitter.

The obfuscation contained in later versions of “state-counter” is quite complex with most plaintext strings scrambled haphazardly. Analyzing earlier versions, now unpublished from npm by the author but 

, helped us better understand the true nature of the package during static analysis.

A quick glance at the (plaintext) string array alone showed fragments of several URLs, including one starting with 

 redirects to an adult love doll and toy store:

Other references in the code point to specific sections of the online store, as well as ascertaining the user’s timezone, language as well as search engine settings. On meeting the specified criteria, the adware launches the NSFW URL on a user’s system.

Based on the criteria specified, “state-counter” appears to target China-based developers and users.

Granted, this typosquat isn’t nearly as sinister as malicious npm packages previously caught launching 

 scripts. But, it still counts as a counterfeit component posing risk to the overall security, integrity, and hygiene of the open source software ecosystem.

Ongoing threats to the software supply chain include 

 and dependency confusion PoCs, such as '

 of Wormhole Foundation’s SDK. These are just a few examples of unwanted components identified by Socket this week.

We reported “state-counter” to npm prior to publishing and it was taken down shortly by GitHub’s security team.

Developers can install Socket’s free GitHub app which can detect malicious uses of obfuscated code among 

Install Socket for GitHub and get protected today.

npm package ‘state-counter’ mimics StatCounter but instead pops open a very NSFW website.

What’s in your npm stat counter? A love doll store—we hope not!

Mikola Lysenko

Feross Aboukhadijeh

 ecosystem are on the rise. We’ve seen this time and time again with malware published to npm to launch 

If you are following these developments, you may have noticed that most npm malware relies on npm 

 to auto-launch malicious payload after infecting your system. You may also be led to believe that turning off install scripts with 

 is an effective preventative measure against most npm malware, or that you are safe if your npm code only ever runs on the front end.

 and show yet another attack vector that can allow malicious packages to pwn your computer.

. When installed, the executable files are unpacked and symbolically linked into 

(This nifty feature is used everywhere, from build tools like 

. Clearly, executable packages are really great and add a ton of value to the npm ecosystem...)

 places few restrictions on executable packages. In fact, there’s nothing stopping a hacker from naming thier bin script exports to whatever they like, 

including ‘node’ and ‘npm’ itself

 attack, which can be triggered by any dependency 

. This flag has no bearing on “bin” scripts.

, which hijacks a host—whether Windows or Unix based, in two steps:

1. First, the victim installs a compromised package:

2. Now their system is infected with the malware. Any subsequent npm script will trigger the payload. For example:

The actual malicious package is quite simple and contains two files

 file, which overrides the system definition of 

Test package, please ignore and do not install

npm-bin-script-poc

 which pops up Rick Astley’s famous music video

Once installed this package will override any subsequent invocations of 

 could trigger it. Even when installing other packages or running tests!

 isn’t entirely new, but little thought has been given to 

 malicious use cases made possible by “bin” exports, including remapping of the “node” command itself—which we call 

In 2019, full stack developer Daniel Ruf 

 ways in which threat actors could abuse ‘bin’ scripts.

 released updates addressing the major part of the issue (arbitrary file overwrites), but not other attack vectors. At the time, after “scanning the registry for examples of this attack,” npm did not find any published packages in the registry exploiting the arbitrary file overwrite or symlink creation aspects of the attack.

In 2021, however, ReversingLabs researchers 

’ that abused “bin” exports to remap the location of the legitimate ‘jstest’ package.

Compared to install scripts, bin script confusion is a bit harder to exploit since the victim needs to run a command (e.g. 

) after installing the malicious package. But it comes with its own share of problems. Being a relatively lesser widely known attack vector makes malicious use of bin exports harder to detect and prevent without reviewing all dependencies. As we explain, even best practices like 

 fall short of preventing shell injection via bin script confusion.

Moreover, legitimate use cases of “bin” scripts in npm packages may cause developers to ignore any (malicious) uses of such scripts during code reviews.

This problem is made worse by some quirks in npm. Because npm moves all transitive dependencies’ executables to the root, any package in your 

Another interesting thing to note is that 

 do not provide much protection and that the npm CLI has a race condition where installing multiple packages with the same exported executable will produce 

non-deterministic bin script configurations

. For example, two packages “foo” and “bar,” each with a “bin” export called “cmd” set to different locations.

Because many front end developers use npm scripts (i.e. 

) in their build processes, the potential attack area for this is much greater than simply adding malicious code to an existing package, where it would otherwise be confined to run in a browser sandbox. This could be exploited to steal credentials from production deployments, mine cryptocurrency, etc.

Finally, unlike with pre/postinstall scripts, the delayed execution of “bin” scripts may actually make them more insidious if they can lie dormant until a build or server command is run in a production environment with stronger credentials than the install script. Hypothetically, a CI system could 

 a malicious package in a restricted build environment and then trigger the build script later when running a subsequent build step.

We believe that this behavior is not ideal and poses a security risk. We had earlier disclosed our research on these risks to 

 via GitHub’s bug bounty program. GitHub’s response is that this functionality is currently working as designed and that they neither consider this a security vulnerability nor have plans to address it. And, to GitHub’s defense, even if they did agree with our concerns, curtailing the behavior of npm “bin” exports is no easy task. Bin scripts and the dependencies between them currently rely on this behavior and changing it would break countless existing packages and development workflows.

A preventative measure for developers is to use 

 when installing new packages, however, this is very fragile. Unlike 

, it is not sticky on a per-package basis and if you ever rerun 

 to update your dependencies from a lockfile it will again trigger bin script confusion.

Removing bin scripts for all packages may not be a viable option either for most developers using tools like 

 which can detect bin script confusion attacks and 

At the time of writing, Socket is the only tool that catches bin script confusion and bin script shell injection attacks, and we are continuously working on rolling out improvements that help developers stay ahead of supply chain risks.

Yet another attack vector that allows malicious packages to pwn you.

npm bin script confusion: Abusing ‘bin’ to hijack ‘node’ command

Today, we're excited to announce the ability to dismiss Socket pull request alerts from within GitHub. We call this feature "Bot Commands" and it's available to all Socket users starting today.

To dismiss a Socket pull request alert, simply leave a comment on the Pull Request in the following form:

When you leave a comment like this, Socket will re-analyze your project and update the GitHub check run, while ignoring the packages mentioned in the comment (

Deleting the comment will un-ignore the mentioned packages, and editing the comment will re-run the report with whatever the new ignore comment is.

You can ignore multiple packages at once by separating them with a space:

That's the quick summary of Socket Bot Commands. Now let's dive into the details.

 is "What do I do when I receive a Socket alert on on added or updated dependencies?".

Like all good questions, the first part of the answer tends to be "It depends!".

Dismiss Socket pull request alerts using bot commands.

Announcing: Socket CLI Preview

We're excited to preview a brand new way to use Socket, a CLI tool! This will be especially useful to those of you not using GitHub or those who want more control over how you interact with Socket..

Posts