License Change Audit

[msymons]

License Management in Dependency-Track should implement an audit trail (similiar to that implemented for vulnerability management) as an enhancement.

A use-case for this will be for when support for multiple licenses is introduced (#170). The audit trail should record what license was chosen (with optional comment), and who performed the update (and when).

[stevespringett]

Do you have examples (screenshots perhaps) of what other products do in this area? License auditing is a bit out of my area of expertise.

[msymons]

I have used WhiteSource and Black Duck Hub, and Nexus IQ - but none recently.

For Nexus IQ, there is public documentation:

• Component License Information
• License Threat Groups

I'll try and put together some more thoughts...

[hehaveri]

Here is a description of our open source license compliance needs - I wonder if these would be useful for others:

• There should be a way to define a list of compliant licenses, either as a global setting or separately per project. This is the organization's or project's OSS license policy. For example, some projects allow LGPL components while other projects cannot include LGPL code.

• A report would show the compliance of a project with regard to the OSS license policy. This would be similar to the vulnerability dashboards, and it could highlight the projects that have license compliance issues

• It would be nice to have another report that would list the components of a project grouped by license

• Not all components will have their license available in the CycloneDX BOM, so there should be a way to mark these components as compliant or non-compliant manually in Dependency-Track. However, as the component authors may later change the license in newer versions of the component (as the BOM is updated), then the manually entered compliance ratings may become invalid. Maybe the tool could highlight these components to indicate that the version has changed since the latest manual license compliance approval

[stevespringett]

@hehaveri thank you for the use-cases. Being an OWASP project with a security focus, my first priority will be #83 which adds security-related policies. But at that point, a policy engine would have been built and integrated into Dependency-Track. I'll ensure its designed in a way to also accommodate license policies as well.

Reporting is not something this project will ever do however. Everything is API-first, API-all-the-time. Reports themselves are not actionable and outdated the moment they're generated. The thing we're trying to build here is more about real-time consumption and being a single source of truth. We will have dashboard, a visual way to see various metrics (including policy violations), just like what you have now with other metrics, but the exporting of reports is not on the roadmap. Using the API, you could however, generate a report.

With that said, it would be nice to see some screenshots of what some of the other products do in this space. I'm a security person, not a compliance or license expert. So if there's aspects of one product that folks like but dislike other aspects, that would be good to know.

With that in mind, start uploading screenshots, mockups, etc, and have others upvote/downvote the things they like/dislike and have the community guide what they want to see in terms of license auditing, workflows, and governance.

[hehaveri]

@stevespringett Here is a PDF that presents some mockup ideas about how open source license compliance could be added to Dependency-Track. The features are based on our experience with an internal tool. I hope this is useful for the community discussion!

Dependency-Track-oss-license-compliance.pdf

Thank you for explaining the API first and reporting strategy - it makes perfect sense to me.

Lastly, many thanks for your work on Dependency-Track in general. The project is truly a major contribution to the software security community.

[stevespringett]

@hehaveri This is fantastic! You and team have obviously been thinking about how best to integrate license functionality within Dependency-Track for awhile. This gives me a much better understanding of what a typical workflow would be, and I like the consistency between vulnerability and license auditing. Overall, I think this makes a lot of sense.

I think the first step would be to develop the auditing functionality itself along with the corresponding APIs and metrics. Once that's done, it'll be on-par with the existing vulnerability auditing.

At that point, it makes sense to start work on a policy engine that can accommodate:

• Vulnerability policy
• Outdated component policy
• License policy

For the sake of scope however, this ticket will be specific to the auditing functionality itself.

Also as a side-note, if you're not already participating in the Dependency-Track Slack channel, I encourage you to do so. I always post thoughts, unpublished roadmaps and initiatives, etc there. Links in the 'About' dialog in Dependency-Track. The next major release after v3.4 will be feature-less - similar to macOS Snow Leopard in concept. It's a hardening-only release. See: https://owasp.slack.com/archives/C6R3R32H4/p1544132671011800

[msymons]

I agree with both the last two comments... that @stevespringett deserves a lot of thanks for his hard work, and also that the PDF is a very useful document.

I'll try and give some specific feedback before I leave the office on Friday, but for now, don't forget that the APIs will need to support negative queries (is that the right wording?) ie,

• License is not fsLibre
• Tag is not xxx

Concerning Slack, I signed up the other day and it seems that the Dependency-Track Slack channel can only be joined via an admin invite. But I could see no way to request such an invite. What to do? =)

[stevespringett]

https://join.slack.com/t/owasp/shared_invite/enQtNDI5MzgxMDQ2MTAwLTEyNzIzYWQ2NDZiMGIwNmJhYzYxZDJiNTM0ZmZiZmJlY2EwZmMwYjAyNmJjNzQxNzMyMWY4OTk3ZTQ0MzFhMDY

[stevespringett]

This will require a lot of UI changes to a UI that will soon be deprecated. I'll need to wait until the new front-end is complete.

Dependency-Track/front-end

[stevespringett]

Is it possible to get a list of SPDX IDs which fall into the following categories:

• Copyleft
• Weak Copyleft
• Liberal (Permissive)

https://tldrlegal.com/licenses/tags/Copyleft
https://tldrlegal.com/licenses/tags/Weak%20Copyleft
https://tldrlegal.com/licenses/tags/Permissive

FOSSA has a free online reference. Doesn't look like they have an API available, but we could use it as research.

Is there any other accurate and freely available source which has interrupted SPDX licenses and has clearly defined terms, conditions, and has put them into general buckets as defined above?

[stevespringett]

My thinking here is that each SPDX license can be part of zero or more license groups.

License groups can be created, edited, etc in the UI. A few built-in license groups would be helpful for people to get started. I'm proposing default license groups of Copyleft, Weak Copyleft, and Liberal (or Permissive). But you could also create license groups for 'Whitelist', 'Blacklist', etc, as these are the examples in the PDF that @hehaveri attached.

License groups would then be an optional condition when creating a policy. If a policy is created that restricts use of any license in the blacklist or copyleft license groups, then that would lead to the results that would be displayed in the license audit tab.

[stevespringett]

BTW @msymons, I know this ticket has morphed into something not exactly what was stated in the ticket description. However, global component metadata is going away when #593 is implemented.

[hehaveri]

@stevespringett 's license group concept sounds great, and the proposed default license groups make sense to me.

I don't know if there are any authoritative sources that we could use, but the lists from tldrlegal.com look short and good to me. The most important and widely used licenses seem to be included. As the predefined lists are meant as starting points, then I think it is fine that not all licenses have been classified or included in the predefined default groups.

[stevespringett]

I just checked in the default license groups that will be created on startup. Refer to 39be934

The licenses specified are SPDX license IDs. You can either use DT to look them up, or refer to them here: https://spdx.org/licenses/

Can someone go through the list and check for any licenses that are not in the correct license group?

If your org has counsel on staff, it would be extremely helpful if you can run it past them as well. Additionally, if you have counsel on staff, I'd like to have a sentence or two that makes it clear that the project is not providing legal advice.

[stevespringett]

Here's a 'mostly' working prototype of license groups:

[stevespringett]

Displaying policy violations for a project now works and is auditable. Violations currently support license and operational risk. Security violations will be added in a future release.

A few minor things are left to do but for the most part the functionality is implemented and works as designed.

Policy violation - license

Policy violation - operational

[stevespringett]

Closing. Auditing license policy violations is included in v4.0 - to be released soon.

[adibo]

Hi,
Firstly thank you for all the effort put into DependecyTrack development! I'm new but it's already a great work, with potential for even more.
I'm trying v4.0.0 with an attempt to check the new feature of license policy violation but I was unable to define any sensible policy such that it would fail just for the sake of testing. Am I missing something or is it yet in early development (e.g. UI is ready, but the backend not so just yet).

For example, let's say I have components loaded with a single item having MIT license (member of Permissive group). Suppose I want my policy to detect this item.

So my Test Policy could look like this

Name: Test License Policy
Operator: All
Violation State: Fail

with conditions of
License group is not Permissive

Is my thinking correct? If I suppose so, upon a refresh scan, no Policy Violations are reported (note: all actions via UI). Looking forward for any guidance.

[stevespringett]

@adibo not sure what you mean by 'refresh scan' That concept doesn't exist. A scan (and subsequent policy evaluation) can be triggered on a individual component simply by editing the component and clicking 'update' without making any changes, or can be triggered by uploading a BOM (even if it's the same one). Otherwise, a rescan will take place every 24 hours.

[adibo]

Thanks, that was a good hint. I am now uploading the same BOM each time.

Another issue though is that for a given component, the license field is empty on the component details view (under Legal tab) event though the license (but not the license group!) is correctly assigned in the components list view.
And the license policy seem to work for components with component legal details updated by hand.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.