One of the key cybersecurity problems for business entities that use open-source software, third-party libraries, cloud services, development tools, and CI/CD pipelines is software supply chain attacks.

Contrary to regular cyberattacks on the company’s network, supply chain attacks involve compromising a trusted component and using it to attack many victims. The recent happenings in the open-source community demonstrate how fast malicious code, stolen credentials, and compromised software packages are spreading.

The latest software supply chain attack news today reveals yet another trend: hackers focus on the trusted tools that developers use more and more frequently rather than hacking each company separately.

Latest Software Supply Chain Attack News

Recent cybersecurity news shows that software supply chain threats are common in many ecosystems.

One of the major pieces of news this week is related to TeamPCP. The Australian police, with the assistance of the FBI and Western Australia Police, have accused two men who are connected to TeamPCP. According to the claims, the team used malicious open-source software to steal credentials from organizations worldwide.

This event is quite significant since it proves that there are numerous consequences of software supply chain attacks. If there is some malicious code in trusted software, the attackers will be able to get access to credentials and environments of downstream organizations.

Another interesting development concerns the LiteLLM software supply chain attack. Researchers discovered that it could affect 2,500 organizations and almost 434,000 CI/CD pipelines, thereby exposing cloud credentials, repository credentials, and other secrets.

What Is a Software Supply Chain Attack?

software supply chain attrack

A software supply chain attack means compromising a trusted component of the software development or distribution process by the attacker.

Contrary to attacks on the target itself, the attacker compromises:

  • Open-source library
  • Software vendor
  • Developer account
  • Package repository
  • Build server
  • CI/CD pipeline
  • Software updates process
  • Third-party service

This component allows the distribution of malicious code or gives access to the downstream environment.

Example

Consider the following chain:

Developer → Open-source library → Application → Customer

In case of exploitation of an open-source library, the malicious code will have an effect on any application that uses the corresponding version of the library.

Therefore, supply chain attacks are very dangerous because the place of the attack is far from the target object.

Why Are Supply Chain Attacks Growing?

Today, software development includes numerous third-party components.

Developers do not develop everything by themselves but use libraries, frameworks, APIs, packages, containers, plugins, and cloud services.

The more complex the dependency chain is, the more difficult it is to monitor each component manually.

Software Component Potential Risk
npm package Malicious or compromised code
Python package Dependency or maintainer compromise
Container image Vulnerable embedded software
GitHub account Unauthorized source-code changes
CI/CD pipeline Credential theft or malicious builds
Software update Malicious release distribution
Third-party vendor Access to customer environments

The larger the dependency chain becomes, the more difficult it can be to monitor every component manually.

Open Source Software – The Main Target of the Attackers

Open source software plays an important role in software development recently. why such software becomes an attractive targets for attacks is that sometimes a package might be installed thousands or even millions of times; if the attacker manages to control a maintainer account or to publish malicious releases, the situation can be critical. A number of recent incidents were related to the ecosystems of npm and Rust.

For example, some malicious versions of several Rust crates were removed after publication in the compromised maintainer account with a build-time payload.

In addition, security researchers found a number of supply chain attacks against the npm ecosystem.

Credential Stealing is Important for Attackers

Today, most supply chain attacks are focused on stealing credentials rather than damaging software.

Credentials allow the attacker to gain access to:

  • Cloud platforms
  • Git repositories
  • CI/CD systems
  • Package registries
  • Databases
  • Kubernetes environments
  • Internal applications

Such access will enable the attacker to penetrate further into the infrastructure of the attacked company.

The incident with LiteLLM can be regarded as an example of the significance of this fact. According to the researchers, there was the potential exposure of AWS, Google Cloud, Azure, SSH keys, and Kubernetes-related credentials.

How Are Supply Chain Attacks Spread?

Usually, the process of such attacks includes the following steps:

  1. Initial compromise – the attacker gets access to the package, developer account, repository, or build system.
  2. Malicious modification – the attacker adds some malicious code or makes other unauthorized changes.
  3. Trusted distribution – the compromised software gets distributed through a legitimate channel.
  4. Automatic installation – the developer or CI/CD system installs the package.
  5. Credential/data theft – the malicious code tries to get secrets, credentials, source code, and any other useful information.
  6. Further access – in case the credentials are obtained, the attackers might access other systems.

Recent npm Supply Chain Threats

There have been several recent reports on supply chain security in the npm ecosystem.

Attacks that utilize compromised packages, developer credential theft, and malicious releases have been discovered by security researchers.

This year, a number of open-source supply chain attacks on npm packages have been associated with North Korean threat actors by Amazon, as reported by BleepingComputer.

Those attacks show that organizations must not assume that a popular package is necessarily safe to use.

The popularity is what may make it interesting to attackers.

The Value of CI/CD Pipelines

CI/CD systems allow for faster software delivery, but they may be interesting targets themselves.

A common pipeline would typically:

  1. Download dependencies.
  2. Build the application.
  3. Run tests.
  4. Use cloud credentials.
  5. Create containers.
  6. Deploy software.

If the malicious dependency runs while building the application, it might get access to the secrets that are available to the build system.

That is why organizations must try to minimize the permissions that CI/CD jobs will use.

How Organizations Can Limit Software Supply Chain Risk

Organizations can not remove all software supply chain risks, but they can certainly limit their exposure.

Keep Track of Used Software Components

Organizations must know which software components and dependencies they use.

Pin Important Dependencies

Production systems must not allow to pull unpredictable versions of dependencies.

Check Dependencies for Vulnerabilities

It is important to periodically check for known vulnerabilities in the dependencies.

Protect Developer Accounts

Authentication must be sufficiently robust, and multi-factor authentication must use where possible.

Limit CI/CD Permissions

The build system must be able to do only those actions that it needs.

Protect Secrets

Cloud credentials, API keys, and deployment tokens must not unnecessarily expose to the build system.

Monitor Package Ownership Changes

Any change in package ownership must carefully consider.

Software Supply Chain Security Checklist

software supply security checklist

Security Measure Why It Matters
Dependency inventory Identifies what software is being used
Version pinning Reduces unexpected changes
Vulnerability scanning Finds known security issues
MFA Protects developer accounts
Least privilege Limits attack impact
Secret management Protects credentials
Package verification Helps identify suspicious releases
CI/CD monitoring Detects unusual build activity
Incident response Speeds up containment

What Developers Should Do After a Supply Chain Alert

When a new vulnerability in the supply chain becomes known, there should be no need to panic but rather to verify it.

First, establish whether the affected package or service is really used in the environment.

Next:

  1. Establish the affected version.
  2. Check if the application uses it.
  3. Review the security advisory.
  4. Examine recent changes in the package/dependency tree.
  5. Apply the required upgrade/downgrade.
  6. Rotate potentially exposed credentials.
  7. Review the CI/CD logs.
  8. Examine the repositories and build systems for any suspicious activities.
  9. Monitor the affected system(s) after the remediation.

Rotation of potentially exposed credentials is especially critical in case there were indications that secrets revealer.

Why Software Supply Chain Security Is Becoming a Business Issue

Supply chain security is not an issue solely for developers anymore.

The success of an attack would have repercussions on business operations, customer data, intellectual property, compliance issues, and the company’s reputation.

It is possible that an affected dependency can get into production before the security team realizes something is going on.

In this regard, cooperation will require by the following parties:

  • developers
  • safety teams
  • IT administrators
  • procurement teams
  • cloud engineers
  • business leadership

The security aspect must be taken into account at the vendor and software selection phase, not only as a response to incidents.

The Future of Supply Chain Security

The software environment is likely to become even more intertwine.

Companies will rely on more:

  • open source software
  • AI frameworks
  • Cloud services
  • Development automation
  • Containerization
  • Third-party APIs
  • software as a service

However, at the same time, security vendors and development platforms will introduce more stringent controls. For example, GitHub and PyPI introduced time-based defenses aimed at limiting the impact of malicious packages.

Frequently Asked Questions

What is a software supply chain attack?

It is an attack on software, dependencies, development infrastructure, or any other trust entity that is used to target downstream users.

Why are software supply chain attacks dangerous?

The nature of the attack allows it to spread via trust software and reach many organizations without compromising each one of them directly.

Are open-source packages dangerous for security?

Open-source packages themselves are not dangerous in terms of security. However, companies need to monitor their dependencies because maintainers, packages, and releases may be compromises and create risks for organizations.

What should businesses do after a supply chain attack?

They need to check whether they are impact, find the compromised components, apply all suggested fixes, rotate potentially exposed credentials, check logs, and monitor their system.

How can developers protect npm dependencies?

Developers should keep an inventory of their dependencies, monitor vulnerabilities, watch for changes in packages, control versions of their packages, protect npm credentials, and limit CI/CD permissions.

Can a supply chain attack steal cloud credentials?

Yes. When malicious code runs in an environment where cloud credentials are store, attackers will try to obtain those credentials. Recent events showed that it is crucial to protect CI/CD secrets.

Conclusion

Modern supply chain attack news proves that attackers still target relationships between developers, open-source projects, software vendors, package repositories, and businesses.

Cases with TeamPCP, LiteLLM, npm, and other ecosystems show how compromising software can potentially reveal cloud credentials and give attackers access to downstream environments.

The key thing that needs to be understood both by businesses and developers is that software security should not limit only to the application itself. Each of the dependencies, packages, developer accounts, build systems, and third-party services can include in the security chain.