DependencyTrack/dependency-track

Current Behavior The componentUuids path parameter of GET /api/v1/component/project/{projectUuid}/dependencyGraph/{componentUuids} is documented as a "List of UUIDs of the components (separated by |)", and the handler splits it with componentUuids.split("\\|"). However, the parameter is also annotated with @ValidUuid, and ValidUuidValidator calls UUID.fromString() on the whole value. Any value with more than one UUID therefore fails bean validation, and the endpoint returns 400 before the handler runs: [{"message":"Invalid UUID","messageTemplate":"Invalid UUID","path":"getDependencyGraphForComponent.componentUuids","invalidValue":"<uuid1>|<uuid2>"}] The error is the same whether | is sent raw or percent-encoded as %7C. Each UUID on its own returns 200. The annotation was added to this parameter in DependencyTrack/hyades-apiserver#712, which added @ValidUuid to UUID parameters across the REST resources. It is present in every 5.x tag (hyades-apiserver 5.5.0+ and dependency-track 5.0.0 t

Current Behavior Observed on Dependency-Track 5.1.0 (apiserver and frontend, PostgreSQL 18), with the internal analyzer. Chainguard / Wolfi publishes one OSV advisory per package and per architecture. The architecture is carried by the arch qualifier of affected[].package.purl. Dependency-Track ignores this qualifier when matching, so an x86_64 component is reported as affected by the aarch64 advisory as well. Example, both for CVE-2026-8674 (upstream field) on glibc-2.44: Advisory affected[].package.purl (Wolfi ecosystem) Ranges Wolfi status CGA-fjmw-f657-w678 pkg:apk/wolfi/glibc-2.44?arch=x86_64 introduced: 0 pending_upstream_fix CGA-jm93-f4m9-rgvp pkg:apk/wolfi/glibc-2.44?arch=aarch64 introduced: 0, fixed: 2.44-r8 fixed The component in the uploaded BOM (container image built for linux/amd64): pkg:apk/wolfi/[email protected]?arch=x86_64&distro=wolfi Both advisories are reported as findings on this component: {"vulnId":"CGA-fjmw-f657-w678","component":"glibc-2.44","vers

Current Behavior Material for MkDocs is currently in maintenance mode and going to be End of Life in May 7, 2027 Announcement: squidfunk/mkdocs-material#8523 Proposed Behavior The Team behind the original project has announced Zensical as it's successor to overcome the technical limitations of MkDocs and being almost fully compatible with the Material for MkDocs it can be easily migrated over. Checklist I have read and understand the contributing guidelines I have checked the existing issues for whether this enhancement was already requested

Current Behavior For our system we authenticate all connections via oauth2-proxy before they reach the backed. This give us a simple pane of glass when it comes to IT health checks. All authentication for apps that support proxy authentication are done in the same way and we can apply rules to not allow any API traffic without authentication When is comes to application such a dependency track which support the own implementation of OIDC we need to do much more due dilligance to make sure the service complies with our security standards. We have to allow unauthenticated access to the dependency track apis which make our security team nervous. Proposed Behavior Allow Dependency track to support oauth2-proxy so that a user, once authenticate with the gateway, does not have to do any more actions to access the dashboard. Checklist I have read and understand the contributing guidelines I have checked the existing issues for whether this enhancement was already requested

Current Behavior During the work on #7076, it became clear that the VEX ecosystem is not converging on any one standard, but is instead fragmented. Many CLI tools, while offering CycloneDX VEX support, default or recommend OpenVEX. We're missing out on real interop-opportunities by not supporting OpenVEX. An eventual integration of CycloneDX Transparency Exchange API (TEA) will amplify this gap. Proposed Behavior Add the ability to import OpenVEX statements. Export is out of scope for this issue and may be requested separately. Checklist I have read and understand the contributing guidelines I have checked the existing issues for whether this enhancement was already requested