Policy Engine results in no violations

[dashmesh]

Hi Steve,

I have been trying out Dependency Track 4.0. I am especially interested in the policy engine but no matter what I do, it does not seem to produce any violations.
I watched your live stream for DT 4.0 where I watched you demonstrate this feature. Some pointers in this regard would be appreciated.

Thanks,
Dashmesh

[stevespringett]

What policy conditions are you having trouble with - and what is the component or license data for which the condition is being evaluated against?

[dashmesh]

Hi Steve, Thanks for the speedy response. It is so very kind of you. I have the following Policy Management configuration: **New License Group:** Name: ABC Allowed Licenses - Licenses Selected: GNU General Public License v2.0 w/Autoconf exception **Following 3 custom policies created:** 1. Name: License Violation | Operator: All | Violation State: Fail | Condition: License IS NOT Abstyles License 2. Name: License Violation 1 | Operator: All | Violation State: Warn | Condition: License Group IS NOT ABC Allowed Licenses 3. Name: Test Policy | Operator: Any | Violation State: Inform | Condition: Coordinates DOES NOT MATCH abcd abcd 1.0 All of the above in my opinion were destined to cause a policy exception unless there is something I have completely missed. I have tried these on DT 4.0 / 4.0.1. The two applications/projects being subjected to these policies are as follows for which I got the BoM files from GitHub site for CycloneDx: - keycloak v10.0.2 - dropwizard v1.3.15 I am using the bundled version of DT - dependency-track-bundled.war Thanks.

[stevespringett]

I created the license group, the three policies, and imported the bom from dropwizard. The result is 394 policy violations.

I'm not sure why its not working... Was the bom imported AFTER the policies were create or BEFORE? If the policies were created AFTER the bom was imported, you'll have to wait until the next analysis which will take place upon the import of the bom again or every 24 hours thereafter.

[dashmesh]

Hi Steve,

Additional information for the policy engine behavior. I confirm that the policy engine flagged the violations for the following cases:

1. BoM upload after the Policy is created and
2. subsequent modification of the Policy (not tested thoroughly)

I have 3 projects 2 of which had their BoM files uploaded before creating the Policy. The policy violations did not get flagged for these two projects in both of the cases mentioned above.

The issue persists and the policy engine fails to get triggered if the BoM files are uploaded before creating the Policy. I hope this helps to identify the root cause of the problem or is this the expected behavior?

DT v 4.0.1

Thanks,
Dashmesh

[keymandll]

Hi there,

I would also like to report that the feature does not seem to be working.

My policies:

Name: Baseline, Operator: Any, Violation State: Fail
License group IS NOT Permissive

Name: Baseline 2, Operator: Any, Violation State: Warn
License group IS NOT Permissive

I have a project in which I purposefully included a GPLv2 licensed dependency to trigger a violation. However, there is nothing visible even after I import the BOM again.

I'm using the latest Docker Container provided.

I was trying to look for some guidance in the documentation at https://docs.dependencytrack.org/analysis-types/license/ but the page is basically empty.
I thought I may have to assign the policy to individual projects but I could not find an option for that.

Any help would be highly appreciated!

[keymandll]

Thanks @stevespringett . So what does "resolved" and "unresolved" mean other than how it's represented on the UI? What I'm trying to understand is how can I set up a policy so if the project has any components with a non-permissive license such as GPLv2 I would be made aware of it?

[keymandll]

Oh, I see what resolved and unresolved means now, just had to read your reply a few times. I can see that all the components listed have unresolved licenses.

Digging more into this, I can see what the problem is. Most of the Python modules out there do not use SPDX License IDs in the license property of the setup.py file. Classifiers are also incompatible with the SPDX License IDs so cyclonedx-py does not even have a chance of resolving the licenses to SPDX License IDs. As a result, the license policy feature of Dependency-Track will simply not work with most of the Python projects by default.

[stevespringett]

I think there's room for improvement in the CycloneDX Python module. The .NET implementation for example, will first consult NuGet to determine the license. If it cannot be determined from NuGet, it will query the GitHub API for the project to determine the license. Similar logic could be incorporated into the Python implementation - simply replace NuGet with pypi but the logic would remain roughly the same. Pull requests for the project are greatly appreciated.

[stevespringett]

There's also room for improvements for Dependency-Track. License matching functionality exists in these three open source projects:

• SPDX Java Library is a new library (replaced the legacy SPDX Tools currently being used by DT).
• HERE Open Source Review Toolkit (ORT) has good license matching logic although the it isn't decoupled from ORT itself, so I'd have to work with the project to do so.
• nexB Scancode Toolkit also has good license matching logic but its written in Python, so Dependency-Track would either need to use Jython or GraalVM. (I have plans on experimenting with GraalVM anyway)

Once license matching logic is in place, it's possible that some of those unresolved license names coming in from CycloneDX could be resolved by DT. Once resolved, policy conditions would work on those components.

[devsecopsale]

Hi @stevespringett / @keymandll , I'm experiencing the same issue. Does any issue (enhancement) need to be created for this? thank you