In recent years more open source vulnerabilities have been discovered than ever before. This is all part of the natural evolution; it’s what we expect to see as the amount of open source usage grows within organizations. But there’s something that we missed in this equation: while identifying vulnerabilities, organizations haven’t found a way to block unwanted dependencies, which made them vulnerable to attacks like never before.
The increasing number of software supply chain attacks has created awareness and made secure management of open source dependencies a top priority for businesses.
This article gives you an introduction to events that helped create awareness during 2021 and where the industry stands today. It’s becoming more and more clear to leaders and developers that new technology is required to protect organizations from becoming victims.
What? The next wave in enterprise application security are dependency security solutions.
A new kind of infrastructure, a Dependency Firewall, sets up a secure perimeter against threats from malicious or vulnerable open source packages used in an organization.
Why? Technology evolves rapidly, making software vulnerable to new threats at a rapid pace. Just last year Log4j and Spring4Shell were driving the news in the media. Even though the threat is always increasing, many DevOps teams lack the tools they need to maintain their software. The use cases in this article help you understand why a Dependency Firewall is an important component in a secure software supply chain.
Continue reading to learn more about how businesses can benefit from elevating security using a Dependency Firewall to secure software supply chains.
Software Supply Chain attacks in 2021 and 2022
The success of software supply chain attacks in 2021 makes it certain that it will remain an important part of criminal activity throughout 2022.
The starting point in 2021 was the SolarWinds attack where software supply chain attacks were put in the spotlight and created awareness among companies.
In addition to SolarWinds there were other attacks such as the painful log4j, spring4shell, ua-parser and many others. The world has also opened its eyes to Dependency confusion attacks where supply chains are tricked into replacing internal packages with public malicious ones.
Software Supply Chain attacks, where attackers distribute vulnerable, or malicious code, are often very efficient as once attackers penetrate the supply chain, all downstream consumers will be affected. This is why supply chain attacks are often expensive and time consuming to recover from.
It has become evident that the software supply chain often is the weakest link in the Software Development Life Cycle (SDLC).
Common for these attacks is open source code that is often (blindly) trusted and used indiscriminately by developers and CI/CD systems. This introduces substantial risks to organizations due to vulnerability and license compliance issues.
DevOps will continue to be a competitive advantage in organizations of any size and industry. Innovation and quickly pushing new features to production includes coordination of development, QA, operations and security across the SDLC.
Without the proper tooling, it’s a challenge to manage the number of open source packages that organizations depend on. That open source is often developed by various package maintainers who are unknown to you, which just adds to the complexity.
DevOps have enabled teams to be more autonomous with various tooling for ecosystems. These often focus on transparency and visibility which is important, but only checking for vulnerabilities and code quality in CI/CD pipelines is risky. One of the major problems is that if a vulnerability gets installed on a developer computer or CI/CD system you might already be compromised.
Being able to control the flow and use of dependencies, as well as tracking remediation, is an absolute necessity to secure SDLCs
Most would agree that they would not expose their infrastructure on the internet without blocking ports and controlling traffic using a network firewall. The same thing should apply to development pipelines. Developers and CI/CD should only use open source code that has been approved and is compliant with defined business rules. Any non-compliant code should be isolated and unavailable to the organization.
How can open source dependencies be used for software supply chain attacks?
Today’s modern applications consist of components where typically most of the code is open source. As much as 99% of code bases depend on open source code. Almost all companies practicing DevOps have benefited from a boost in improved velocity and higher quality of releases.
If companies and teams are benefiting from better performance and higher quality, isn’t that enough? Not quite.
Although developers might know what direct dependencies they are using, the challenge comes with transitive dependencies (dependencies of dependencies). A typical application can consist of hundreds of open source dependencies developed by anyone from solo developers to large enterprises. Code quality, security, time to resolution of vulnerabilities will vary.
An application is only as secure as its weakest link in the supply chain. The risk of getting attacked increases with the number of dependencies and the likelihood of a successful attack increases with the number of vulnerabilities.
Besides this, attackers target popular packages because of frequent package downloads and the widespread use. With supply chain attacks, attackers try to get developers and CI/CD systems to include malicious packages into the development pipelines so that they are spread as much as possible. Regardless if you are using npm, Maven, NuGet or any other type of packages you’re exposed to the risk of bad open source code - no ecosystem is excluded.
There are numerous examples where malicious code has been installed that steals passwords, mines crypto currencies or other even worse things.
Vulnerabilities are not the only threats that need to be managed properly. Open source code is protected by open source licenses and breaching licenses can cause both financial and reputational damage.
AppSec and DevOps teams need a way to block unwanted dependencies
Security is all about collaboration and automation. Being dependent on manual processes or individuals does not work in the long run and leads to higher risk of mistakes that might lead to becoming an attack victim.
AppSec and DevOps teams often speak about lacking resources and knowledge to prevent supply chain attacks. These are contributing factors to why we have seen a tremendous increase in the number of attacks.
Another important factor is that developers and systems often install directly from public sources (like Npmjs, Maven Central or Nuget.org) or private registries that lack proper functionality to isolate malicious or vulnerable packages. For example when installing an npm package, the post installation scripts can pretty much do anything unless you are being careful. Unfortunately most people trust what they install.
What is a Dependency Firewall? Next level of supply chain security
A dependency firewall is the first line of defense against threats from malicious or vulnerable open source packages used in organizations. The firewall audits all new dependencies being downloaded to make sure they comply with defined security and license compliance policies.
Instead of having any dependency or version used by anyone in the organization, firewalls limit the universe of available packages. Making sure they have been scanned for known vulnerabilities and only contain open source licenses that are accepted by the organization.
Set the financial damage aside, avoiding having to spend weeks or even months recovering from an attack is the reason why you want to understand how to use the Dependency Firewall capability.
Typical use cases for a Dependency Firewall
Below are a few use cases using Bytesafe Dependency Firewall to secure software supply chains.
Centralize open source dependency security management
Shifting from waterfall to Agile and DevOps has had a huge impact on developing products that are closer to what the customer or end-users want. Making the shift into DevSecOps means that teams need to scale skills like cybersecurity and that takes time. At the same time, security and risk management should never be dependent on specific individuals. Instead the same level of security should be applied on a business level, regardless of skill level.
To overcome different skill levels, companies need to define security on an organizational level (instead of depending on individuals). This is especially important for large enterprises where the number of developers can be in the range hundreds to thousands.
A common security principle is one that separates entitlements for critical functions among different staff members. When it comes to secure dependency management different roles should be used for security related tasks.
Firewall registries let organizations centralize the management of company defined rules to automate the process of deciding what is allowed to be used. Those packages that are not compliant will be quarantined. Only those members with the right access will be able to change and update central security rules.
While it’s getting more and more complex to use the plethora of tools, preferably new security related tooling should “just work” with the tools the developers are used to working with. Automate more, improve security and let resources focus on developing new features.
Add a safety delay before making new package versions available
The latest version is not always the most secure one. The popular JavaScript library ua-parser-js sparked vigorous security activities when three malicious versions were published to the public in October 2021. The hijacked package contained malware and was the result of a maintainer account takeover.
Although it only took 4 hours before all the major, minor and patch versions were deprecated and unpublished from npm, the problem is that users and systems had already installed the packages during this time. Those who had installed the compromised packages were to be considered fully compromised.
The Bytesafe Dependency Firewall lets organizations add a safety delay before new versions from external sources are possible using the Delay Upstreams Policy.
Block dependencies with critical vulnerabilities to protect developers and downstream systems
As software is developed, dependencies are installed from public sources. These dependencies should be considered insecure with potential bugs and vulnerabilities. A dependency firewall allows for defining when dependencies should be blocked and put in quarantine based on severity levels. This way they are securely isolated and made unavailable to the organization.
Block unwanted open source licenses
Trying to keep track of all open source licenses is tedious work, which is often manual and error prone. Therefore it is advisable to automate this process.
Bytesafe allows for automated license compliance. Bytesafe checks all files in packages for Open Source licenses (SPDX) and by defining a license policy organizations can choose what unwanted open source licenses should automatically be isolated and unavailable to the organization.
Bytesafe quarantines packages based on severity levels both for vulnerabilities or open source licenses.
Avoid namespace confusion attacks (dependency confusion attacks)
One of the hot discussion topics is namespace confusion attacks, also referred to as dependency confusion attacks. These attacks consist of attackers publishing packages in public sources with newer versions and the same names as the internal package names.
This tricks developers and CI/CD into installing the external packages with newer versions instead. This can happen in any CI/CD environment unless proper tooling is used.
All your internal packages should always stay internal and should never be replaced by any public upstream source. Regardless of what solution is used to protect organizations from dependency confusion attacks, avoid using solutions that rely on naming conventions or complex configuration.
The Bytesafe dependency firewall automatically flags all published versions to a Bytesafe registry as Internal.
Interested in hearing more?
The need for such a solution is clear. We expect the registry ecosystem to continue growing and the use of private registries to expand with it. Businesses contain sensitive data and require a security layer that can enforce business rules.
Bytesafe is a cloud based dependency firewall that provides secure dependency management across Npm, Maven, and NuGet repositories. The solution provides visibility into all users, groups, and repositories enabling organizations to review and make conscious decisions on the dependencies they are using for a secure supply chain.
How? To get started - read about the Bytesafe Firewall in our Documentation or Contact us for a demo.
Thanks for reading!
