Most companies fail at managing software dependencies because they use technology to fix a cultural and process issue. The real problems aren't technical; they're human. Leaders must take responsibility for the "competency" and "accountability" gaps before a major breach forces their hand.
I have something to tell you that most tech consultants won't say to your face. While they're trying to sell you advanced DevSecOps platforms and costly security auditing services, the truth about handling software dependencies in your business is much more complicated and difficult than anything a vendor presentation will show you. After years of studying safe software development methods and seeing many companies deal with the same problems, I've learned that the real problems aren't technical at all. They're human, cultural, and very personal.
To begin, here are the numbers that should keep you up at night. Recent research shows that 95% of vulnerabilities are in transitive dependencies. These are the pieces of software that your software automatically pulls in, and your developers may not even know they're using them. Even worse, 89% of codebases have open-source software that is more than four years old. Take a moment to think about that. Almost nine out of ten software projects in your company are using parts that haven't been updated in almost five years.
But this is where it gets really hard for leaders like us: According to Gartner, 45% of organizations will have had a software supply chain attack by 2025. In 2024, 75% of software supply chains were attacked. But somehow, only one in three businesses thinks they are ready to protect themselves from software supply chain threats. These numbers aren't just numbers. They show that our industry's leaders have failed big time, and we need to take responsibility for that failure before we can fix it.
The first hard truth I learned about is what I call the "competency gap." Just like when I was working in maritime technology and traditional industry professionals had a hard time adjusting to digital change, a lot of your current team members don't have the skills they need to effectively manage modern software dependencies. Each app has six to ten direct dependencies, but when you add in transitive dependencies, the total number of dependencies goes up to 180. 80% of application dependencies don't get updated for more than a year, which makes software more likely to have bugs and vulnerabilities. It's not because your employees are lazy or not good at their jobs. It's because things have gotten too complicated for them to keep up with, and many companies haven't spent the money on the training and tools they need to close this gap.
I've seen great developers who built amazing systems five years ago have a hard time with modern Software Composition Analysis tools, SBOM generation, and automated vulnerability management. The industry taught me that technology changes quickly and that software dependency management is changing faster than most teams can keep up with. Some of your employees will step up to the plate and meet these challenges, but others won't. It's not their fault, but as a leader, it's your job to see this and act on it.
The "accountability gap" is the second uncomfortable truth. Most of the time, when I talk to executives, they don't really know what the risks are in their software supply chain because they've given teams the power to make technical decisions without setting up proper governance frameworks. ISO 27001:2022 Annex A Control 8.25 says that companies must follow certain rules when making secure software products. These rules include automated dependency tracking and vulnerability scanning. Still. Less than 20% of organizations that are making or buying critical infrastructure software required and standardized on SBOMs.
A lot of leaders treat software dependencies like any other purchase, but they are very different. It's easy to check the quality of office furniture or cleaning services and switch vendors when you need to. When you use software dependencies, you often make choices that will affect your organization's security for years to come. If you want to change them later, it can take months of development time and cost hundreds of thousands of dollars to do so.
Most executives don't know how high the stakes are. Companies that are hit by supply chain attacks often lose a lot of money because their systems go down, they lose sales, and they have to pay for fixes. Trust between stakeholders—customers, suppliers, and investors—also suffers, and rebuilding that trust can be hard and may cause long-term damage that goes beyond immediate financial losses.
I learned something that changed the way I deal with this problem: you can't just give your technical teams the job of making sure the software supply chain is safe. The NSA, CISA, and ODNI all said in their advice that good SBOM consumption programs will need money and a lot of automated tools and processes. This isn't a problem that can be fixed by getting better tools. It's a problem with leadership that needs long-term commitment and resources from the organization.
Most companies fail at managing dependencies because they use technology to fix a cultural and process issue. They spend a lot of money on Software Composition Analysis platforms like Snyk, Checkmarx, or Synopsys Black Duck and think that their teams will automatically be safe. But the tools only work as well as the people who use them and the rules that govern how they are used. These tools turn into costly security theater that gives the impression of safety without actually providing it if they aren't properly trained, have clear policies, and get ongoing leadership attention.
I've seen this happen over and over again: executives give big budgets to security tools, but then get upset when breaches happen or when they find out their teams aren't using the tools properly. The tools aren't the problem. The issue is that people think technology can fix a problem that is really a human and organizational one.
Researchers say that "multi-layered approaches combining automated tools with manual oversight processes" are needed for good dependency management. You need to build "regular security testing into your development workflows," which should include static and dynamic code analysis, penetration testing, and vulnerability assessments. "Developer training in secure coding practices"* and "collaboration between development and security teams" are even more important to make sure that security requirements are understood and followed correctly.
But here's something that most executives don't get: in order to use these practices successfully, your company needs to completely change the way it thinks about software development. DevSecOps isn't just about tools; it's a change in culture that needs teams to learn new skills. This means you have to admit that some of the ways you're doing things now aren't working, some of your employees need a lot of training or need to be replaced, and some of the money you've spent on technology hasn't been well spent.
It's true that this realization makes me feel lonely. When I first started to understand the risks in my own organization's software supply chain, I was working alone on problems that most of my coworkers couldn't even understand, let alone help me solve. Many software programs, tools, and dependencies are part of the tech infrastructure of modern businesses. The average company uses 112 SaaS applications, and each one has 150 dependencies, 90% of which are indirect. The level of difficulty is mind-boggling, and it is up to leaders to make sure that proper governance is in place.
I learned to see this loneliness as independence, which is what you need to be a good leader. When you really understand the risks in your organization's software supply chain, you see that most of the people around you don't work at the same level of complexity and responsibility as you do. They aren't to blame, but that's how things are for you.
Don't complain about how hard it is or hope that someone else will figure it out. Taking full responsibility for your organization's software supply chain security and building the skills needed to manage it well is the answer. This means putting money into good training for your teams, putting in place strong governance frameworks that meet standards like PCI DSS and ISO 27001, and most importantly, staying personally involved with these issues instead of handing them off completely.
Organizations need to use layered security strategies that include automated scanning tools, formal governance processes, and the ability to monitor things all the time. But none of these plans will work unless leaders stay committed to them and the culture changes that are needed to support them. You can't hire someone else to be responsible for the security of your organization's software supply chain, even if you can hire someone else to do some of the technical work.
When I first started dealing with these problems, I wish someone had told me this: most of your coworkers at other companies are having the same problems, but no one talks about them. The maritime industry taught me that the first step to finding real solutions is often to admit that you don't have all the answers. The best executives at managing software supply chain risks are the ones who understand how complicated it is, put money into building real skills in their companies, and stay personally involved with the problems instead of hoping they'll go away on their own.
Leaders who can handle this complexity well and build organizations that can handle the changing software security challenges will be in charge in the future. You have a simple choice: you can either take charge of the risks in your software supply chain now, while you still have time to build the right governance and skills, or you can wait until a major breach forces you to face these facts in much more difficult circumstances.
The trip is hard, and it can feel lonely when you realize that not many people around you really get how serious the situation is. But that's why we need you to lead. Companies that do this right will have a big edge over those that keep thinking of software dependencies as someone else's problem. The question is not if you can handle this challenge. The question is if you're willing to take on the responsibility and do the hard work needed to keep your organization safe in the future.
This article is provided for informational purposes only.
I have made efforts to ensure the accuracy of the information, but do not guarantee its completeness or applicability. The grammar and spelling of this text have been reviewed using automated tools like Grammarly; however, some errors or nuances may remain. The views expressed are personal opinions and subject to change, especially given the rapidly developing nature of the software development practices. This content should not be considered professional advice, and readers rely on it at their own risk.
The following numbers, statistics, and insights are derived from the research sources listed below.
