Developers are flooded with tools and worries provided by security vendors. From researchers finding theoretical attacks, to time spent dealing with package updates, to simple accidents causing downtime all of these exist. Taking some history into account to understand the basic categories of attacks and how practical they are to exploit or even how common they are will give some assurance and guidance on where a developer can focus their limited energy and get the most out of their efforts.
Supply Chain Security Experience
AI Generated Video Summary
Supply chain security is important in software development, and it's crucial to assess the actual impact of threats. When dealing with security vendors, ask practical questions about vulnerabilities and impacts. Focus on quality signal and noise ratios when considering the number of dependencies. Ongoing conversations with vendors are important to address concerns. Stay informed and make informed decisions.
1. Introduction to Supply Chain Security
Hi, I'm Bradley Farias. I work at Socket on Supply Chain Security. Supply Chain refers to the network of people, tools, and dependencies that come together to build software. Security vendors often exaggerate the risks and try to make you panic. It's important to ask questions and assess the actual impact of the threats. When considering security, focus on your application, its dependencies, and the consumers. At Socket, we prioritize defending against dependencies and the risks they introduce. Understanding what the security vendor offers and tailoring it to your needs is crucial.
Hi, I'm Bradley Farias. I work at Socket on Supply Chain Security, and I want to talk to you a little bit about experience of doing so and 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.
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 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 is 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. They could be informative. They are trying to tell you, this thing that you installed has 80 dependencies within it. You're not installing one when you add it to your package JSON.
2. Asking Security Vendors the Right Questions
You need to ask security vendors practical questions about vulnerabilities, scenarios, and impacts. Don't be overwhelmed by the number of dependencies; focus on quality signal and noise ratios. Ensure that vendors have answers for incidents and preventive measures. Have ongoing conversations with vendors to address concerns. Demo time is limited, but stay informed and make informed decisions.
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.
Figure.js, Event Stream, Lettpad, 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 that 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.
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've 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. 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 a very short amount of time when we're demoing things. Yes, it will all be good.