Supply Chain Security Experience

Hi, I'm Bradley Farias. I work at Socket on supply chain security, and I want to talk to you a little bit about the experience of doing so and kind of how to not be overwhelmed by all these security people trying to talk to you about their wonderful products and all the chaotic mess that we have.

So supply chain is just means a network of different people, of different tools, different dependencies, all coming together to make your application for software. And people want to blow this out of proportion. They want to say, oh, this network is ever expanding and stuff like that. And it is large, especially in javascript. The average dependency might actually have around 80 dependencies, what we're seeing at work today. So whenever you pull in a dependency in your package.json for node, you're actually pulling in around 81 on average, because each dependency may have another dependency, which is a little bit scary to think about, but it's just the reality of the nature of building software these days. Everybody's working together. And that means our supply chain is very large.

This has security people and security vendors wanting you to panic. They want you to think that all sorts of things are vulnerable. Any sort of attack, everywhere, even the most minute kind of attack, is something you must be vigilant against. You must spend thousands and thousands of your money to just defend against something when, in reality, if you ask some questions, who can actually perform the attack? What can the attack do? Where can the attack actually be performed?

And these kind of things, you might notice that, okay, we can invest in these things that the security vendor has said are the most important things. But the impact of them is very small. And so it may be the case that all these security threats that are being identified, that are being shown to you by these security vendors, are impractical or just don't do anything to what you have.

So when you think about this, you need to think about your application, the dependencies in your application, and the consumers of your application. And who's the security vendor actually doing something for? Are they preventing consumers from doing something bad to your application? Are they preventing dependencies from exposing dangers to your application?

For our work at Socket, we are mostly focused on your dependencies. We have a high level of trust on your application. And that's not to say it's the only thing we defend against. But a lot of the time, when you are working with dependencies, you don't read their source code. You don't know what happens when you update your dependencies. They could pull in a new dependency. And when that dependency updates, pulling in a new dependency could introduce a backdoor. It could introduce a problematic script that runs on your development machine, on your build server, and stuff like that.

A lot of this is about trying to figure out what the security vendor is providing for you.

What the security vendor is trying to tailor their experience for. And they could be informative. They are trying to tell you about, oh, this thing that you installed has 80 dependencies within it. So you're not installing one when you add it to your package.json. You're actually installing 81 packages. They may be proactive. They might try to prevent you from installing something. Oh, this install will cause you to have an install script. The install script looks a little bit scary. Let's back off. So they could be proactive about security. Or they could be reactive. Oh, we saw that this vulnerability occurred. These are the steps you could do to identify what happened, what was vulnerable when, and what data was affected by it. You need to ask these questions when you're talking to security vendors. And ask about scenarios. Practical ones. Faker.js, EventStream, Lepad. These are all very famous. I have a great deal of hope that every security vendor you talk to has at least some basic answer for what would occur when using their tool, if their tool even affects those scenarios. These have academic papers written on these events. These are in Wikipedia articles and stuff like that. Or any theoretical scenarios you can come up with. But a lot of these come down to a famous XKCD.

A random person is hidden within your dependencies. You don't know who this random person is. They're so deep down in there. Their dependency is so deep down in there. That when they have a problem, when they introduce risk, malicious scripts into your codebase, you may not be able to see it. And these tools are trying to expose that.

And it seems overwhelming. But oftentimes, when you have hundreds and hundreds of dependencies, you may only have a few that are risky. So don't be overwhelmed by numbers. Get quality signal and noise ratios so that you can actually do an informed decision.

And the impact. When you're talking to these vendors, they may show you a great demo, but they definitely need to have answers to what happens if there is an incident. Is it going to take down your production machine? Is it going to cause problems for you as a business? And how much effort is it going to take for a developer, when they're waiting on a fix, to keep the production machines alive?

What can you do after it? You fixed it, but is there anything that the tool can do to prevent the next incident? And you need to go and have that conversation repeatedly. And hopefully, the vendors have an answer for you. So that's all. Don't get overwhelmed. Everybody's trying to show the value of their product as fast as they can, because we have very short amount of times when we're demoing things. But yes, it'll all be good.