Top 5 Security Considerations for a New Web App - 5. Establishing an Dependency Patching Plan

Welcome to our comprehensive series on the Top 5 Security Considerations for a New Web App. This post wraps up the series, focusing on Establishing a Dependency Patching Plan, and is part of a broader effort to equip developers, IT professionals, and web administrators with essential security knowledge for proactively safeguarding their web applications. Throughout this series, we explore the critical security measures that are fundamental to the development and launch of a secure web application. For a complete overview and the context of this series, we invite you to read the Introduction post. This foundational understanding will enhance your grasp of why each consideration plays a vital role in the lifecycle of a web application in the initial buildout and the days immediately following the launch. Join us as we delve into the best practices, strategies, and real-world applications that underscore the importance of implementing robust security measures from the ground up.

Previous: Logging And Monitoring

5. Establishing a Dependency Patching Plan

The security of web applications is not just about the code you write, but also about the external libraries and frameworks you depend on. Application dependencies and server runtimes form the backbone of modern web applications, offering the functionality and efficiency developers need to deliver complex solutions. However, these dependencies also represent a significant security risk if not properly managed and updated. Establishing a robust dependency patching plan is crucial for maintaining the security integrity of web applications.

Understanding the Importance of Patching

Patching application dependencies and server runtimes is critical because vulnerabilities in these components can be exploited just as easily as vulnerabilities in the application's own code. When security flaws in widely used libraries or frameworks are discovered, they become prime targets for attackers who can exploit these vulnerabilities to compromise web applications that rely on them. The process of regularly updating these dependencies to their latest, secure versions is known as patching.

Developing a Dependency Patching Plan

A comprehensive dependency patching plan involves several key steps:

• Inventory of Dependencies: Begin by cataloging all external dependencies your application uses. This inventory should include details on the version in use and the latest available version of each dependency. Tools like OWASP Dependency-Check can automate the discovery of vulnerabilities in dependencies.
• Regular Vulnerability Scanning: Implement automated tools to regularly scan your dependencies for known vulnerabilities.  Many continuous integration (CI) pipelines can be configured to include vulnerability scanning as part of the build process.
• Prioritization of Patches: Not all vulnerabilities pose the same level of risk to your application. Assess the severity of identified vulnerabilities and prioritize patching based on the level of risk. Critical vulnerabilities that could lead to severe data breaches or system compromise should be addressed immediately.
• Testing Before Deployment: Before applying a patch to a production environment, test the changes in a staging environment. This testing phase is crucial to ensure that the patch does not introduce new issues or break existing functionality.
• Automate Patching Where Possible: Automating the patching process can significantly reduce the time to deploy patches. Tools and services are available that can automatically update dependencies to their latest secure versions within the constraints of compatibility.  For runtimes, you might consider parallelizing certain builds or automated tests on both the current version in production and the next version you are planning to migrate to (e.g. the incoming LTS version).
• Monitoring and Alerts: Stay informed about new vulnerabilities as they are disclosed. Subscribe to security bulletins related to the dependencies you use, and set up alerts for new patches or versions.

Implementing the Plan

With a dependency patching plan in place, the next step is implementation. This involves integrating the plan into your development and deployment workflows. Regular reviews and updates to the plan are necessary to adapt to new threats and changes in the application's dependency landscape.

A Case study - The danger of an incomplete inventory - Equifax (2017)

The Equifax breach is a seminal event in the history of cybersecurity, underscoring the critical importance of timely detection, effective logging, and prompt incident response. This case study provides a detailed timeline that illustrates the sequence of events leading up to the breach, the delayed response, and the aftermath.

The Timeline of the Equifax Breach:

• March 6, 2017: The vulnerability in the Apache Struts framework, CVE-2017-5638, was publicly disclosed, and a patch was made available. This vulnerability allowed remote code execution on the server running the Apache Struts application.
• March 9, 2017: Equifax claimed to have been aware of the vulnerability and took steps to identify and patch any affected systems. Despite these efforts, the vulnerability remained unpatched in certain critical systems.
• Mid-May 2017: Evidence indicates that unauthorized access through the exploited vulnerability began around this time, marking the start of the data breach.
• July 29, 2017: Equifax detected suspicious network traffic associated with the Apache Struts vulnerability on one of its U.S. websites. This discovery prompted an internal investigation, which confirmed the presence of unauthorized access and the exploitation of the vulnerability.
• September 7, 2017: Equifax publicly disclosed the breach, revealing that sensitive information of approximately 147 million consumers was exposed. The delay in detection and the time taken to disclose the breach to the public drew significant criticism.

The Equifax breach timeline reveals critical lapses in the organization's cybersecurity practices, particularly in its failure to patch a known vulnerability promptly and its delayed breach detection. The time elapsed from the public disclosure of the vulnerability to Equifax's initial action highlights a significant gap in the company's security posture, exacerbated by insufficient logging and monitoring practices that failed to detect the breach earlier.

The breach's impact was profound, not only due to the number of individuals affected but also because of the nature of the data exposed, including Social Security numbers, birth dates, addresses, and, in some instances, driver's license numbers. The aftermath of the breach emphasized the need for robust security frameworks, the importance of swift action upon the discovery of vulnerabilities, and the critical role of effective logging and monitoring systems in identifying and mitigating unauthorized access.

The Equifax breach serves as a cautionary tale, illustrating the dire consequences of security complacency and the paramount importance of maintaining vigilant and proactive security practices to protect sensitive data from emerging cyber threats.

In Summary

Keeping your dependencies patched is conceptually simple, but presents a significant challenge in practice.  The core parts are:

• Establish an inventory of dependencies.  With the increased interest in Software Bill-of-Materials (SBOM) in recent years, there is more tooling than ever for extracting and maintaining this type of inventory. This is ideally maintained in a unified way across the organization, rather than ad hoc per application.
• Ensure the inventory is routinely updated. The best solution here is an automated feed from the build pipeline that ensures the information is always up-to-date for what is deployed. However, for many organizations this is not yet practical for their size and maturity level. In these cases, a scheduled task on a regular interval might be a more reasonable option, even if there is a manual element to performing the updates. The exact interval will depend on how regularly the software is changing or being redeployed.
• Determine how to monitor dependencies for disclosed vulnerabilities. For commercial products, there is usually a formal channel such as a mailing list that announces new releases.  Some package managers such as npm have an audit function, which can be used to write automated checks. There are also external dependency-checking analysis tools like OWASP Dependency Check.  Popular hosted code repositories, like GitHub and GitLab, have dependency scanning functionality that you can leverage as well.
• Become familiar with release cadences for key packages and runtimes. For a lot of software packages, there is no fixed cadence. New versions are released when they are ready, and it is decided in response to the development progress. However, some packages and runtimes have a typical release cadence, whether that is formal (e.g. major releases every April and October) or informal (e.g. historically there has been a major release about once a year).  For those you rely on the most, it is worthwhile being familiar with the cadence, as it informs when major releases with potential breaking changes will be ready for testing with your application.
• Get involved. For open-source packages that your organization depends on, consider getting actively involved in the community, whether that is by helping maintain the package or host user-groups.  The knowledge sharing that comes with that type of involvement makes it more likely that your organization will be well-informed about new developments related to the package. New developments could be anything from significant vulnerabilities to new security features to knowing early when it is going to be deprecated or become unmaintained.

Additional Materials

• Dependency Track (https://dependencytrack.org/)
  This open-source OWASP flagship project is a collection of tooling built around building and maintaining an inventory of dependencies and checking them for known vulnerabilities.
• Dependency Scanning in the Code Repository
  • GitHub Dependabot (https://docs.github.com/en/code-security/dependabot)
    Can inform you on a configurable interval about security patches for your project’s dependencies, and can even open a pull request for them.
  • GitLab Dependency Scanning (https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) Configurable scanning tool integrated into GitLab. They also have a container scanning tool.

• OWASP Dep-Scan (https://github.com/owasp-dep-scan/dep-scan)
  OWASP’s next-generation dependency scanning tool.  I have not used this one, but there is a lot of active development on it and it is about 4 years old as of early 2024, so it has had time to mature.
  
  

If you came to this post directly, you should check out the whole series which starts out with an introduction here, and then goes straight into Secure Coding Practices.