Open source dependency security (DepSec) is the key to securing the software supply chain and creating applications that are secure by design, especially given the fact that open source dependencies comprise ~80% of any modern application’s codebase. DepSec recognizes the need to treat third-party code differently from first-party code. However, that doesn’t mean doing what most organizations currently do, namely treat DepSec as a second class citizen within the Application Security (AppSec) process.
Rather, outsourcing DepSec to a trusted partner can close the gap in securing your open source supply chain without overburdening your AppSec team.
Despite the importance of open source dependencies in the creation of software, DepSec is given far less time and resources than required because most SMBs simply can’t afford it. Instead, SMBs devote their security teams’ time and resources to the more general AppSec practice.
To be clear, focusing on AppSec is not a bad thing. Any organization serious about security already has their work cut out for themselves building AppSec practices into the development process in order to ensure that the final product is secure by design, rather than tacking it on at the end of the project, as usual.
But this focus often means that DepSec is treated as a variable within the AppSec function. Consider:
- Policy – good AppSec starts with good policy that defines the difference between what the organization considers secure code and what it doesn’t.
- One aspect of policy is determining what makes open source code fit for use, which can be as simple as checking to see whether it’s signed by a trusted vendor, or as complex as checking multiple variables from author to vulnerability status to licensing to maintainability, and so on.
- One aspect of policy is determining what makes open source code fit for use, which can be as simple as checking to see whether it’s signed by a trusted vendor, or as complex as checking multiple variables from author to vulnerability status to licensing to maintainability, and so on.
- IDE Plugins – code security begins with developers. IDE plugins that provide code linting, Infrastructure as Code (IaC) configuration checking, secrets detection, and so on, can all help developers write more secure code.
- Plugins also exist specifically for open source dependencies in order to identify (for example) vulnerability and license issues.
- Plugins also exist specifically for open source dependencies in order to identify (for example) vulnerability and license issues.
- Repositories – after code is checked into a repository may be the best time to run Static Application Security Testing (SAST) out of band of the CI/CD pipeline since the process can be time-intensive.
- Artifact repositories also commonly provide tools that can identify open source dependency vulnerabilities, licensing issues, general package health, and more.
- Artifact repositories also commonly provide tools that can identify open source dependency vulnerabilities, licensing issues, general package health, and more.
- CI/CD – the build pipeline is where security checks can be applied in depth, preferably running in parallel so as not to slow things down. Typical routines include penetration testing, security unit tests, IaC configuration checks, and Dynamic Application Security Testing (DAST) of the final built product.
- Similarly, open source dependency security testing may be as lightweight as just running an SCA tool or as comprehensive as checking against Provenance Attestations (for example, to ensure dependencies meet sourcing requirements) and SBOMs (for example, to ensure extra dependencies haven’t been injected).
The point is that AppSec is complex enough when applied to just first-party code (consider all the alerts, notifications, and alarms that get generated on your own code and need to be investigated, for example), often relegating DepSec to a secondary concern. But given the growing threat posed by open source dependencies, this can be a highly risky strategy. For example:
- Software Supply Chain Attacks – software supply chain incidents increased 633% YoY resulting in $46B in damages in 2023.
- Open Source Exploits – the number of reported vulnerabilities has exploded since 2016, but so have malware incidents including ransomware attacks where payouts have hit an all time high of $1.1B.
In addition, malicious packages with names similar to popular packages are regularly removed from public repositories on a daily basis, but not before being downloaded hundreds or even thousands of times. The days of taking open source security for granted are over, but AppSec has yet to evolve to where it’s treated as a first class citizen.
How to Make DepSec a First Class Citizen
The problem lies in the fact that every software vendor is in the business of software supply chain management, but very few can afford to devote the time and resources necessary to be successful at it. This shouldn’t be a surprise, since software vendors are in the business of selling their product, not the components that go into it.
But it means that the pressure on AppSec teams will only grow. For example, the Application Security Posture Management (ASPM) 2024 report found 77% of US-based CISOs recognize that software supply chain security is a blind spot for AppSec teams who have more than enough on their plate already.
The problem is made worse by the fact that most organizations have a tech stack that typically includes two or more open source languages, each of which have different guidelines when it comes to building, packaging, and versioning code for their ecosystem. As a result, it’s not possible to create a “one size fits all” solution for all third-party code without cutting corners, exposing organizations to significant risk.
This is why Independent Software Vendors (ISVs) outsource a significant portion of their software supply chain to a third-party vendor whose business is dedicated to securing third-party code. Unfortunately, most third parties provide only point solutions (SCA tools, repositories, build tools, and so on), creating significant integration and management work for their customers.
By way of contrast, ActiveState provides a comprehensive, end-to-end open source management platform that can provide you with visibility into your existing open source dependencies (no matter whether they’re deployed), and observability over time so you can identify and track changes, including when vulnerabilities are found and remediated. Uniquely, ActiveState will automatically rebuild your open source dependencies from vetted source code using our hardened build system, enabling you to not only remediate vulnerabilities more quickly, but also improve the security and integrity of your open source dependencies at the same time.
In this way, ActiveState lets you scale and secure your use of open source far more effectively and affordably than doing it yourself.
Conclusions – Outsourcing Dependency Security
The days of taking the security of open source dependencies for granted (other than vulnerabilities) is over. But most organizations are still focused on resolving vulnerabilities and investigating alerts generated by scanners rather than addressing the kinds of issues that can reduce the risk of the open source supply chain, such as:
- Generating and validating Software Attestations and SBOMs within the SDLC.
- Implementing a hardened, tamper-proof build system capable of creating secure, reproducible dependency builds.
- Ensuring open source dependencies are free of malware/ransomware BEFORE they’re imported into the organization rather than hoping that scanners can detect and remove them before they do harm.
Open source management platforms, like ActiveState’s, give companies the end-to-end capabilities to make DepSec a first-class citizen, without the overhead and hassle.
Next Steps
Compare the cost benefits of outsourcing your software supply chain versus managing it yourself: The Business Case For An Outsourced Software Supply Chain
