Guest: Feross Aboukhadijeh (LinkedIn)
Company: Socket (Twitter)
Show: Let’s Talk

Supply chain attacks have increased dramatically in the past year. Malicious actors are attacking organizations through open-source dependencies. In this episode of TFiR: Let’s Talk, Socket CEO Feross Aboukhadijeh shares his insights on software supply chain security and how Socket helps protect against attacks by proactively detecting supply chain risk in open-source code.

Current trends in the market:

  • As an open-source maintainer for the JavaScript community for the last 10 years, one of the things Aboukhadijeh has learned is how wide-reaching the dependency trees are.
  • It’s common for a new application to have thousands of dependencies right off the bat. This creates a lot of risk in software supply chains and the trust that is given to all the different individuals that make the open-source software.
  • A node package manager (NPM) averages 79 additional dependencies that that dependency depends on, i.e., you’d be in 1 dependency and you end up with 80 dependencies in your application. It’s less to do with open source and more to do with the way we’re splitting up the code into different dependencies.
  • The JavaScript community, the Rust community, and other newer programming language communities have a tendency to create tiny packages that do one thing well. This leads to dependency trees expanding to the point that it becomes hard to understand what’s happening.
  • Teams are aware that they should be doing something about open-source supply chain security, but they don’t really know what to do.
  • People think that scanning for common vulnerabilities and exposures (CVE) is enough to keep them safe from attacks and risks.
  • The market is flooded with a lot of vulnerability scanning tools that merely look up the packages that you’re using to see if any vulnerabilities have been reported in these packages. Unfortunately, this process is slow and too reactive to stop an active supply chain attack. When a package is compromised and a developer goes to install that dependency or a build tooling automatically upgrades that dependency or makes its way into people’s products, it’s too late at that point to go and protect all the apps that had used that dependency.
  • A lot of teams scrutinize their colleagues’ code more than they scrutinize open source code that was written by random people on the internet.
  • When it comes to dependencies, nobody really reviews them. All you usually see is a dependency was added.
  • GitHub and other popular tooling out there do not really show the code in that dependency, what that code is going to do, what other dependencies does that dependency depend on.
  • Organizations are expanding the scope of what open-source security means to go beyond just vulnerabilities and into include a holistic defense against supply chain attacks.

Supply chain attack vs. vulnerability

  • A supply chain attack involves an intentional introduction of a problem into a package, and it’s done by an attacker with malicious intent. You don’t have time to mitigate them.
  • A vulnerability is like leaving a window in your house open. Somebody might use it to get into your house, but probably not. Some are low impact, and some might not even be exploitable in production. You usually have a window (days, weeks, months) to fix it.

How Socket helps:

  • It is extremely developer friendly.
  • It provides actionable feedback about dependency risk without adding more burden or more noise to the developers.
  • It is built directly into the GitHub workflow, the VS code editor, the CLI, and into all the places that the developers spend their time, meaning, it doesn’t require them to use another tool or learn another process.
  • It brings the information that’s most useful to the developer directly to them, and then makes it digestible and easy to understand. Examples: 1) A developer might use a new dependency and Socket will tell them there has been no updates in 5 years. 2) A developer wants to install a dependency via the command line but makes a typo. Socket will inform the developer that there is a much more popular dependency with a slightly different name and will ask the developer to confirm the install. It doesn’t interfere with their workflow, unless there’s a good reason to tell them that information.
  • It will highlight when the behavior of the package has changed in a significant way.
  • It is used by over 3,000 organizations and in over 150,000 code repositories.
  • Even though it is a relatively new tool, the company has been around for decades.
  • It is super easy to install, literally in two clicks.
  • It is very accessible. There is a free version for open-source projects and small teams.

What’s ahead:

  • Socket will expand to support more ecosystems, more languages, more use cases.
  • There will be an increased adoption of software bill of materials (SBOMs).
  • While it’s great to know what open-source software you’re using, the real question is, what do you do with that information? How do you make that useful? We need to combine SBOMs with more useful data about what the dependencies are doing, what are the risks, what is the behavior of each dependency, what is the maintenance status, who is the creator of each dependency, etc.

This summary was written by Camille Gregory.

You may also like