Understanding the potential security vulnerabilities introduced by the open source packages in a codebase is essential. The teams need visibility into affected components, severity scores, and available fixes. But anyone who has worked through a real software audit knows that the scan result is only the beginning of the conversation.
In reviewing automated scan results in the field, we often see the same pattern: A report flags a long list of vulnerabilities, many with alarming severity ratings, but the actual remediation priorities are not always obvious. Some “critical” findings may be difficult or unrealistic to exploit in the production environment, and some “high-severity” findings present more immediate risk because they sit in exposed, actively used code paths. And sometimes a patch exists on paper, but the dependency chain makes remediation far more complicated than it appears.
That gap between what the tool reports and what the business needs to act on is where the expert human input of a security audit becomes especially valuable.
Severity is not the same as priority
A CVSS score is useful, but it is not a complete risk model. It describes general severity, not necessarily the practical likelihood of exploitation in a specific application, deployment model, or business context.
When evaluating software, this distinction matters. A vulnerability may be rated critical because of its theoretical impact, but actual exploitation may require uncommon configurations, privileged access, or a very specific chain of conditions. Meanwhile, a lower-scored vulnerability in a public-facing app or commonly executed code may demand faster attention.
Another important consideration is whether the vulnerability appears in CISA’s Known Exploited Vulnerabilities (KEV) catalog. KEV-listed vulnerabilities have documented evidence of active exploitation in the wild, making them a strong indicator of real-world attacker interest. As a result, KEV status often deserves elevated remediation priority regardless of CVSS score alone. Putting the severity scores in context can inform the remediation plan significantly.
Transitive dependencies can turn simple fixes into complex decisions
Another common challenge in the field is a vulnerable component that is not directly called by the application. Vulnerabilities may be in a transitive dependency that arrives through another library, which itself comes in through another framework that could be outdated or no longer actively maintained.
On the surface, there may be a simple answer: Upgrade to a patched version. In practice, the customer may need to update several layers of dependencies, test compatibility, and determine whether an older framework can safely support the change.
There is an argument that vulnerabilities introduced through transitive dependencies are not directly reachable from the application itself, which can reduce the practical likelihood of exploitation. Maybe. However, remediation policies vary by organization. Some companies believe it’s prudent to address vulnerabilities in transitive dependencies even when the affected code path is not clearly reachable, lest a future change in functionality expose it.
So “patch available” does not always mean “fix available,” and “transitive” does not mean “don’t worry about it.” For software buyers, investors, and engineering leaders, understanding the dependency path is just as important as understanding the vulnerability itself. A deeply nested issue may reveal broader maintainability concerns, especially if the components pulling it in have not been updated in years.
Legacy components are becoming a bigger security concern
Stable code can be reassuring, but old code is not automatically low risk. Components that have not changed in years may still appear in shipped products, container images, or customer deployments. But they may have been written before today’s security expectations, development practices, or threat models were common.
The rise of AI-assisted vulnerability research adds another dimension. Attackers and researchers can analyze older code faster than before, looking for insecure patterns that may not yet appear in public vulnerability databases. Just because hackers haven’t found the exploit doesn’t mean that AI-equipped bad actors won’t. And for any fix that involves replacement, the older the original version, the harder the upgrade.
For customers, the key questions are: “Where is this old component is used, how critical is it, and how difficult it would be to replace if needed?”
That inventory and upgradeability picture is often critical in due diligence.
Reachability helps separate noise from today’s attack surface
Not every vulnerable function is actually used. If a vulnerable method exists in a library but the application never calls it, the immediate risk may be lower. But reachability is not static. Code paths change. Features are added. Refactoring can bring previously unused functionality into production.
That is why reachability should inform prioritization, not replace remediation planning. It can help teams distinguish between theoretical exposure and practical attack surface, but it also needs to be documented and revisited.
In an audit context, this nuance is important. A finding may be less urgent if the vulnerable code is not reachable today, but it still belongs in the risk conversation if the component remains in the product and could become reachable later.
Conclusion: The real lesson from the field
Vulnerability management is most effective when it goes beyond simply sorting findings by severity score and starts focusing on the risks that actually matter to the business. While CVEs and CVSS scores provide an important foundation, they rarely tell the full story. The real challenge is understanding how a vulnerability relates to the software being developed, shipped, and supported—and distinguishing between issues that are theoretically present and those that represent meaningful risk to the product.
For Black Duck Audit customers, that additional context is often what transforms a lengthy list of findings into a practical view of risk. Understanding whether a vulnerable component is present in shipped artifacts, whether it is a direct or transitive dependency, whether vulnerable functionality is reachable or exploitable, and how much effort remediation may require can significantly influence prioritization decisions. Even components with no currently reported vulnerabilities may warrant attention if they are outdated, poorly maintained, or likely to create future security and maintainability challenges.
Additional intelligence sources can help sharpen those decisions even further. Information such as CISA’s Known Exploited Vulnerabilities, evidence of active exploitation, and Black Duck Security Advisories often provide valuable context beyond the CVE record itself. Automated tools are effective at identifying signals, but organizations ultimately need more than signals alone. They need interpretation, prioritization, and expert analysis that connects technical findings to real-world software risk. When vulnerability data, engineering context, and threat intelligence are considered together, organizations can make more-informed decisions about which issues require immediate attention, which should be addressed through planned remediation efforts, and which represent longer-term areas of concern.
