DependencyTrack / DependencyTrack/dependency-track
Exportable audit report for policy violations and license compliance decisions
- Dominant language
- Java
- Stars
- 4.2k
- Forks
- 811
- Avg merge
- 9h 4m
- Merged PRs (30d)
- 229
Description
### Current Behavior
Dependency-Track currently allows users to review policy violations from the UI and API. Policy violations can be analyzed using states such as Not Set, Approved, and Rejected, and findings can also be suppressed.
This is useful for operational review, but in enterprise environments, especially for OSPO, legal, risk, and compliance teams, it is often necessary to export evidence of how policy violations were handled.
Currently, there is no dedicated export capability that provides an audit report for policy violations including details such as:
- Project name and version
- Component name and version
- Detected license
- Policy name
- Policy violation type
- Policy violation state
- Analysis decision
- Suppression status
- Comments or review notes
- Reviewer information
- Review date
- Optional audit trail
For organizations using Dependency-Track to support license compliance in CI/CD pipelines, this requires manual review and manual evidence collection outside the platform.
### Proposed Behavior
I would like to propose an enhancement to provide an exportable audit report for policy violations, with an initial focus on license compliance use cases.
The intention of this issue is to validate the feasibility and alignment of this contribution with the Dependency-Track maintainers before starting the implementation. If the proposal is considered useful, I would be willing to take ownership of the development.
A possible MVP could introduce an API endpoint to export policy violations with basic filters.
Possible endpoint:
GET /api/v1/policy/violation/export
Possible query parameters:
- projectUuid
- policyUuid
- type=LICENSE|SECURITY|OPERATIONAL
- state=INFO|WARN|FAIL
- analysis=NOT_SET|APPROVED|REJECTED
- suppressed=true|false
- format=json|csv
- includeAuditTrail=false
Initial output formats could be:
- JSON
- CSV
The first version could focus on the current state of each policy violation. A later iteration could include full audit trail details through an optional parameter such as includeAuditTrail=true.
Example output fields:
```json
{
"projectName": "example-service",
"projectVersion": "1.0.0",
"componentName": "example-component",
"componentVersion": "2.3.4",
"license": "LGPL-3.0-only",
"policyName": "Medium Risk License Policy",
"policyViolationType": "LICENSE",
"policyViolationState": "WARN",
"analysis": "APPROVED",
"suppressed": false,
"lastComment": "Reviewed and approved for this specific usage context.",
"reviewedBy": "user@example.com",
"reviewedAt": "2026-01-01T12:00:00Z"
}
Contributor guide
Research direction
The issue names no implementation files or tests. Start by reviewing the existing policy-violation UI and API behavior described in the issue, then trace how violations, analysis decisions, suppressions, and review metadata are represented. Done requires an agreed MVP scope for the proposed export endpoint, filters, output formats, and audit-trail behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend-api-design, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100