3 June, 2025
Dependency management has become one of the most critical aspects of modern software development. Third-party dependencies now make up the majority of most codebases. What once felt like the holy grail of software reuse in the early 2000s is now the default. That shift has fuelled faster development, but it also introduced a massive security problem. According to Verizon’s Data Breach Investigation Report from 2024 the number of breaches caused by third parties has increased 68% from 2023. That is surprising as we have tools to systematically scan applications for dependencies and flag known vulnerabilities. Software Composition Analysis (SCA) tools have become a commodity. Frankly, my team could build a basic SCA tool in a week. The real challenge lies elsewhere. You need the right people, mature processes and clear ownership. And you need tools that fit your workflow, not tools that force you to create one.
SOOS stands out because it focuses on exactly that. It helps teams manage security vulnerabilities within their own process. On top of that, it offers powerful features I haven’t seen anywhere else.
In this blog, I’ll zoom in on what effective software dependency management looks like in a large organization. If you can pull it off at scale, smaller setups become easy. I’ll also show you why SOOS is a key enabler in making that possible and how it perfectly aligns with the best practices outlined by OWASP SAMM.
Common mistakes in third-party dependency management process
Before we look at what good dependency management looks like, let’s first unpack some of the most common mistakes that explain why the current state of practice is often so weak in many teams.
Install a tool and call it a day
You’ve just realized your projects rely heavily on third-party dependencies. Some of them might contain known vulnerabilities, so simple to exploit that even a curious ten-year-old with copy-paste skills could cause damage. Naturally, you start looking for solutions. There are dozens of tools out there. Maybe you haven’t picked one yet, but you’re relying on GitHub’s built-in capabilities. Great start. At least now you know what dependencies you’re using and which ones have known vulnerabilities. For now, we will ignore the fact that not all scanners are perfect and might actually miss the full dependency tree.
That gets you halfway to Level 1 in OWASP SAMM’s Software Dependencies stream. But here’s the catch: SAMM doesn’t reward awareness alone. You also have to fix the issues. Yet this is where many teams stop. They install a tool, check the dashboard, and assume the job is done, without ever fixing the findings.
Fix critical, high and medium before move to production
You’ve decided to ask all teams to fix the findings. Perhaps not all of them, but at least the critical, high, and medium ones. For the sake of simplicity, let’s forget that these severity labels do not reflect on real risk.
At first, things seem manageable. Some issues can be fixed by simply upgrading to a newer version. But soon enough, a pattern emerges. One upgrade pulls in another. Then another. You’re stuck in a snowball effect. Each upgrade brings a risk of breaking functionality, even when marked as backwards compatible. Some updates aren’t backwards compatible at all. Now you’re deep in regression testing, chasing bugs, and resolving version conflicts. Releases get delayed. Teams lose motivation. And worst of all, the effort barely improves your long-term security posture.
The other side of this coin is the opposite problem. Your process states that your software system is not allowed to move to production if any critical, high or medium vulnerabilities are found in your third party packages. But what if a high vulnerability is found in a component that is only used in the highly trusted administrative module of your application? At the same time you have actual high-priority bugs that need to move to production.
Give developers freedom to select third-party components
Your teams seem to fix any tool reports pretty fast without any issues. They work in a modern tech stack with little to no technical debt. So developers are free to pull in any dependency they like. No restrictions. Why worry? You’ve got a solid SCA tool in place to catch anything risky.
There are (at least) three issues with this approach. First of all, developers will always bring in far more third party dependencies than necessary. Moreover, two developers might pull in two different packages for similar features. Finally, each dependency typically brings other dependencies you don’t really pay attention to, until it’s too late.
All of these issues are guaranteed to cause you a lot of headaches once your new, shiny and debt free tech stack starts to age. There are also no guarantees dependencies won’t become abandoned like any code your own team might write. Dependency sprawl is just another form of technical debt.
Third party dependency management best practices
The secret to application security is not really a secret. It comes down to people, processes, and tools—in that order. You need people who understand their roles and responsibilities. You need low-friction processes that enforce meaningful gates. And you need tools to support and streamline those processes. That’s why the right starting point for managing third-party dependencies is always the process. The exact process depends on your organization’s size, tech stack, and risk appetite. Still, there are key elements every mature approach must include.
Note that this section might seem written backwards. You would typically start with scanning dependencies. Then you might create an “approved list” of dependencies (I have yet to encounter a team that does that). Finally, you might start thinking of a formal dependency approval process. That makes no sense. You can’t curate a good list without having clear criteria. So most teams end up with an implicit policy of “approve anything”, which is worse than having no policy at all.
Define a formal dependency approval process first
Any code deployed to production should pass through code review, period. Most teams I’ve worked with have a code review process. Some even have mandatory two or even three reviewers depending on code criticality. However the review process should be structured, ideally with a checklist of what is the definition of good code. One of the items on that checklist should be dependency review.
Dependency Due Diligence: What to Check Before You Approve
When reviewing dependencies, start with a simple question: do we really need the dependency? This might seem obvious, but I have seen too many times developers pulling in a dependency they end up not needing. Then when the code is committed, the dependency stays in the codebase forever. Or even worse, two developers using different libraries to do the exact same thing.
Assuming the dependency is absolutely necessary, you want to make sure the dependency is evaluated qualitatively. To do that you should define a list of criteria that each dependency should meet before adding it to your codebase. Here are several criteria you could consider:
- License type: This might not be a technical issue, but it is a legal one. Some licenses might require you to open-source your whole product. That is a risk your business team is unlikely to tolerate. Based on my experience, some organizations are more concerned about license risks than security vulnerabilities. It’s not uncommon to see a rigorous license review process in place while a formal dependency approval workflow is still missing.
- Ongoing maintenance: You want packages that are actively maintained. In case a vulnerability seeps in, you would want the community to fix them as soon as possible. Look for recent releases, frequent updates, and signs of community use. Stars, downloads, contributors.
- Popularity. I don’t want to claim that widely used packages are typically more secure. They are most likely better tested, but they are also more likely to be attacked. However, very obscure and unpopular packages are more risky in my opinion.
Once you have picked the list of criteria you want your review process to stay as objective as possible. So coming up with an exact match of what is allowed is perhaps a good idea. For instance, you might state that any dependency that is actually required that has more than 100,000 installs, 25 maintainers, at least 4 releases per year should be accepted during a review.
How to handle edge cases in dependency management
However you will also need room for exceptions. Not every dependency will meet your criteria, and that doesn’t always mean it’s a bad choice. Some libraries are rarely updated, because they are extremely stable and there is rarely anything to update. Take, for example, a small utility that calculates Pi to 20 decimal places. It’s unlikely to ever change. It doesn’t need ongoing maintenance. And it probably poses little risk. Hence, your process should include three parts.
- A clear list of accept criteria.
- A clear list of reject criteria.
- An exception flow for edge cases that need extra scrutiny.
Dependency governance made easy with SOOS
One of the best things about SOOS is its focus on governance. Unlike many tools that start with scanning, SOOS begins with structure. You define how your organization handles third-party dependencies before any code gets scanned. This governance-first approach ensures your approval process stays consistent, repeatable, and aligned with your risk tolerance.
SOOS lets you:
- Control licenses by specifying which types are allowed or explicitly blocked
- Set approval rules based on install count, release frequency, contributor activity, known defects, and ratings
- Handle exceptions through a built-in workflow that keeps edge cases tracked and transparent
With SOOS, you stay in control. You define friction-free processes and introduce the right gates without letting the tool dictate how you work.
Creating and maintaining an approved dependency list
Maintaining a curated list of “known good” dependencies seems obvious. If you already trust certain packages, your developers shouldn’t have to go through the full approval process every time. A pre-approved list saves time and reduces friction. But let’s not forget the order of things. You can’t build a meaningful list until you define your dependency approval process. This stream often runs backwards. Teams scan first, list later, and process never. That’s the real problem. Once you’ve defined your criteria and approval flow, you can curate a list that reflects those rules. In theory, you’d start a project with a clean list and only add new dependencies when needed. In reality, most teams already have a running project and a messy list of packages.
Here is a suggested approach to get there:
- Inventory all current dependencies.
- Evaluate each one using your approval criteria. If it meets the bar, add it to your known-good list. If it’s no longer used, you drop it. If it fails but you need it, mark it as an exception.
- Decide how to manage version control. For approved packages, allow any version that passes your criteria and has no known vulnerabilities. For exceptions, lock them to specific versions to reduce risk.
This approach helps you clean up your dependency graph and build a trusted baseline. In some of our own products, the cleanup revealed dozens of unused or redundant packages. You’ll be surprised what falls away once you apply a clear process.
Enforcing dependency standards with SOOS
SOOS stands out when it comes to enforcing third-party dependency standards across your projects. It supports both disallow list and allow list concepts, giving you the flexibility to choose the approach that best fits your governance strategy.
Disallow list enforcement
SOOS allows you to create a “known bad” list. This lets you block high-risk, deprecated, or unsupported dependencies before they reach production. For teams just starting out, this is an easy way to bootstrap your third-party dependency policy with minimal effort and immediate results.
Allow list enforcement
A more robust and proactive model is built around an allow list. Instead of flagging what is not allowed, an allow list defines exactly what is approved. Everything else is automatically rejected. This approach leaves less room for mistakes and ensures that nothing slips through unnoticed. It also reinforces the dependency review process by making approval a requirement. When a developer introduces a new package, the pipeline will fail unless the dependency is explicitly approved.
This capability aligns directly with OWASP SAMM’s expectations at maturity level 2, where organizations are expected to have formalized and enforced approval workflows for third-party components.
Dependency scanning with SOOS
Once your governance is in place, scanning becomes the easiest part. SOOS allows you to quickly scan your applications, identify all third-party dependencies, and detect known vulnerabilities. The results follow your predefined policies, so the output is not just noise. You get clarity on what matters and why. Each scan generates a complete Software Bill of Materials that includes both direct and transitive dependencies, giving you full visibility into your software supply chain. SOOS lets you export the SBOM in standard formats such as CycloneDX, making it easy to share with stakeholders, integrate with other tools, or meet compliance needs. Because scanning in SOOS is tied directly to governance, it becomes a meaningful part of your security program rather than just another step in the pipeline.
Scaling dependency governance across the organization
The challenge of scaling process in large organizations
Up to this point, we’ve covered what good dependency management looks like. That’s the easy part. The real challenge begins when you try to roll it out across a large organization. You’re no longer dealing with a single team or tech stack. You’re navigating hundreds of teams, multiple languages, and overlapping priorities. Things are rarely clean or consistent. Welcome to real life.
From a SAMM perspective, the ideal model is straightforward. The corporate security or engineering function defines the baseline process, and teams are free to refine it, ideally by making it stricter. But in practice, this almost never happens that way. In most organizations, process adoption tends to happen bottom-up, while only a few key policies are pushed top-down.
What should be defined at the corporate level
The most obvious top-down control is licensing. This is usually non-negotiable and owned by legal or compliance teams. The business must ensure that no developer accidentally pulls in a package that forces the company to open source its entire platform. Corporate policy on acceptable licenses is essential, and enforcement needs to be universal.
Another policy often defined centrally is vulnerability remediation. Organizations frequently mandate that all teams fix critical and high-severity vulnerabilities within specific timeframes. For example, critical issues must be resolved within 10 days, and high ones within 30. This creates alignment across the board and supports risk tracking at the executive level.
What should be owned at the team level
Other aspects of the process—such as dependency approval workflows and known-good lists—should be defined locally. A web team working in .NET, a mobile team building with React Native, and an embedded team coding in C++ will all have different needs. Forcing them into a single template is inefficient and often counterproductive.
Instead, corporate should set a maturity baseline and let teams define their own way of meeting or exceeding it. Teams should have full freedom to tailor their review process, define quality criteria, and curate their own known-good list based on how they work and what they build. This flexibility is critical for adoption and long-term success.
How SOOS enables dependency governance scaling
This is where SOOS truly shines. The platform makes it easy to scale dependency governance across complex organizations. You can define sub-organizations to reflect your business structure, such as business units, departments, or product teams. Governance policies can be configured globally or locally.
Corporate can set mandatory license rules and vulnerability SLAs that apply across the board. At the same time, individual teams can create their own approval processes, set thresholds for dependency quality, manage exception flows, and define known-bad packages, all within their own space.
SOOS gives you both control and flexibility. You roll out policy from the top while empowering teams to own their process. This reflects the reality of SAMM in large-scale environments. It’s structured without being rigid, and governed without becoming bureaucratic.
Conclusion
Breaches caused by third-party vulnerabilities are growing at an alarming rate. The 2024 Verizon DBIR makes that painfully clear. This rise is especially concerning given that software composition analysis tools are now a commodity. The root cause, in our view, is twofold: a lack of structured process and a tendency for tools to focus only on vulnerability findings instead of enabling proper governance.
As we have outlined in this blog, solving this problem is straightforward. Start by establishing a formal approval process for third-party dependencies. Apply that process consistently across all applications and remove anything that no longer belongs. In parallel, build a known good list based on your criteria and make it part of your development workflow. Most importantly, make the tools serve your process, not the other way around. SOOS enables exactly this by offering the flexibility to define governance centrally or locally, and the building blocks you need to scale good practices across your organization. This is how you shift from reactive scanning to real control and achieve meaningful security improvement.
