How to stop cybersecurity attacks on the supply chain

Automatic updates, trusted providers, and cloud services have become commonplace in any business, and the absence of one Zero Trust policy It worsens the risk. The problem is that that same trust has become a perfect target For attackers, this means they no longer try to enter through the front door, but rather sneak in through seemingly harmless suppliers, development tools, or software components.

Every time you install a patch, add an open-source library, or grant access to a managed provider, you are expanding your attack surface. So-called supply chain attacks exploit precisely those weak links.and can affect thousands of organizations worldwide with a single well-placed blow.

What is a supply chain attack and why has it skyrocketed?

Un A software supply chain attack occurs when cybercriminals do not directly target the end victim.but rather they infiltrate at some intermediate point: a software vendor, an MSP, a development tool, a container registry, or even hardware and physical media.

Instead of tearing down the walls of a large company or a public body, Attackers prefer to infiltrate a smaller provider or one with fewer controlsBut it has privileged access to critical networks and data. It's a typical "easy way out" attack: less resistance, fewer controls, more access.

A very common scenario is that of manipulated updates: The attacker compromises the compilation or distribution environment of legitimate software and inserts malicious code. in a signed and seemingly normal patch. When customers install that update, they unknowingly open a backdoor in their own infrastructure.

This approach is so appealing because It allows you to compromise thousands of systems at once.Instead of attacking company by company, it is enough to attack the provider that serves them all: monitoring platforms, VoIP tools, accounting software, open source libraries, etc.

Added to this is an increasingly complex environment: hybrid and multicloud environments, digital supply chains, and a vast ecosystem of third and fourth partiesSecurity teams are overwhelmed by alerts and false positives, and detecting the real anomaly amid the noise is a constant challenge.

Real cases that changed the rules of the game

SolarWinds: the blow that put the issue in the headlines

The incident of SolarWinds has become almost a textbook case. Regarding supply chain attacks, SolarWinds is a US provider of network monitoring and management tools, and its Orion platform was used by more than 30.000 public and private organizations, including top-tier government agencies.

In this attack, an advanced group (attributed to APT29, also known as Cozy Bear) managed to infiltrate the SolarWinds build environmentFrom there, they injected the malware SUNBURST in the official Orion updates, which were distributed signed and completely “legitimate” to thousands of customers.

The compromised updates began circulating around March 2020 and The attack was not discovered until December of that same year.When FireEye detected suspicious behavior, attackers had free rein to steal information, move laterally, and deploy more malware in organizations worldwide for months.

The potential scope was brutal: some 18.000 organizations could have been affectedincluding key US government agencies and large multinational corporations. Although the actual number of exploited victims was lower, the scale of the impact triggered a global crisis of confidence in supply chains.

The consequences were not long in coming: New government guidelines for secure development, increased scrutiny of critical suppliers, and a thorough review of upgrade processes in all types of organizations. SolarWinds, for its part, faced reputational damage, lawsuits, and a long list of regulatory requirements.

3CX: Business communications as a gateway

In 2023, the communications provider 3CX suffered a large-scale attack on its supply chainTheir desktop applications for Windows And macOS, used by companies around the world for VoIP and unified communications, were the vector.

The attackers They managed to manipulate the 3CX software installation processThe installer secretly loaded a Trojan horse that established communication with command and control (C2) servers, allowing criminals to collect data and expand their presence on compromised networks.

Further investigations point to an even more sophisticated scenario: It could be a “double supply chain attack”The attackers reportedly compromised another application first before gaining access to 3CX. The case has been linked to the Lazarus Group, which has ties to North Korea and is known for espionage campaigns and theft of funds.

Given 3CX's global reach, The number of potentially affected systems is in the hundreds of thousands or even millions.The main objective was to obtain sensitive information, access credentials, and records of business communications.

3CX had to act very quickly: patch releases, public notices, and active crisis managementEven so, many customers were severely shaken in terms of trust, as the attack occurred through verified installers whom they were supposed to be able to trust blindly.

Stuxnet: the first major industrial “cyberweapon”

Although it is earlier, the case Stuxnet remains a benchmark for advanced attacks against industrial infrastructure.This worm was specifically designed to sabotage Siemens control systems used in the Iranian nuclear program, specifically the uranium enrichment centrifuges.

The attacked network was isolated from the Internet, so The attackers resorted to memories USB infected to introduce the malwareEverything points to an external technician or employee unknowingly introducing a contaminated device into the internal network.

Stuxnet exploited several zero-day vulnerabilities in Windows, allowing it to propagate undetected and manipulate the Siemens Step7 softwareOnce inside, he discreetly altered the speed of the centrifuges while displaying normal readings on the control panels.

The result was a silent sabotage: The centrifuges were being physically damaged without the operators suspecting anything.Investigations point to a joint US-Israeli project to curb Iran's nuclear program.

Stuxnet marked a turning point: It demonstrated that cyberattacks could cause very specific physical damage. and accelerated the adoption of security controls in industrial systems (ICS/SCADA), which until then many considered protected because they were "isolated".

Other relevant attacks: Target, NotPetya, CCleaner, Codecov, Kaseya

Supply chain attacks are not limited to management software or communications; Any sector with interconnected suppliers is potentially vulnerable.Some illustrative cases:

• Target (2013)An HVAC supplier had their credentials compromised, which were used to break into the retail chain's systems and steal some 40 million payment card records.
• NotPetya (2017)It was distributed through a corrupted update of the Ukrainian accounting software MeDoc. Although presented as ransomware, it acted as a destructive wiper, rendering the systems of companies like Maersk and Merck unusable.
• CCleaner (2017)The attackers compromised the development environment of the popular cleaning tool, adding malware to its official installer. Millions of computers were affected, and in certain technology companies, a second phase of highly targeted espionage was activated.
• Codecov (2021)Using a credential exposed in a Docker image, an attacker modified a script charging so that would send the environment variables of the CI systems to a server controlled by the criminalsFor months they were potentially able to access secrets and continuous integration systems of numerous clients.
• Kaseya VSA (2021)Kaseya is a management platform used by many MSPs to deploy patches and monitor clients. Attackers compromised Kaseya's infrastructure and pushed malicious updates to local VSA servers. distributing ransomware en masse to managed companies.

All of this is part of an upward trend: Gartner estimates that by 2025, 45% of organizations will have suffered some kind of attack on their software supply chaintripling the 2021 figures. And the affected names include giants like Samsung, Uber, Nissan or Nvidia.

Why these attacks are so dangerous (and difficult to stop)

Supply chain attacks are notable for their ability to provoke large-scale damage with a single point of compromiseInfecting a popular update, a widely used open-source package, or an MSP's core tool can affect thousands of customers and millions of end users at once.

Furthermore, their success is based on something very human: trust. Organizations rely on their security vendors, signed updates, and the tools they use daily.If an update arrives signed and through an official channel, practically no one suspects that it might contain a backdoor.

This makes detection extremely complicated. The rear doors arrive through certified channels.They are integrated into normal deployment or compilation processes and can remain undetected for months or years, especially in environments with a high alert load.

In many cases, by the time the attack is discovered, it is already too late: Sensitive information has been exfiltrated, credentials have been stolen, or malware has enabled deep lateral movement.If the compromise affects firmware or hardwareThe solution may require physical replacements, and sometimes even reinstalling the operating system won't completely clean the environment.

All of this is exacerbated by the current complexity of supply chains. Globalization, outsourcing, and the massive use of third parties and open source. They increase the attack surface. A failure or poor practice at any link can become the entry point that attackers need.

Why development infrastructure and DevOps are the new star target

For years, security focused almost exclusively on production applications: WAF, vulnerability analysis, application scanners (AST), SCA, etc.But attackers have realized that development infrastructure is an equally or even more lucrative target, and far less protected.

The entire DevOps ecosystem—repositories, version control systems, CI/CD servers, build tools, scripts, IaC templates, containers— It forms a huge attack surface that often escapes the direct control of security teams.It is usually managed by development and operations teams, more focused on speed than hardening.

In this context, textbook errors are repeated: credentials and API keys hardcoded in the source code for quick testingSecrets stored in plain text, Git histories with sensitive information that is never completely cleaned up… Even if those files are deleted, attackers can recover them from the history.

With just a few valid credentials, cybercriminals can move laterally throughout the SDLC: from the repository to the CI server, from there to the container registry and finally to the production environmentsAlong the way, they find it easy to insert malicious code or perform DLL hijackingextract data or install persistent backdoors.

Added to this are repositories and tools that are poorly configured or directly exposed to the Internet. An open VCS, a CI instance without strong authentication, or a poorly secured bucket. enough to put at risk not only the code, but also the systems that will later deploy that code.

The risk of open-source packages and third-party components

Open source is wonderful for accelerating development and sharing solutions, but It's also a great way for attackers to sneak in unnoticedThere are two main risk scenarios:

On one hand, known vulnerabilities in very popular librariesAs in the case of Log4j, vulnerabilities can be exploited on a massive scale if organizations are slow to patch them. While this isn't exactly a supply chain attack, it demonstrates how a single common component can compromise half the planet.

On the other hand, in the purest supply chain attacks, Attackers find ways to inject malicious code into widely used open-source packagesIf they manage to publish Trojanized versions, or gain control of a maintainer account, the malware will automatically spread to all organizations that update those dependencies.

Since most of these projects are public, A security flaw can be discovered by an attacker before it is discovered by the community or the maintainers themselves.From there, it's simply a matter of creating exploits and waiting for the affected companies to deploy the vulnerable component in production.

All of this makes managing dependencies and third-party components a critical task: It is not enough to "trust" that the open source ecosystem monitors itselfWe need to constantly inventory, monitor, and control what goes into our codebase.

Particularly attractive targets: security providers, MSPs, and visible structures

Not all goals have the same value. Security providers are, paradoxically, a very tempting target.If an attacker manages to introduce malicious code into your infrastructure or updates, they can divert confidential customer data from those who relied on you for protection.

Managed service providers (MSPs) are also in the spotlight. A single committed MSP is equivalent to entering through the back door of dozens or hundreds of customersWith the right code, an attacker could steal the MSP's credentials, move them to their clients' systems, encrypt data, divert payments, or manipulate support dashboards.

Another increasingly exploited vector is BEC (Business Email Compromise) associated with the supply chain. Any organization with public organizational charts on social media or on its corporate website It serves as a basis for social engineering campaigns.

The attacker can compile a list of executives and employees with high privileges and impersonating others to force fraudulent payments or bank account changesFurthermore, if he were to compromise the email of a legitimate supplier, he would have a direct line to deceive internal employees with altered invoices or payment orders.

The common outcome in all these scenarios is the same: When the supply chain is attacked, the impact is rarely limited to a single company.There is often a domino effect that impacts many interconnected organizations.

Key best practices to curb supply chain attacks

Reducing risk is not impossible, but it does require a broader approach than simply "putting up a firewall and antivirus software". A comprehensive Supply Chain Risk Management (SCRM) strategy is needed. that covers both the technical aspects and the relationship with suppliers.

1. Discovering and controlling shadow IT

In many companies, official systems coexist with unapproved tools and services that teams have adopted on their own. Auditing and locating this shadow IT is the first step to truly understand what is being used and what potential entry points exist.

It is essential to maintain a updated inventory of software assets and services, including development tools, SaaS contracted by business areas, and small scripts that have grown with ThereAnything that isn't under radar is a potential hole.

2. Evaluate and monitor suppliers continuously

It is not enough to ask for a security questionnaire at the beginning of the contract and forget about it. A supplier's security posture should be reviewed regularly.especially in critical providers (MSP, security, communications, monitoring, accounting, etc.).

It is advisable to treat the Supplier risk validation as a living process: periodic reviews, requirement of standards (ISO/IEC 27036, NIST SP 800-161), specific clauses for incident notification and transparency in their own supply chain.

3. Strengthen the software supply chain and the SDLC

Software development and delivery must be secure from the first line of code. Some fundamental practices are:

• To implant strict code integrity policies and allowlistsso that only authorized applications and binaries can be run.
• Protect as much as possible compilation and update infrastructurewith granular access controls, strong authentication, environment segregation, and continuous monitoring.
• Integrate the security throughout the development lifecycle (NIST SSDF, OWASP recommendations), including code reviews, penetration testing, and automation of controls in CI/CD pipelines.
• To create and maintain a SBOM (Software Bill of Materials) that details libraries, versions and components, in order to respond quickly to new vulnerabilities.

Every change to the code or configuration must leave a trace: record, signature and traceability of who did what and whenThis helps both to prevent manipulation and to investigate it if something goes wrong.

4. Protect repositories, registries, and client environments

Version control systems (GitHub, GitLab, Bitbucket) concentrate a huge amount of sensitive code. It is essential to strengthen the security of these platforms with measures such as SSO, two-factor authentication, and role-based access restrictions.

Furthermore, it is advisable to apply strict branch protection rules (branch protection): mandatory pull request reviews, prohibition of direct commits to main branches, commit signatures, and automated controls to prevent merging unreviewed code.

Container image registries (Docker Hub, private registries, etc.) cannot be neglected either. They must be analyzed continuously to avoid image "poisoning". and block those that present serious vulnerabilities or do not comply with internal policies.

In client environments, tools such as EDR (Endpoint Detection and Response) and browser-side protection They can help detect anomalous behavior caused by Trojanized code, malicious scripts, or compromised libraries.

5. Implement supply chain-oriented monitoring and incident response

Continuous monitoring is key, but it must be focused on the specific risks of the supply chain. It is critical to monitor for anomalous access to development tools, suspicious changes in pipelines, and modifications to container logs. and strange behavior in updates.

All of this must be integrated into a formal incident response processthat considers scenarios involving vendor, software package, or CI/CD infrastructure compromise. The clearer the plan (what to do, who decides, how to isolate, how to communicate), the less chaotic the reaction will be.

Many organizations complement this approach with cyber-risk insuranceHowever, this should never replace preventive measures and early detection.

The SCRM approach and the importance of continuous improvement

A solid strategy of Supply Chain Risk Management (SCRM) encompasses everything from the initial selection of components and suppliers to the final delivery to the user.This is not a one-off audit, but a continuous cycle of evaluation, mitigation, and improvement.

NIST frameworks (such as SP 800-161 for supply chain risk management) and standards such as ISO/IEC 27036 for secure supplier relationships They offer clear guidelines for structuring this approach. Applying them doesn't guarantee immunity, but it greatly raises the bar an attacker must overcome.

Within this model, it is very useful to rely on periodic audits and certifications of products and processesBoth internal and external. Independent certifications, laboratory testing, and ongoing assessments help detect security deviations before they become breaches.

La Artificial Intelligence and machine learning also plays an increasingly important role: Specific models allow the identification of anomalous behaviors and zero-day attacks. with high detection rates and fewer false positives. Combined with additional layers such as anti-spyware tools or advanced secure data erasure solutions, they build a defense-in-depth scheme.

Ultimately, the goal is to create a security chain that goes from the first line of code to the final download or updateIf there is visibility, controls, and response mechanisms at each link, any attempt at manipulation will have less room to maneuver.

The current situation forces us to change our mindset: it is no longer enough to protect your own castle, you also have to watch the bridges, the roads and the back doors that connect with third parties. Those who treat the security of their supply chain as a strategic responsibility—and not as a mere formality—will have a much better chance of dodging the blows.And when one arrives, because they will arrive, the important thing will be that the damage is contained and does not become a chain reaction capable of paralyzing the entire organization.

Related article:

What is Application Security Posture Management (ASPM) and how does it improve the security of your applications?

Isaac

Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.