Business risks of not securing your code supply chain

Business risks of not securing your code supply chain

Today, open source software (OSS) is everywhere and in most cases developers are asking themselves not if they are going to use open source, but more likely what open source code and how much.

Open source provides a shortcut for developers to build web applications by reusing existing packages sourced from a public package registry. But, few fully understand the ubiquity or full extent of their dependency on open source code.

For example a web application may consist of hundreds or even thousands of code dependencies. And when it comes to the quality of the open source libraries available, there are lack of controls or checks in place for publishing a package.

As a business, lacking visibility or insights into what packages your developers are using can open the door for hackers to inject an attack into the code supply chain.

The recent SolarWinds supply chain attack is perhaps the most well known example, where malicious code was inserted into one of the SolarWinds products and distributed as an update to their customers.

One of the key takeaways from these attacks is that you need access to the right tools to avoid being the victim. So, to keep track of vulnerabilities and to secure a supply chain there must be an awareness of what is in your codebase.

In the following blog I will explain how critical dependency security is to safeguarding the code supply chain.

What is a Code Supply Chain?

As a business your code supply chain is anything that touches or affects your code right through all the development stages until it gets deployed into production.

DevOps Toolchain

A supply chain contains all the external code an application depends on, be it open source or commercial and their source. And like any supply chain it’s critical to ensure that it always delivers what you need in a secure and efficient way.

To assess how secure a supply chain is, it’s important to know:

  • Who wrote the code
  • When it was contributed
  • The history of how it’s been reviewed for security issues
  • If there are any known vulnerabilities
  • Supported versions
  • Code dependencies
  • License and compliance information

In theory using open source implies better security but that is not always the case, which is why you must care about and manage all your external dependencies and their different levels of security.

Stay Updated!
We’ll keep you up to date on supply chain security and send you the latest information.

What is Dependency Security?

Dependency security means being able to manage all known vulnerabilities in third-party libraries, avoiding new threats as well as managing external dependencies in applications.

Most companies don’t really know 100% what open source software they’re using and developers probably aren’t up to speed with the numerous libraries they are fetching packages from.

So, if an application’s dependencies aren’t tracked it could mean missing key information, like deprecation or new vulnerabilities - with serious consequences.

Avoid dependency issues by adopting a proactive approach to security:

  • Knowing and controlling the dependencies you are using
  • Making sure dependencies are secure and trusted
  • That the code is always available
  • Code is up-to-date
  • Package workflows meet the required business and security policies

We’ve worked our way through understanding the code supply chain and dependency security. Next section will give you an insight into why web applications use dependencies and the difference between the different types.

What is a Dependency?

"dependencies": {

"internal-package": "^0.2.2"

"another-internal-package": "~2.3.4"

"external-package": "^5.5.0"

"another-external-package": "~3.6.5"

}

A dependency is typically a piece of code or package sourced from a public package registry such as npmjs and added to an application’s dependencies.

Installing these reusable build-blocks, with all their benefits such as not having to code everything yourself, can also put a project at risk by introducing the third-party software’s vulnerabilities, including security flaws and software bugs. Especially if you are not careful how you configure what versions to include and from what source.

There are two types of software dependencies;

  • Direct dependencies when your application directly uses a piece of code.
  • Transitive dependencies which are dependencies to your application’s direct dependencies (dependency of a dependency)

Managing dependencies will always be an important task for any developer and managing the risks associated is typically the responsibility of a manager or someone in the business. It’s important to understand that software is organic and needs to be managed accordingly to avoid the worst risks and attacks.

Continue reading to learn why you should keep your dependencies up to date, what risks your business is exposed to when using dependencies, different code supply chain attacks and most importantly how secure your code supply chain.

Avoiding Software Decay

In order to avoid decay, software needs to be treated like a fresh commodity. Developers must make sure that code is well maintained and dependencies have the latest releases.

Unchecked software decay can expose an application and its users to:

  • Security vulnerabilities
  • Missing out on the latest enhancements, bug fixes or alerts to code that has been deprecated or reached end-of-life

External developers and Dependency risks

When your application utilizes external dependencies you’ll depend on developers who you can exert no real control over. Without having control, how do you know whether the open source components in your codebase are being maintained?

External dependencies equals risks:

  • No influence over the code or whether it will remain compatible
  • Cannot prevent the code being changed
  • Cannot ensure the adequacy of background checks on developers
  • A lack of control over how developers manage tokens/credentials securely

Attacks on the Code Supply Chain

Instead of trying to exploit existing code vulnerabilities, hackers are focusing on getting their malicious code included in applications as part of the build process.

Package and account takeovers exploit legitimate npm packages by accessing the maintainer token for a package. A new version can be published with a weakness ready to be exploited.

Typosquatting attacks trick developers into installing malicious packages that have similar names to the official packages. Hackers want to get their packages pulled into your supply chain.

Dependency confusion confuses package managers on what package version to pull into their project. The attack comprises of uploading malware to open source repositories and then being distributed downstream automatically into a company’s internal applications.

Securing the code supply chain

Creating a dependency firewall provides a link to the public npm registry. A single point of contact that prevents new packages and versions from automatically trickling down to all other users and applications.

Using Bytesafe Security Policies manages dependencies as per particular business rules, preventing unwanted package versions from being included in registries.

Having the same level of security for all packages brings together different teams to collaborate on dependency security.

What security does Bytesafe add?

Having all your own packaged and external code dependencies in Bytesafe allows for continuous monitoring, scanning and control of what code you are using.

Using Bytesafe allows for:

  • Private registries
  • Visualization of all dependencies
  • Dependency firewall
  • Security scanning
  • License compliance
  • Deterministic results
  • Bringing together your team