Dependency Management: Protecting Your Code

Managing dependencies isn’t always easy, but it’s critical for protecting your code. In this guide, we’ll explore what dependencies are and how they can be checked for known vulnerabilities, compatibility, licensing requirements, and more. We’ll then learn that dependency checks should be part of a dependency management strategy to keep applications up to date and reduce security risks and technical debt.

This article also provides insights into the challenges of dependency management, as well as a number of best practices and things to consider. It highlights the benefits of regular application updates and how automated dependency management can simplify the process. Lastly, the guide provides strategies and tips for managing dependencies.

What are dependencies in code?

In the past, companies would typically either write their own custom software for business needs or use off-the-shelf software packages. But today, most organizations have software stacks composed of many different third-party or open-source components.

Dependencies in code are the connections among all those different software components. A piece of software is said to be dependent on another piece of software if it invokes it. For example, a company might have a custom point-of-sale solution that uses open source payment processing libraries or receipt-printing libraries. That means the solution is dependent on those open source libraries. 

In short, external code that’s required for a piece of software to operate correctly is a dependency. Dependencies can include libraries, frameworks, modules, APIs, and services. 

Dependency check

The most significant risk for companies is not knowing what they don’t know. That’s where dependency checks come in. 

A dependency check identifies all the components, libraries, or modules that are linked to a specific piece of software to create an inventory and identify out-of-date software components, license issues, compatibility issues, version numbers, and more.

Dependency checking is a key way organizations can reduce security risks and identify known vulnerabilities. Some of the key items being checked include:

• Known vulnerabilities. Dependency checks typically start with an automated scan that checks all the dependencies in a given code set against a database of known vulnerabilities to identify potential issues.
• Outdated software. A dependency scan also checks for outdated code by seeing if new versions of libraries or software components are available.
• Compatibility. If new versions of software components are available, it’s important for a dependency checker to identify whether they are compatible or not, so an organization can manage the risk and the level of effort required to update to a new version.
• License information. Dependency checking can also evaluate the licensing information for any third-party code to avoid possible legal issues and ensure compliance. 

Ideally, the results of a dependency check will generate a detailed report identifying vulnerabilities or issues and suggest recommended actions. Most companies will also want to conduct continuous dependency checks, because new vulnerabilities may be introduced any time software is altered or updated.  

Dependency checks improve application security in several ways. First, vulnerabilities in third-party components can be identified and eliminated before ever making it into the code base, which shrinks the potential threat footprint. Second, eliminating known bugs improves code quality and reliability. And finally, organizations can ensure that all software components comply with licensing requirements.

What is dependency management?

A dependency check allows organizations to identify the connections or dependencies among all the different components in its code base. But that’s just the start of the process. Once an organization knows the initial connections and dependencies, it needs to create an on-going management strategy for them. 

That’s where dependency management comes in. Dependency management is a structured approach to managing all the external software components (including libraries, frameworks, modules, APIs, and services) linked to a specific project or code base. 

Proper dependency management ensures that organizations are using the appropriate versions of software components and ensures on-going consistency and security of the software. 

Essential components of a robust dependency management strategy include: 

• Version control. Identify and manage the specific versions of software components to ensure they’re up to date or using the most recent viable version.
• Package managers. Dependency management is best automated due to both the need to continually rerun dependency checks and the large volume of software components that typically make up today’s solutions. Package managers help by automating the downloading, installing, and updating of dependencies.
• Dependency resolution. Knowing that a component has different versions is just the first step. Knowing which one to use is the next step. Dependency resolution is the process by which a package manager or dependency management process determines which version is best to use based on potential conflicts, compatibility, or specific requirements.
• Transitive dependencies. Software isn’t only dependent on the libraries or code it invokes; it’s also reliant on whatever libraries or code those initial libraries depend on—the transitive dependencies. That’s why it’s essential to manage transitive dependencies to ensure they are compatible and appropriate as well.
• Security management. One big reason to bother with dependencies at all is to manage security and prevent known bugs. Organizations need to regularly monitor and resolve security issues or vulnerabilities in software dependencies and incorporate known patches as appropriate. 

In addition, a dependency management strategy should ensure isolation among the updates for different projects so that updated dependencies on one project don’t cause problems with separate projects. Organizations should also make sure to maintain clear documentation on the dependencies and versions and implement automated testing procedures to ensure compatibility and stability. 

What are the risks of not updating dependencies?

Using third-party components for software development can save organizations considerable money, time, and resources. However, those same components can open the organization to potential risks, especially if they drift out of date. While no one likes to interfere with working software, organizations that let the dependencies in their software code base become out of date are opening themselves up to a variety of non-trivial risks. 

Consider some of the dangers that not updating dependencies can generate:

• Security risks. The most obvious problem with out-of-date dependencies is potential security risks or vulnerabilities. The older a piece of software is, the more likely potential vulnerabilities have been identified or exploited by bad actors. Using such out-of-date components dramatically increases an organization’s security risk profile.
• Compatibility issues. Most software continues to change over time via updates with new features, patches, or bug fixes. The more out-of-date a component is, the greater the risk of compatibility issues. Also, the older the software is, the more risk there is that an update will be problematic or have integration problems when trying to update.
• Malicious updates. Organizations need to remember that not every update is good! Malicious updates are updates that bad actors create to introduce vulnerabilities or bad code that can be exploited. For example, a malicious update may introduce a hidden software back door for data breaches or install malware that provides external actors control over a system.
• Increased application fragility. Organizations that don’t update dependencies risk increasing the fragility of their applications. The longer it has been since updates have been applied, the more difficult they may become, or the more work may be required once they are applied.
• Performance issues. Due to optimization or updates, new components or software may provide better performance characteristics than older software. Organizations that don’t update dependencies will miss out on potential performance updates. 

Decreasing risk in updating dependencies

Application development teams find themselves balancing functional risk—that is, the chance that updating software might break something—with security risk. How do organizations resolve these competing factors and decrease the risks that might come from updating dependencies?

There are two primary ways to decrease both types of risk when updating dependencies: Merge Confidence metrics and blocking malicious software.

Merge confidence from broken dependency releases can help organizations determine how likely a potential update will have a negative impact or “break something.” Merge confidence metrics can take into account statistics such as the frequency of updates with that component, the number of users, the regularity of updates, and how quickly component problems are resolved. Merge confidence can also take into account details from a component’s change log to help understand the specific changes that have occurred. 

Detecting and blocking malicious open-source packages is equally important to prevent the introduction of problematic code when updating dependencies. Putting measures in place or using software tools that can detect and block malicious open source software updates helps prevent potential security breaches that such software might introduce, whether it’s malware, trojan back doors, or other hostile behaviors. 

What are vulnerabilities in dependencies?

Unfortunately, organizations should look for vulnerabilities not only in their own code but also in any dependencies that are called or referenced within that code.

Vulnerabilities in dependencies are security risks or vulnerabilities in third-party libraries, frameworks, or code. Organizations need to be just as diligent in identifying and mitigating vulnerabilities in dependencies as they are in their own code. 

There are several ways that vulnerabilities manifest themselves in dependencies, including:

• Outdated or unmaintained versions. Older versions or unmaintained versions of software components can have known vulnerabilities or risks.
• Malicious packages. Organizations must be careful that third-party components don’t have intentionally harmful code.
• Indirect vulnerabilities. Dependencies can have dependencies, so organizations need to dig deep when analyzing potential vulnerabilities.
• Insecure configurations. Some software packages may come with default configurations that can open an organization to risks unless altered. 

What is technical debt?

What happens when there’s a problem in a software project that’s not resolved? It tends to grow bigger over time. As a result, it can become more challenging to solve because of changes in the environment or lack of skills availability. 

That’s technical debt in a nutshell. Like financial debt that increases over time due to additional interest charges, technical debt is a technical problem that’s not addressed immediately and is left to linger. As a result, it typically grows larger and harder to solve, leading to increased maintenance costs.

There are several causes of technical debt, including quick fixes, lack of expertise, poor design decisions, changing requirements, use of outdated technologies, and even lack of documentation. Moreover, organizations can accrue technical debt intentionally or unintentionally. Intentional technical debt comes from taking shortcuts or making quick fixes to meet a deadline without regard for the future impact. Unintentional technical debt accumulates accidentally due to a lack of expertise, knowledge, or complexities within a software environment. 

Unfortunately, technical debt isn’t just an IT problem, as accumulating technical debt can hurt an organization in a number of ways. increased maintenance costs, decreased productivity, slower development, and higher failure/defect rates are just a few examples. In response, organizations need to recognize the impact that technical debt can have on their development process and business outcomes and plan to minimize it. 

What are challenges in dependency management?

One important way to reduce technical debt is through dependency management, which can shrink security risks and enable more rapid and agile change.

But as helpful as dependency management can be, there are potential challenges that organizations must be aware of, including:

• Conflicting dependencies. Sometimes, more than one software package needs to use the same dependency, but each requires a different version. The versions may not always be compatible, so by solving the dependency for one piece of software, you could risk breaking the compatibility of another.
• Versioning issues. As software evolves over time and new versions are released, it can be difficult for an organization to keep track of the different versions of a component needed for different projects. For example, versioning issues can arise when teams lose track of the most up-to-date versions and continue to use out-of-date versions, or when different projects require different versions of the same component.
• Dependency license issues. Open-source license management issues can also arise as a challenge in dependency management. As components are referenced or updated, software developers need to ensure that the license terms and conditions of the dependency are up to date and work well with the overall project.
• Managing dependencies across multiple environments. Most organizations have more than one software project, so managing dependencies across multiple environments can quickly become a significant challenge. It’s important to recognize that dependencies can behave differently when used in different environments and when they are combined with other components. Like cogs, they have to fit together properly; otherwise, the whole mechanism doesn’t work. Mismanaged dependencies can, therefore, disrupt or disable entire projects.  

What are best practices for dependency management?

Dependency management requires organizations to keep track of many different software components across many projects and versions. It’s a complex task. 

That’s why it’s critical for organizations to establish some best practices for dependency management so they can ensure it is implemented correctly to streamline development, reduce security and performance risks, and ensure software consistency. Good dependency management is critical for ensuring the security, stability, and performance of software. 

Since there is so much pre-written code and third-party software to choose from, a few best practices for dependency management include the following items:

• Compatibility. A good place to start is to find out whether the dependency works on the platform you’re using. If not, discard it.
• Licensing. Verify that a dependency’s licensing terms and conditions are up-to-date and consistent with your project needs.
• Maintenance and versioning. Check to make sure the dependency is updated regularly and properly; otherwise, avoid it.
• Breadth of use. Look for dependencies that are currently in wide usage. 
• Quality. Look at the source code—is it clean and readable? Is the documentation solid? Does the dependency come with its own unit tests?
• Ease of integration. Investigate how easy it is to integrate the dependency into your current workflow and how easy it will be for developers to start using it.
• Size. Smaller, more focused dependencies are better than larger ones since they are less likely to bloat and slow down your code base.
• Community support. Evaluate how active the community support is for a dependency.
• Speed and efficiency. Consider how responsive the solution is and if you can manage dependencies in real time. 

What is semantic versioning?

Managing dependencies effectively requires a solid strategy for managing different software projects and components. 

That’s where semantic versioning comes in. Semantic versioning is an approach for defining and communicating the meaning of software changes within a specific release. It provides a visible way to note the hierarchy of software releases so developers can easily understand how they may relate to underlying code changes.

A typical semantic versioning format comprises three parts: a major version, a minor version, and a patch version. 

The major version is incremented or advanced when there are significant changes within a software project, such as when an API changes or there are changes that are not backward compatible.

The minor version is advanced when new features are added but don’t necessarily impact existing functionality. 

Lastly, the patch version is incremented when bug fixes are made. It’s typically used for minor changes that don’t affect functionality. 

Semantic versioning has several benefits, including consistent communication among developers, enabling automated updates and compatibility checks, providing a clear understanding of the extent of a version change, and facilitating compatibility management by communicating the extent of change. 

Semantic versioning is a simple way to keep track of changes and indicate what kind of change happened and at what point in development. It can also help developers gauge update risk based on whether a change is major, minor, or patch. Most importantly, semantic versioning helps developers avoid dependency hell by making it easier to resolve version conflicts and know what versions are acceptable to use.

Regular application updates and maintenance

Regular updates and maintenance to applications and dependencies give organizations the best chance to avoid security risks. Attackers are always looking for vulnerabilities and ways to exploit them, so if an organization has an older version of a popular component, there’s a good chance the bad actors have found ways to exploit it. Updates can counter these efforts and reduce overall risk by addressing flaws or weaknesses before they cause trouble. 

In addition, keeping dependencies current can provide increased stability and potential performance improvements while reducing technical debt. Updated dependencies may also deliver new features or provide more robust or security applications.

Critical benefits of regularly updating application dependencies include:

• Security improvements
• Bug fixes
• Performance or feature improvements
• Increased compatibility 
• Reduced technical debt
• Improved compliance

One consideration when updating dependencies is reachability. Reachability is the determination of whether all the dependencies and transitive dependencies are identifiable, accessible, available for use, and can be successfully resolved. 

However, any application update, even those made to fix dependency problems or bugs, can introduce new problems. 

Some of the potential risks of updating an application’s dependencies include: 

• Breaking an application
• Introducing new bugs or security risks
• Performance problems
• Introducing dependency conflicts
• Integration issues
• Increased maintenance overhead

While the risk of breaking an application during dependency updates exists, those potential risks can be minimized with the processes and automation in place. Regular scanning for vulnerabilities is necessary to ensure that every dependency used is secure and updated. 

Automating dependency management

Given the number of dependencies and the volume of changes occurring, most organizations cannot effectively manage dependencies without automation. Automating dependency management boosts efficiency while also improving the security and maintainability of software projects.

The first step in automating dependency management is selecting a dependency management tool that typically integrates with your version management system and other components in your software environment. The next steps are configuring your CI/CD pipelines, automating tests and scans to run during dependency updates, and establishing a process for reviewing and merging automated dependency pull updates. 

Automating dependency management instead of manually managing it provides significant benefits, including consistency, security, efficiency, and compliance.

Strategies for managing dependencies

Since managing dependencies can be a complex process, it’s best to have a strategy to ensure consistency and security. Here are three different types of dependency management strategies to consider:

• Centralized management. A centralized approach to dependency management focuses on keeping all the software components in one centralized repository. This would typically include all libraries, components, versions of third-party dependencies, and APIs. The benefit of this approach is having one place to consult and one source of “the truth.” This centralized approach can reduce the risk of dependency conflict or confusion. A consideration, especially for larger companies, is whether this approach will work for situations with vast numbers of dependencies or projects since the large size could lead to performance problems.
• Decentralized management. A second approach is to go in the opposite way and empower teams to manage dependencies by themselves rather than having them all in a single corporate repository. This can theoretically be simpler since each team is managing its own dependencies, which can result in faster performance when finding, identifying, and fixing problems. However, it also reduces the overall visibility and control of the dependencies since there is no centralized resource. It may also lead to different versions of the same third-party libraries across different teams, possibly resulting in conflicting versions and dependency confusion.
• Hybrid approach. A hybrid approach combines centralized and decentralized repositories. To do this, an organization sets up a single centralized repository that keeps shared libraries, third-party dependencies, and APIs together for use by all teams. Teams would then extend this with their repositories for code specific to their needs and not shared by anyone else. The approach will reduce dependency confusion while accelerating the ability to find project-specific code.

Tips for managing dependencies

Understanding which dependencies are vulnerable to security threats and which updates won’t break your code is complex, especially with so many direct and transitive dependencies. To help manage the process, consider starting with the following best practices for dependency management:

Identify trusted sources of dependency information. Identify trusted sources of dependency and version information to avoid including malicious dependencies or introducing risky code into your project.acks.

Prioritize. Organizations should focus their attention on the highest risks, so it’s essential to recognize that some dependencies are more important than others—and those are the ones that should be analyzed first. This may include understanding which potential open source vulnerabilities are being accessed by your code and which aren’t, so you can prioritize the updates.

Automate. Bug fixes and software updates can be time-critical, so it’s essential to put automated processes in place for dependency management in order to quickly and easily update new versions when appropriate.

Create and communicate policies. Policies let development and security teams know how to handle threats in third-party components, how to update them efficiently, and what priority is placed on continuous dependency management.

Have a consistent approach. Dependency management isn’t a one-off project. It should happen continuously so that potential vulnerabilities are eliminated before they become real vulnerabilities.

Automate dependency updates

See Mend Renovate