Beginner’s Guide to Supply Chain Attacks in Cyber Security

You can be doing almost everything right in cyber security and still get hacked. Not because your systems are weak or you made a mistake.

But because hackers gained access to the third-party tools you use!

It's annoying because you can’t just stop using these tools. In fact, most of them help you run your business. However, there are things you can do to minimize the impact when it happens.

In this guide, I’ll break down what supply chain attacks are, how they work, and what you can do to protect yourself and your organization.

Sidenote: If you want to learn how to defend against these and other issues then check out my complete Cyber Security Bootcamp!

Intermediate

Complete Cybersecurity Bootcamp: Zero to Mastery

11 Hours •98 Lessons

Go from zero to hired as a Cyber Security Engineer. Learn the latest cybersecurity best practices, techniques, and tools so that you can build and defend your digital assets against hackers.

Aleksa Tamburkovski

Updated for 2025, you’ll learn the exact techniques and tools you need to know to help yourself or even other companies protect and defend digital assets from these black hat hackers.

With that out of the way, let’s get into this 5-minute guide.

What are supply chain attacks?

The easiest way to rob a house is to go through an open door, and supply chain attacks use that same principle. Rather than trying to hack you and your secure systems, they hack 3rd party tools instead.

Think email platforms, dashboards, etc.

Basically, the tools you use that are already on your network, so they can get inside without you even knowing about it.

For example

A few years ago, hackers managed to insert malicious code into a legitimate software update from a company called SolarWinds on their Orion platform.

This hack meant that when customers installed a verified update, attackers gained backdoor access to their systems.

Now, for most of us, this company doesn’t mean anything. However, this tool is used by everyone from small teams to major corporations and even government agencies around the world.

This meant they managed to get access to literally thousands of companies at once.

And the thing is, supply chain hacking isn’t limited to just software. It could also be installed on hardware components, firmware updates, or even development tools.

Scary stuff!

So how do we protect ourselves from this?

How to protect, detect, and prepare for supply chain attacks on your systems

The reality is, you can’t fully prevent a supply chain attack because it’s out of your hands. Like we saw with the SolarWinds hack, if a vendor gets compromised, then even ‘trusted’ files can be infected.

However, you can build better practices and systems to limit the impact and recover faster when it happens.

So let’s work through the common steps now.

Step #1. Map your dependencies

One of the best ways to defend your system is to be aware of what's in that system. That way, if anything happens, you’ll know if it affects you, and you can sort it ASAP.

So start by making a complete inventory of what’s running in your environment.

This includes:

Installed applications (both local and cloud-based)
Browser extensions and plugins
APIs or integrations that connect systems together
Dependencies within your codebase, like NPM packages, Python libraries, or Docker images

The good news is that this doesn’t need to be complicated. You can just throw it all into a spreadsheet, then list each tool, what it does, who owns or manages it, and whether it has access to sensitive data.

Also, there are tools to help you with this.

If you’re working with code, then you can use OWASP Dependency-Check or npm audit to automatically identify what libraries you’re using.

These will scan for any known vulnerabilities while also identifying your libraries, so it's a win-win situation to help you get organized and secure, and check for issues in the future.

You can also use configuration management databases (CMDBs) or asset discovery tools like Lansweeper to map dependencies across systems for you.

Once you have all these tracked, try to create a habit of reviewing your dependency list quarterly, if possible. This way, you can prune what’s no longer needed or being used, so you’re not leaving unsecured backdoors.

Step #2. Use zero trust as standard

Once you’ve mapped what’s running inside your system, the next step is to tighten how those tools interact with everything else so you can reduce the impact.

We call this concept ‘zero trust’.

Basically, we’re going to assume that at some point, you will be hacked, so you can’t just trust that everything will be secure. However, by limiting users' and software's access to only what's needed, it then limits what the hackers can interact with.

Better still, it also means that they can’t elevate their access or wander across your network, as your firewall, IAM policies, or container limits won’t let them, and they’re stuck within the permissions you’ve defined.

So start off by reviewing who and what has access to your systems, and assess if they have the right level of access.

For example

A tool that only needs to read data shouldn’t have permission to write it
A reporting dashboard doesn’t need access to your production database
And if a contractor’s project is finished, close their account instead of keeping it around “just in case”

It’s easy to kind of run through installing tools and not think about the access you’re giving them, so going back and checking can help bring up any potential issues.

So here’s how to do this.

You’re going to need an identity and access management (IAM) system. You can use tools like Okta, JumpCloud, or others.

The setup with these tools will vary depending on which one you use. However, you should be able to do the following with each of them:

Start off by creating roles for each team or tool based on what they actually need, and assign permissions to those roles and not to individuals. That way, when someone changes teams or a vendor integration evolves, you can update their role instead of chasing down dozens of accounts
Next, go ahead and enforce least privilege by default. Most systems let you toggle read-only or restricted modes for connected tools. If an app only needs to fetch data, keep it read-only. If it ever needs admin access for a specific task, make that access time-limited so it expires automatically
Then, isolate and segment your environments. Keep your production systems, admin consoles, and test setups separated so that even if one is compromised, the others remain safe
And finally, log everything. Every login, every new connection, every permission change. You don’t have to review them daily, but if something looks off later, those logs can then help you narrow down the issue

Simple!

These will reduce the impact of almost any hack. However, we can reduce it even further if we can catch it early with the next step…

Step #3. Monitor for unusual behavior

Monitoring tools allow us to notice when something doesn’t look right and then act before it spreads further.

You can start off small using basic built-in tools like Windows Defender, or even better, use a specialized SIEM (Security Information and Event Management) tools like CrowdStrike Falcon, or tools like Wazuh, or Graylog, so you can monitor endpoints and flag suspicious activity.

These are great because they don’t just look for known malware. They also try to spot strange behavior, like an app trying to run code that it’s never used before or making connections to unknown servers.

Again, the setup will vary depending on the tools, but you’re going to want to:

Make sure logs are enabled and stored somewhere central so you can review them later.
Then, set up alerts for key changes such as new user accounts created, failed logins, system reboots, or configuration edits, as these are often the first signs of trouble

That being said, it's worth starting off small and figuring out what ‘normal’ looks like in your environment. This way, you won’t set up alerts for the wrong things or be overly sensitive, or even miss anything.

I highly recommend one of these if you don’t have one in place yet. This is because most major breaches (not just supply chain attacks) go undetected for weeks or months simply because no one’s watching for the signals that they’re hacked or infected. Even small, simple monitoring setups can cut that time dramatically.

Of course, once you’ve found an issue, you then need to do something about it...

Step #4. How to respond when the hack is found

There are a few basic steps you can follow to deal with a potential hack.

Confirm the issue is real

So you’ve had an alert or noticed some odd behavior. However, before raising the alarm or freaking out, take a minute to confirm whether it’s legitimate or if it's a false alarm.

For example

If someone finally logged into an account they haven’t used in a while, reach out to them and see what they were doing
But if it's happening at 3 am and they are sending data back and forth, then that's a huge red flag. It could be that someone has remote access to their account.

Contain the damage

If you suspect an attack, isolate affected systems right away. That could mean disconnecting a compromised workstation from the network, disabling an account, or temporarily suspending integrations.

The goal is to stop the spread without taking down the entire business.

Find out how it happened

Once things are contained, identify how the attacker got in:

Was it a malicious update?
A compromised vendor?
A stolen credential?

We need to figure this out before we can remove the issue and fix it. So go through your logs and SIEM to see where the issues arrived.

Important: You might have got an alert and a hotfix from a tool already.

Don’t assume you’re safe, though. It could be that they escalted aand gained further access elsewhere so you need to check everything. Don’t skip on checking those longs and figuring out the impact!

Eradicate, recover, and restore

Once you’ve found the issue, go ahead and fix it. Then, use backups to restore clean versions of systems.

I can’t emphasize enough that it needs to be clean. If your backups are connected to the compromised network, then they could also be affected, so offline or off-site copies are safest.

Learn and report

Even if you’re a 1-person team, it’s worth keeping track of issues and making an incident report for yourself after you fixed it.

It might seem like overkill, but these can be incredibly helpful for yourself and future team members.

So go ahead and make a note of:

What happened?
What was the root cause?
What was the solution?
Did anything cause delays?
How can you improve on this next time?
How can you prevent this from happening again (or reduce the chances)?

Start monitoring today!

You can’t control whether a vendor gets hacked, but you can control how ready you are when it happens:

Review the tools your company already uses
Check what data they have access to
Tighten permissions by role
Remove what’s unnecessary, and document what’s left

Then build habits:

Test updates before rolling them out
Set up monitoring for your systems
And keep a clear response plan ready for when something slips through

The work you do now could be the reason a future breach stops at one system instead of spreading across your entire network.

P.S.

Just a heads up, but if you decide to join Zero To Mastery as a member, you get access to ALL of my Cyber Security courses and more.

Every tech course on the platform is available in a single membership, as well as access to our private Discord server.

Here you can chat to me, other students, and working cyber security professionals, and get help with any questions you might have 24/7.

It’s the best investment you can make to improve your Cyber Security in 2025.

Best articles. Best resources. Only for ZTM subscribers.

If you enjoyed Aleksa's post and want to get more like it in the future, subscribe below. By joining over 400,000 ZTM email subscribers, you'll receive exclusive ZTM posts, opportunities, and offers.

No spam ever, unsubscribe anytime

Check out my other articles and guides: