BOM validation soft failing

[rkg-mm]

Current Behavior

Currently, you either disable BOM validation, or you enable it. Which either results in no validation or possibly many failures right now.

Proposed Behavior

Add another state "soft validation" which

1. Does enable validation
2. On failure:
   2a) Logs validation failure with details
   2b) sends out notification of validation failed (see Notification Event: Bom Validation Failed #3778)
   2c) Possibly gives feedback in return of API call
3. But: DOES NOT FAIL the import, and still returns API status 200 OK.

This would allow the monitoring of imports for a while, to ensure all used tools behave properly. Due to usage of many tools in different projects and different circumstances in different projects it would be beneficial to first observe the behaviour for some weeks before letting uploads faile. Furthermore it might give a hint in the logs if a validation failed AND later the processing failed. This might help identifying processing issues.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[nscuro]

Add another state "soft validation"

Instead of the soft validation wording, I'd prefer the current boolean option Validation enabled to become a BomValidation enum with possible values being along the lines of:

• DISABLED - Do nothing
• MONITOR - Log and alert
• ENFORCE - Reject invalid BOMs (still log and alert?)

2c) Possibly gives feedback in return of API call

This could lead to some confusion / inconsistencies WRT API design. Getting a successful (HTTP 200) response that indicates errors in its body is an anti-pattern. Not sure how to implement this suggestion in a sensible way.

[aravindparappil46]

I like the idea of this "continue-on-error" kind of validation.

We had to turn off BOM validation due to external references URL being invalid from cdxgen (CycloneDX/cdxgen#1107), so definitely see the value here.

The enum approach sounds neat. Maybe could call it Validation Mode? (STRICT, LENIENT, DISABLED)

[rkg-mm]

2c) Possibly gives feedback in return of API call

This could lead to some confusion / inconsistencies WRT API design. Getting a successful (HTTP 200) response that indicates errors in its body is an anti-pattern. Not sure how to implement this suggestion in a sensible way.

Not a hard requirement from me, just thought it could come handy for some people. However, I think if its a "Warning" not an Error, it could be fine to return.