AppSec or Application Security has long been a discipline within software development aimed at finding, fixing and preventing security issues at the application level. AppSec practices typically surface security issues within:
- Proprietary Code – developers may inadvertently introduce security issues through poor coding practices.
- Third-party Code – security vulnerabilities or malware may be introduced either inadvertently or maliciously in third-party libraries like open source software (OSS).
- Functional Exploits – issues may arise when using the application, such as exploitable execution paths.
- Infrastructure – security issues may arise with the tools that support the software development process from developer tooling through the CI/CD system to the deployment environment, such as container or configuration (IaC) issues.
It should be readily apparent that one of these things doesn’t look like the others since three of them are (typically) under direct control of the organization, but the fourth, OSS is not. When you consider that OSS can be >80% of any modern application’s codebase (>500 packages per application, on average), this is a non-trivial part of the work that AppSec teams are tasked with over which they have little to no control.
What is Dependency Security (DepSec)?
DepSec, or Dependency Security recognizes the need to treat third-party code differently from first-party code. While third-party code can include commercial software, in practice, the majority is open source libraries (i.e., dependencies) created by millions of authors and contributors with whom most organizations have no relationship. As a result, issues of trust arise, especially given the exponential growth in open source software supply chain attacks over the past few years.
The need to “trust but verify” is paramount, but verifying open source dependencies raises a number of issues due to:
- Breadth – most organizations work with more than one open source language, and import their code from more than one public repository. Because there are no industry-wide standards for open source in place today, each language and repository must be treated uniquely.
- Depth – There is a large set of best practice security and integrity controls you could implement in order to scrutinize the open source components you import. How far you go down this rabbit hole is largely dependent on your appetite for risk, but also your time and resources, as well.
- Change – no set of open source dependencies is ever set in stone. Open source authors change, and the packages they produce are constantly updated, become vulnerable, and get patched. Languages go EOL, repositories move, etc. Keeping up with it all will, once again, demand time and resources.
It’s this level of complexity that makes DepSec unique compared to AppSec, and it has unique ramifications, as well.
What Is The Need For DepSec?
In practice, most organizations already pay special attention to their open source dependencies. According to JFrog’s Software Supply Chain State of the Union report:
- 47% of organizations use between 4 and 9 AppSec solutions
- 33% of organizations use 10 or more AppSec solutions
While they may be labeled as AppSec solutions, the majority of these tools are aimed at identifying or helping to resolve open source dependency issues. On top of this, security-conscious organizations have also instituted multiple processes, and created teams/ individuals with specialized knowledge pertaining to certain open source ecosystems or security disciplines.
Despite all these tools, processes, teams and solutions, as well as the fact that security budgets keep growing, security outcomes are arguably worse than ever, what with:
- 2.1B dependencies downloaded in 2022 and 2023 had known vulnerabilities despite the fact that a fixed version was available.
- 81% of developers admit to shipping applications with known vulnerabilities.
- 91% of organizations experienced a software supply chain attack in 2023.
In other words, the software industry continues to spend more and more on security only to end up achieving worse outcomes. Clearly, a change is necessary in the way the software industry treats open source in general, and open source vulnerabilities in particular.
DepSec is a proposed methodology for standardizing the way organizations work with open source software in order to reduce costs and improve outcomes.
How Does DepSec Differ From AppSec?
AppSec is the umbrella term for a wide range of application security practices, whereas DepSec focuses only on securing the third-party components of an application. By splitting out DepSec from AppSec, organizations can focus on the weakest link in their software supply chain (i.e., OSS) when attempting to secure their application.
For example, typical AppSec guidelines around the code repository include enforcing such best practices as:
- All code is tracked in a version control system.
- All code has at least two reviewers prior to being checked in.
- The URL/ immutable reference to a library has been verified (e.g., to prevent dependency confusion).
- Revision history is verified (e.g., at least timestamp and author are checked).
- A complete history of all revisions is maintained.
And so on, all of which can be infinitely more difficult (though not impossible) to verify when it comes to open source dependencies. While NASA may be able to afford to hire KPMG to verify the thousands of open source dependencies they rely on, they’re not typical of most organizations. As a result, most software vendors often skip this requirement, which can have negative consequences to say the least.
Consider another example: AppSec verification of all built software artifacts. First-party code can be verified as source code (e.g., using a static analysis scanner), throughout the build process, as well as the resulting artifact, but open source dependencies are typically imported prebuilt. This requires a separate process typically involving a binary scanner and extensive investigation of the alerts generated, which can be extremely time and resource intensive especially at the start of a project or whenever dependencies change. This tedious, repetitive process is a significant contributor to cybersecurity burnout, which can lead to security lapses.
And open source dependency security is a fast changing landscape compared to the way we’ve been dealing with proprietary code for decades. Emerging standards and best practices include:
- Software Bill Of Materials (SBOMs)
- Attestations
- Known Exploited Vulnerabilities (KEVs), as opposed to the more general category of software vulnerabilities.
And so on. As a result, there’s a growing need for more open source security specialists rather than AppSec generalists, the better to focus on the true causes underlying the current crisis in software security that has forced the US government to introduce new SEC rules around cybersecurity, as well as to begin suing companies and their executive officers for their lax security practices.
Conclusions: Dependency Security as a First Class Citizen
Dependency security should be of paramount importance to all organizations that develop software. But software vendors sell software, not dependencies. Their core focus is on their final product rather than the commoditized components from which it is built.
Unfortunately, this means that only the largest enterprises can afford to spend the time and resources to create and manage their open source software supply chain in a robust and sustainable manner. Everyone else is stuck repurposing AppSec generalists as software supply chain specialists with the predictable consequences we see today.
Splitting out DepSec as a separate practice from AppSec will go a long way to validating the fact that managing third-party code requires not only a different set of tools and best practices, but an entirely different mindset in order for modern software vendors – and their customers – to remain secure as the digital economy continues to grow.
