In my years of experience supporting the federal government in different capacities, I have seen the evolution of attack methods match the pace of innovation as our information systems become even more advanced. No matter the state of the technology, it is always that proverbial "cat and mouse" game where the good guys try to stay ahead of the bad guys. As this never-ending battle continues, one of the new kinds of software supply chain attacks caught many organizations and agencies off guard early this year when a researcher revealed that he had successfully infiltrated his own code into applications for a surprising number of well-known companies.
Developers in the federal space are not immune from the attack affecting 35 major technology companies disclosed in February 2021. Although many federal systems take additional steps to protect themselves, the vulnerability overlaps both commercial and government systems; meaning extra steps are necessary to protect government development environments.
What is dependency confusion?
The "attack" by a whitehat security researcher on the popular open source JavaScript package provider npm exploits an issue in many software namespaces. This allowed him to inject his own code into the JavaScript ecosystem and appear inside of the target companies' production applications. While this specific effort involved companies that welcome this kind of open source scanning of their application security, it did not take long for copycat attacks to emerge that had more nefarious intentions.
The npm attack involved a technique called dependency confusion or "namespace confusion" and is in the same territory as a typo-squatting attack, but with some key differences. Typo-squatting attackers publish packages with misspelled names that may get consumed due to human errors when typing in dependency data. Package managers defend against this by routinely cleansing their repositories when they see typo-squatting activity. Often companies will reserve names that are close to their real package names to help prevent bad actors from capitalizing on human errors.
This attack involved the researcher being able to figure out the names of internal packages for a company's application and then publish a package with the same name but a higher semantic version of a package already in use and not in a regulated namespace or scope. When automated software development tools update their dependencies they often look to external sources as well as internal sources. This may confuse the tools and trick them into skipping the private internally developed package because the attacker’s public package had a higher semantic version.
Why are many open source repositories vulnerable?
Well the whole idea of open source is to share, right? The rise of open source software (OSS) is greatly attributed to the value of the public sharing of code, presenting both new advantages and risks. As OSS has evolved, so have the protective measures to ensure the risk is minimized, but not all languages are at the same state in their evolution.
Language package ecosystems like Sonatype's Maven Central Repository for example have very structured naming standards (e.g. reverse fqdn) where the author of the code must own the DNS domain that resolves to the namespace in Sonatype's Maven Central Repository. This allows for globally-unique package names and helps prevent dependency confusion. While npm has implemented "scopes" that create a similar method of control, they still lack validation of who can claim scopes and push new artifacts.
How are applications in the federal space affected?
While hardened standards and security controls combined with protected networks prevent a variety of attacks. Federal systems remain vulnerable to more sophisticated attackers. In December 2020, the SolarWinds Orion hack used a software supply chain attack to back door both commercial and government systems alike. Over 18,000 customers using the component were affected and the full extent of the damage is still being investigated today.
The federal response to increased software supply chain attacks
After the recent SolarWinds hack the federal government has firmly committed to increase the security of federal application workloads through a push for stricter policies and a greater focus on innovation. Sonatype is uniquely positioned to help the government achieve greater security through our decades of cumulative component research and the ability to create the necessary comprehensive software bill of materials (SBOM) that will be required for all federal applications. The SBOM capability should be a priority for protecting the software supply chain for federal teams and include controls for all stages of the lifecycle from coding to deployment. All with full visibility of the components that flow through the supply chain to finished applications.
During the writing of this article, another headline-grabbing cyber attack occurred on the Colonial Pipeline. While not known to be a supply chain attack, the White House took action to sign an Executive Order that now mandates tighter security for the software supply chain. The order was signed by the President on May 12, 2021 and mandates the use of the SBOM specifically for all federally purchased software and "ensuring and attesting, to the extent practicable, to the integrity and provenance of OSS used within any portion of a product."
This order now makes the use of Sonatype Nexus Repository, Sonatype Repository Firewall, and Sonatype Lifecycle more important than ever to ensure a secure and compliant federal software development practice.
More on the Biden Executive Order.
How do supply chain attacks work for the federal sector?
Application development teams in the federal space are mostly in the same boat as commercial companies, and are still subject to dependency confusion attacks. While many operate in "air-gapped" or high security enclaves, the use of OSS in the federal space has grown immensely, and that means someone or something is replicating software packages from the public side to the government side. Currently, more than ever before software teams in the federal space are using OSS packages to build applications in unclassified environments and then ship the bundled artifacts to higher security environments. There are also various programs that encourage OSS and commercial vendors to make their software packages available in secure collaboration and code sharing repositories in the Department of Defense hosted by programs like Iron Bank and Platform One. The problem is that if the wells that supply the code are poisoned, then malware could find their way through to our most protected applications and networks unless there are the proper tools and disciplines in place to secure the entire software supply chain.
What can mission owners do to protect their software supply chain?
Never updating anything is something you might laugh at but I have seen it used. While it might work to avoid dependency confusion, it comes with a host of other issues. As we're fond of saying: software ages like milk, not wine. Meaning even when packages are currently not known to have risks, it doesn't mean that new vulnerabilities won’t be uncovered later down the road. Furthermore, app teams need to be ready to roll forward quickly with improvements and mitigations. A head-in-the-sand approach stifles innovation and causes software to miss out on strategic enhancements.
Preventing software supply chain attacks means implementing a proven and reliable way to ensure that only trusted OSS software packages are available from a securely hosted source that delivers management and security across your software development lifecycle (SDLC).
Thankfully, we at Sonatype have pioneered a trusted, end-to-end solution to protect your application ecosystem and add efficiency to your SDLC through our Sonatype Nexus Repository, Sonatype Repository Firewall, and Sonatype Lifecycle products. During the npm attack mentioned above, Sonatype's malware detection systems automatically lagged the researcher’s suspicious packages. Those customers taking advantage of our advanced security tools we protected from both the ethical hack and malicious copycat attacks after the public disclosure.
Current Sonatype customers who have our premium offerings for Sonatype Nexus Repository and Sonatype Repository Firewall can find guidance in our documentation. If you are not yet a customer and wish to find out more about how to protect your supply chain from these dependency attacks, please contact our sales team through our contact page or request a demo.
The diagram below illustrates a software supply chain (Develop, Build, Package, etc.) and the Sonatype products that support a secure practice.
What would a Sonatype-protected SDLC look like?
Sonatype products are engineered to work in a wide variety of development structures, including on-prem, bare metal, virtualized systems, all major Cloud providers, containers, and "air-gapped" environments. The diagram below shows a development workflow and many of the tools and package repositories that integrate with the Sonatype Platform.
Having the Sonatype Platform deployed to protect all stages of the SDLC with policy enforcement, continuous monitoring of applications, vulnerability identification, and remediation tools in place enables mission owners to reduce risk and streamline secure development practices. Enable your developers to mitigate risk in the early stages of the SDLC and benefit from reducing major rework cycles that often plague software development.
What if my network is air-gapped?
Sonatype's options should work for most federal requirements, and we can work with individual customers to customize an effective solution for your unique situation. Sonatype provides a fully functional "disconnected" version of our product suite that operates in high security environments or fully "air-gapped" enclaves.
It takes a team to win
If there is anything I've learned in helping to innovate in the federal space, there is no one person, vendor, or tool that equals an "easy" button. It takes dedicated people working together across companies, agencies, and solution-integrators to achieve success. Sonatype recognizes that, and we commit to working together with our federal customers to get the outcomes they seek and meet them where they live.
Hopefully, you will have read this post and gained some insight into how to better secure your software supply chain, or at the very least, you know where to look for more information. Thanks for your time, and please reach out if you have any questions or would like to have one of our representatives dig deeper into finding a solution that fits your needs.
Contact Us or Request a Demo | Accelerate Software Innovation
.png){kind=logo}