The Open Web Application Security Project (OWASP) has released a new version of its dependency tracking tool, which can identify known vulnerabilities in third-party software components, measure and enforce policy compliance, respond to identified vulnerabilities, prioritize vulnerability mitigation, triage findings and policy violations, and produce a CycloneDX-based software bill of materials (SBOM).
Better tagging, authentication badges, policy management, and other changes can aid teams on managing third-party dependencies, but the update is not the final word on managing software risk, subject-matter experts stress.
Here are highlights of the changes to the software composition analysis (SCA) tool — plus the limitations of SCA, and what you need to know about managing risk from your software, whether it's open-source and homegrown or commercial off-the-shelf software (COTS).
[ See Special Report: How to Manage Commercial & Third-Party Software Risk ]
New features in the OWASP Dependency-Track tool
In addition to a core update of the software stack behind the dependency tracking tool (from Java 17 to Java 21, from Java EE to Jakarta EE 10, from Jetty 10 to Jetty 12, and from Swagger v2 to OpenAPI v3), here are the changes in version 4.12.0 that matter the most:
- Addition of tag features, such as limiting alerts to projects with specific tags, including or excluding projects from SBOM validation using tags, tagging projects as part of an SBOM request, and adding auto-complete to frontend tag input fields
- A tag management view that makes it possible to see how many and which projects, policies, and alerts are associated with a given tag
- A global policy violation audit view for discovering and filtering policy violations across all projects in a portfolio
- Authorization for badges, which are used to visually represent the security status of components within an SBOM
Tagging offers more granular control
The new tag-related features give users more granular control over their security and compliance protocols by enabling alerts specific to tagged projects and facilitating BOM validation through tagging, said MJ Kaufmann, an author and instructor with O'Reilly Media.
Sean Wright, head of application security at Featurespace, said tagging can be an effective way to manage numerous projects on a platform or tool. He explained that while tagging is not a new thing in the Dependency-Track tool, the new version introduces several useful tag-related features that will make it even more useful.
“Even what appear rather minor changes, such as the tag autocomplete feature, can make for a far better user experience, This ultimately helps with the adoption of the tool. So this is certainly a win in my book.”
—Sean Wright
Wright said he expects tagging functionality within the tool to be something that will be further enhanced in future versions.
Joe Nicastro, field CTO of Legit Security, said the new tagging system should make it easier to organize, search, and control alerts with a granularity that wasn’t there previously, it still heavily relies on a manual tagging process to be effective.
“Oftentimes, security teams aren’t really sure which project an SBOM or open-source software package really belongs to, so this will still require a manual mapping effort by these teams to make effective use of this new capability in [the tool].”
—Joe Nicastro
Manage policies across multiple projects
A new policy-violation view in the Dependency-Track tool is receiving praise. Kaufmann said the feature is excellent for organizations managing security policies across multiple projects because it lets users discover and filter policy violations more effectively.
“It provides a comprehensive overview that could significantly enhance a portfolio’s management and oversight of compliance and security standards.”
—MJ Kaufman
Wright said the policy-violation feature is “a big win” for organizations. “I view it as a very powerful feature of the tool, allowing individual organizations to customize the risk of dependencies and software to meet individual needs of an organization.”
“While we had a global view of all vulnerabilities introduced fairly recently, a similar view for policy violations was missing. This new feature will now empower organizations to be able to adapt the results to meet their needs and to be able to view, as well as manage, this from a holistic perspective.”
—Sean Wright
Nicastro said the policy-violation view feature will be helpful to organizations that have large amounts of technical debt around the security of their open-source software. However, he said it still leaves a lot to be desired, including the ability to prioritize or triage a list of policy violations based on things such as business context, reachability, or what parts of a data or production environment a vulnerability package has access to. “But it’s still a very good step in the right direction, especially considering this is a free open-source tool largely given away by its developers,” he said.
Improved security for badges
The latest version of the Dependency-Track tool also makes badges more secure. In a LinkedIn post, Mark Symons, a software security specialist at Fujitsu and member of the OWASP dependency tracking team, explained that badges were previously not protected by authentication and authorization and so were disabled by default. With this release, unauthenticated access is deprecated.
Kaufmann said she liked the new protect badges because they take an otherwise disabled function and make it useful again. “Badges are an excellent way for teams to share information about their current status without oversharing this sensitive information with those who should not have access," she said.
Wright said badges are useful and can provide a simple snapshot into the health of a component in terms of vulnerabilities and licensing violations. “While the information given by these badges is not earth-shattering from a security perspective, they can disclose information that security teams may not otherwise want to have disclosed, certainly not in a public manner,” he said.
However, Wright does have concerns about some aspects of the authentication. “I do wonder about the authentication scheme allowing the API key to be sent via the URI parameter," he said, "as this would likely be available to those who visit pages with the badges embedded on them, or even in the HTTP header. So I question the actual value that this provides.”
Wright stressed that the risk of these being exposed is relatively low as the information that is disclosed is not that sensitive.
An updated tech stack offers better performance
Under the hood of the Dependency-Track tool, OWASP has improved the platform’s software. Kaufmann said moving off of older software versions was key because the solution aims to detect out-of-date and vulnerable libraries. “This shift helps them use newer, more supported versions that do not carry the same vulnerabilities as legacy versions,” she said.
Wright noted that the updated codebase should improve the platform’s performance, enhance security, and provide support for more modern protocols such as HTTP/3. The new frameworks also support things such as modern microservices architecture and deployment structures. “The move from Swagger to OpenAPI should allow for extended capabilities,” he added.
Among those capabilities are expanded handling of media types, which allows API interactions to be more versatile; robust support for more complex request body objects so developers can better define and document intricate API payloads; easier reuse of components; and support for modern authentication mechanisms, such as OAuth 2.0.
Wright predicted that the new features in the tech stack could be leveraged in future versions of the Dependency-Track tool to enhance its own features and capabilities. “However, other than the move from Swagger v2 to OpenAPI v3, I would imagine that most would not notice much of a difference,” he said.
“The move to OpenAPI is welcomed, as this helps to ensure that the tool remains current with technologies and protocols that other tools can leverage. The move to later technologies also shows that the project is in a healthy state, which is important for those who are concerned about investing time and effort into adopting the tool for their own use. It shows that the tool still has a very bright future ahead of it.”
—Sean Wright
A great start — but just a starting point
Nicastro said that while the OWASP Dependency-Track SCA tool is a great starting point for any organization pursuing software supply chain security (SSCS), it still leaves a lot to be desired when compared to many of the tools currently on the market.
The limitations he cited included these:
- The tool lacks the ability to scan a product artifact other than an SBOM. The tool is 100% reliant on providing an accurate SBOM from the exact area of the software development life cycle that you want to measure risk. SBOMs produced at different stages of the SDLC will produce different results, so there could be a misalignment of risk if the wrong SBOM is used for risk validation
- The tool doesn’t take into consideration any of the new techniques other tools are using to help with prioritization, such as reachability, package hygiene, detection of breaking changes, or any business context or organizational perspective. For organizations with small application development teams, this may not be an issue, but for large organizations triaging hundreds of thousands of issues, the lack of these features makes determining what to fix much more of a manual effort.
- Being open source, the code is highly auditable, and you can see what you’re using before bringing it in. It also means that you can fork and change as you see fit for any of your bespoke needs. However, that means that volunteers will maintain it only when they have time. Users may have to wait for any bug, security concern, or feature request to get incorporated or will have to fix it themselves, if they have the resources.
Limitations or not, Wright urges organizations to take a look at the OWASP Dependency-Track tool. “I've been using it for several years now, and it is a tool that I swear by, especially when you consider that it is freely available."
Go beyond open-source risk and SCA tools
Organizations have come to recognize in recent years that attacks targeting software supply chains are a major threat. But the focus has been on attacks involving open-source software, since commercial software is a black box for many enterprises.
Cybersecurity incidents such as the one that SolarWinds disclosed in December 2020 have become increasingly common — as have vulnerability exploits used against trusted vendors and attacks on organizations handling enterprise data. Attacks on Sisense, JetBrains, Crowdstrike, Okta, and XZ Utils highlight the risk from commercial software, which OWASP's Dependency-Track tool misses.
And it's not just the focus on open source. The limitations of SCA tools are clear. As Forrester noted in its 2023 SCA landscape report, SCA must evolve to be relevant in the SSCS era.
The expected growth and complexity with software development are why the software security market has to prepare not only for what’s already out there but also for what’s to come. SCA covers many of the threats posed by software supply chain attacks today, but not all.
To advance the state of software supply chain security and better mitigate risk, the Enduring Security Framework group highlights the need for binary analysis and reproducible builds to counter the threats that can't be seen by traditional application security tools and SCA.
