One year ago, we founded Socket with the goal to safeguard the open source ecosystem for everyone. Modern applications use thousands of dependencies written by hundreds of maintainers. Installing even one package leads to dozens of transitive dependencies coming along for the ride. It's far too easy for a bad actor to infiltrate the software supply chain and wreak havoc.
That's why we're excited to announce our $4.6M Series Seed, with participation from the best angel investors, operators, and security leaders in the industry. See the full list below. This investment will help us pursue our mission to help companies protect their critical applications and services from open source supply chain attacks.
The Story#
Open source software enables teams to build powerful applications in days or weeks instead of months or years. Open source works because anyone can inspect the code. Anyone can contribute. Anyone can publish a package. Open source communities are trusting by default. Good contributors are rewarded with recognition and, eventually, publish rights.
But attackers are exploiting this trust and openness to carry out brazen supply chain attacks. We've seen unprecedented growth in the scale of open source malware. From event-stream
and ua-parser-js
to colors
and node-ipc
, the attacks keep coming. And, what's worse, they seem to be accelerating. A small number of bad actors have been able to pull off massive supply chain attacks that have shaken trust in open source.
Open source software has won, but security has often been an afterthought. New technology spreads because it's useful, not because it's secure.
Why haven't traditional approaches worked to protect open source?
The entire security industry is obsessed with scanning for known vulnerabilities, an approach which is too reactive to stop an active supply chain attack. Vulnerabilities can take weeks or months to be discovered. In today's culture of fast development, a malicious dependency can be updated, merged, and running in production in days or even hours. This isn't enough time for a CVE to be created and make its way into the vulnerability scanning tools that teams use.
Supply chain attacks and vulnerabilities are very different, and they need very different solutions:
- ⚠️ Vulnerabilities are accidentally introduced by an open source maintainer. It is sometimes okay to ship a vulnerability to production if it is low impact.
- ⛔️ Supply chain attacks are intentionally introduced by an attacker. It is NEVER okay to ship malware to production. You must catch it BEFORE you install it or depend on it.
Teams that want to address supply chain attacks currently have two options:
- Do a full audit – Literally read every line of code in all dependencies. Very few companies do this but it is the gold standard for preventing supply chain attacks. It takes a full-time team to manage this process – the audits, the updates, the allowlist, applying critical security patches. This approach is out of reach for all but the largest companies or the most security-critical applications. It's lots of work, it's slow, and it's expensive.
- Do nothing – Cross your fingers and hope for the best. This is the option that most teams take. On most teams, any developer can install any dependency in order to get the job done, and no one even looks at the code in these dependencies before approving the pull request. As you might expect, this approach leaves companies completely vulnerable to supply chain attacks.
Neither approach is ideal.
While we were building Wormhole.app – an end-to-end encrypted file transfer tool – we experienced the pain of selecting, managing, and updating open source dependencies amidst a constant drumbeat of supply chain attacks. We needed a solution.
We investigated what attackers actually do once they've compromised a package. Nearly every supply chain attack in the JavaScript ecosystem followed a familiar pattern. Once the attacker got control of a package, they added install scripts, network connections, shell commands, filesystem access, or obfuscated code. Others used social engineering such as typosquatting.
We had an idea. What if we assume all open source packages may be malicious and work backwards from there? How can we proactively detect signs of compromised packages? What's the simplest way to mitigate this risk without hurting usability?
We set out to help developers safely use open source without sacrificing development speed. Over the following months, Socket took shape. We expanded the team from three to six and things kept accelerating. We published our launch post and a blog post entitled "What's Really Going On Inside Your node_modules Folder?" which shares examples of recent supply chain attacks and concrete steps you can take to protect your team. We released a GitHub App that automatically detects potential supply chain attacks and alerts you.
The Present#
We've been totally blown away by the response to Socket. In just two months since launch, Socket is protecting thousands of organizations and tens of thousands of repositories. The Socket GitHub App automatically evaluates changes to “package manifest” files such as package.json
, package-lock.json
, and yarn.lock
. Whenever a new dependency is added in a pull request, Socket analyzes its behavior and leaves a comment if it is a security risk. Developers get helpful context and advice whenever they send a pull request with a low-quality, risky, or compromised dependency.
By statically analyzing open source packages and their dependencies, Socket can detect the tell-tale signs of a supply chain attack. Socket alerts developers when packages change in security-relevant ways, highlighting events such as the introduction of install scripts, obfuscated code, or usage of privileged APIs such as shell, network, filesystem, and environment variables.
For instance, to detect if a package uses the network, Socket looks at whether fetch()
, or Node's net
, dgram
, dns
, http
or https
modules are used within the package or any of its dependencies. If a new version of a package – especially a minor or patch version – adds code to communicate with the network, that's a huge red flag.
Socket detects 70+ issues in five different categories – supply chain risk, quality, maintenance, known vulnerabilities, and license. We use each issue as a signal into the supply chain risk formula that determines whether we will raise an alert.
Thank you!
Of course, we couldn't have gotten here alone. Thank you to our customers, advisors, and investors who have supported us so far.
We're honored to be backed by the best investors and advisors, including:
Elad Gil (Founder of Color Genomics), Nat Friedman (Former CEO of GitHub), Dylan Field (Founder & CEO of Figma), Patrick & John Collison (Founders of Stripe), Charlie Cheever (Founder of Quora and Expo), Guillermo Rauch (Founder & CEO of Vercel), Kevin & Julia Hartz (Founders of Eventbrite), JD Ross (Founder of OpenDoor), Balaji Srinivasan (Founder of Counsyl, Former CTO of Coinbase), Fred Ehrsam (Founder of Coinbase), Freddy Kerrest (Founder & COO of Okta), Todd McKinnon (Founder & CEO of Okta), Haroon Meer (Founder of Thinkst), Ryan Noon (Founder & CEO of Material Security), Andrew Peterson (Founder of Signal Sciences), Jed McCaleb (Founder of Stellar), John Lilly (Former CEO of Mozilla), Max Krohn (Founder of OkCupid, Keybase, and SparkNotes), Chad Hurley (Founder of YouTube), Dan Boneh (Stanford security professor), Daniel Gross (Founder of Pioneer), Michael Sindicich (General Manager at TripActions), Unusual Ventures (John Vrionis), Village Global (Erik Torenberg), South Park Commons (Ruchi Sanghvi & Aditya Agarwal).
The Future#
We plan to use the funding to grow our engineering, security analysis, and research teams so we can continue to deliver and improve our best-in-class supply chain security product.
If you want to stay in the loop, we'll be posting updates to our blog and Twitter @SocketSecurity, as well as the occasional newsletter (you can sign up below). Expect to see a lot more over the coming weeks.
Better yet, install Socket and get protected today!