PolicyEngine throws error when uploading a BOM

[Jonas-vdb]

Current Behavior:

When uploading a BOM the following exception is thrown in the logs:

2022-08-23 07:13:51,597 INFO [PolicyEngine] Evaluating 260 component(s) against applicable policies
2022-08-23 07:13:54,507 ERROR [Persist] Update of object "org.dependencytrack.model.ViolationAnalysis@5840ab71" using statement "UPDATE "VIOLATIONANALYSIS" SET "POLICYVIOLATION_ID"=? WHERE "ID"=?" failed : org.postgresql.util.PSQLException: ERROR: null value in column "POLICYVIOLATION_ID" of relation "VIOLATIONANALYSIS" violates not-null constraint
  Detail: Failing row contains (4, APPROVED, 2045, null, 48, t).
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2675)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2365)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:355)
...
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)

2022-08-23 07:13:54,519 WARN [General] ExecutionContext closed with active transaction, so rolling back the active transaction
2022-08-23 07:13:54,554 ERROR [LoggableUncaughtExceptionHandler] An unknown error occurred in an asynchronous event or notification thread
javax.jdo.JDOUserException: One or more instances could not be deleted
        at org.datanucleus.api.jdo.JDOPersistenceManager.deletePersistentAll(JDOPersistenceManager.java:837)
        at alpine.persistence.AbstractAlpineQueryManager.delete(AbstractAlpineQueryManager.java:484)
        at org.dependencytrack.persistence.PolicyQueryManager.reconcilePolicyViolations(PolicyQueryManager.java:167)
        at org.dependencytrack.persistence.QueryManager.reconcilePolicyViolations(QueryManager.java:513)
...

When examining the code I did see what was going on:

During the evaluation of the components by the PolicyEngine it calls the reconcilePolicyViolations (PolicyQueryManager:148). In that function it creates a list of PolicyViolation that need to be deleted.

When the delete happens, it will delete the PolicyViolation objects which will also trigger an UPDATE on the ViolationAnalysis. It will try to set the POLICYVIOLATION_ID to null which fails because it does not allowNull:

    @Persistent(defaultFetchGroup = "true")
    @Column(name = "POLICYVIOLATION_ID", allowsNull = "false")
    @NotNull
    @JsonIgnore
    private PolicyViolation policyViolation;

Should the ViolationAnalysis not also get deleted in this case? Should the delete not be cascading?

Steps to Reproduce:

I do not have fixed steps to reproduce: The configuration of the project where the BOM is uploaded to which also shows the error has Policy Violations that are marked as Approved with an audit trail attached.

Expected Behavior:

There should not be an error when uploading the BOM,

Environment:

• Dependency-Track Version: v4.5.1
• Distribution: Docker
• BOM Format & Version: CycloneDX 1.3 XML
• Database Server: PostgreSQL
• Browser: N/A

[Jonas-vdb]

I did not see any code changes for those models between 4.5.1 and master.

[nscuro]

Good catch, and great report @Jonas-vdb!

It indeed looks like we have to ensure that violation analyses are always deleted before we delete the violation itself.

[Jonas-vdb]

Additional info:

I did found out what triggered the issue.

The following Policy is set: License Group | is not | Permissive

There is one component that has the CC-BY-4.0 license. This license is not part of the default Permissive group.

Once I add this license to that group, it causes the issue.

[anpross]

Hello, we are running into the same issue - we have certain vulnerabillities under evaluation, hence are supressing them, and have policies configured against which we check if the just uploaded SBOM is compliant.

The Exception thrown results in our violations API-call forever returning processing=true. This happens regardless of if the outcome of the policy check would be positive or negative.

This effectivly breaks our workflow as we can not scan code with suppressed violations on projects that have a policy (which they would violate).

Im a bit surprised that this bug has not gotten more attention since i think our usage of DT should be fairly typical or maybe i am missing something - something is different for the vast majority of other users. If so, it would be most helpfull if you could point me to it.

We are on version 4.7.1.

regards, andreas.

[anpross]

hi all, we updated to 4.9.1. and the problem is gone. maybe this was fixed by a different change. regards, andreas.

[nscuro]

Fixed via #3228.

[github-actions[bot]]

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.