Software supply chain attacks are extremely prevalent and a great way for attackers to easily proliferate a single vulnerability across an entire organization to have maximum impact. Thankfully, mitigating these three types of threats is easy by utilizing Anchore’s automated policy enforcement throughout your software supply chain.
In this article, I’m going to walk through three types of software supply chain attacks and how Anchore helps in each scenario.
Penetrating Source Code Repositories: Exploiting a Known Vulnerability in the Software Supply Chain
The first type of attack begins in a source code repository. Attackers aren’t dumb and they don’t like to waste time. This is why advanced persistent threats typically leverage a software package that is known to have an exploited vulnerability that is being actively exploited. Even today, over a year after the log4shell vulnerability there are still recent exploitations that entangled the security industry in a vice grip. Incidents like this can all be mitigated automatically with Anchore’s Known Exploited Vulnerabilities (KEV) policy.
Leveraging Anchore’s policy pack, I am able to scan against all of CISA’s Known Exploited Vulnerabilities. This will allow me to detect KEV’s across my SDLC whether it's in a GitHub repo, image registry, or runtime. What’s more is that Anchore provides a recommendation for remediation that can automatically notify team members to remove that package from your development process.
Registry Poisoning: An Image with Malware appears in a Trusted/Protected Registry
This is a popular attack vector. In 2021, the Anchore team saw threat actors use this style of attack to proliferate cryptominers and malicious software across target environments with relative ease. Anchore can detect and prevent these attacks by keeping a watchful eye on customers’ registries, allowing us to continuously monitor that registry for unauthorized pushes of malicious images.
Anchore Enterprise 4.4 continuously monitors repositories within a registry
Anchore Enterprise 4.4 continuously monitors images and all tags within a registry
I’m going to dig in on a very oddly worded PostGres Image that was scanned and automatically triggered a notification about malware in that image. In this example, this attacker combined registry poisoning with typosquatting. Anchore detects the malware in the image and triggers an alert based on that image analysis for my investigation. It’s important to note here that it’s a very unique feature that Anchore provides a malware scan as a part of every SBOM.
In an ideal scenario, developers would be following a software supply chain security architecture that would utilize Anchore policy enforcement that scans for malware before it hits the registry. However, as we have seen in many supply chain attacks since, credentials tend to be left on CI servers, in pipelines in plain text, source code repositories, or on a post-it note left at a coffee shop. Hence, this is a good reminder why we should always be continuously monitoring the registry to prevent registry poisoning attacks.
Cloud Credential Leak: Credential is Unintentionally Left Behind in a Build Artifact
Not all software supply chain attacks are malicious in nature. Some are simple human errors. While the intent isn’t meant to cause havoc, the leaking of a credential (or secret) can still have a lasting impact. Even the most security minded organizations can be hit with an incident of credential leakage.
In March of ‘23 GitHub experienced a very public instance of this supply chain attack. An accidental commit to a public git repository revealed the private key for GitHub’s entire SSH service. This created the opening for an enterprising attacker to set up a fake GitHub service and masquerade as GitHub with full legitimacy. The ultimate deep fake. Fortunately, GitHub caught it quickly and rotated their key out of an abundance of caution.
In order to prevent a potential catastrophic incident like that from happening to your organization it is important to scan your entire SDLC for credential and secret leaks. Catching the exposure before it is pushed to a publicly accessible location mitigates a potential sev 0 before it happens. Actively scanning for leaked secrets has the added benefit of helping prevent the previous attack we highlighted from occurring as well. It is difficult to poison a private container registry when the environment is protected with a secret (that hasn’t been leaked).
Anchore Enterprise offers the ability to use policies to scan images and discover leaked credentials before they are deployed to production. The policies can be configured to enforce a preset action if the presence of a secret is detected, preventing a security incident from happening before it starts.
I hope this article provided insight into the three most popular types of software supply chain attacks and how they happen. Anchore’s technology platform provides the confidence and tools needed for developers and security teams to stay ahead of malicious threats to your software supply chain. If you want to learn more click here to request a demo or watch one of our recent webinars.
