Hash Policy Limit Per Component

[francislance]

Current Behavior

In further improvement related to https://github.com/DependencyTrack/dependency-track/issues/4230

I believe it is a must to set a scope limit of policies per "component" not only limit by Project.

Example in the case of creating policy for Hash values:

• if you create a Hash value comparison the chances that all the rest of hashes of components in that project will fail.
• Hash values for sure differs per component so comparing a value is applicable only in 1 to 1 basis.

Steps to Reproduce

1. Create a Hash Policy
2. Set Limit To - the available option only is to limit per project (or project's tag) and not able to limit by component (or component tag)

Expected Behavior

• Hash value policy must be set to a scope of per component not project as it will render a lot of violations if there are many components in a project.
• Would be good to have a component tagging and that tag can be associated to a policy so that it only checks that specific component.
• Another suggestion is we can have a policy that compares the SBOM's component hash against the component hash in a Maven artifact repository (or other repositories used). This suggestion achieves a sort of integrity monitoring of your SBOM if it is complying or not with what's in the artifact repository. In short, SBOM's Component Hash vs Artifact Repository's Component Hash is not equal means policy violation.

Dependency-Track Version

4.12.0

Dependency-Track Distribution

Container Image

Database Server

N/A

Database Server Version

No response

Browser

N/A

Checklist

• [x] I have read and understand the contributing guidelines
• [x] I have checked the existing issues for whether this defect was already reported

[nscuro]

The way to handle this is to set the policy operator to ALL and add qualifying conditions that narrow down on the components you want to assert the hash for. For example using the Coordinates or Package URL subjects.

With policy operator ALL, all conditions must be met in order for a violation to be raised.

[francislance]

@nscuro i'll give this a try and revert back if all good. Thank you for your quick response on this.

[francislance]

Hi @nscuro

I did looked into this and you are right that it can be achieved.

I have observations on the behavior that I believe we can improve. As I understand this is how Policies work as of my latest testing:

1. OPERATOR with value of ALL will result in VIOLATION if ALL of the conditions are met.
2. I tested Package URL matches specific value condition - this indeed will report FAIL violation
3. I also tested Component Hash with IS_NOT - this also resulted in FAIL violation.

My opinion on this is item#2 above actually shouldn’t be a Condition, but rather be a Scope.

I can see that scoping is implemented already using the feature “Limit to projects/tags” however that also doesn’t limit yet the policy when it comes to special cases like hashing which definitely going to be targeting a 1 specific component.

Another defect I observed based on the use case above is that you will be reported with 2 Policy violations (both PURL and Component Hash) instead of you only checking the violation of the component hash.