Configuration Integrity Check Tool and Report

[msymons]

Current Behavior

Dependency-Track does not provide UI feedback to the administrator to highlght when there might be configuration or other problems. Sometimes DT might not even be checking for problems. DT Logs can be useful... but an admin might even have access to them.

Proposed Behavior

• Provide an integrity report in the Administration page that gives details of any problems, with severity.
• Implement a task that performs integrity tests. This should run on startup and periodically thereafter... and be used to populate the integrity report
• Create integrity tests. A useful MVP would be a check on whether OSS Index Analyser has been configured with an API token.
• Ideally, display a warning flag in UI to admin users to alert them to the the existence of unresolved problems. This can be done in a similar way to Jenkins.

Checklist

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

[stevespringett]

We need to decompose:

Provide an integrity report in the Administration page that gives details of any problems, with severity.

into discrete things that need to be checked. Once that list is defined, we need to get consensus on the severity of each.

[valentijnscholten]

I'm curious about the list, if there are common things that can go wrong (and possibly can be improved or made more robust). Another option is to have more feedback in the UI about things that have gone wrong, similar to what defect dojo has. Some kind alert / notification / message box on the top right showing warnings and errors that have occurred.

[nscuro]

+1 for the idea.

The result of those checks should be easily consumable by automated monitoring tools. Relying on an admin user to log in would be sub-optimal, especially in setups that practice least-privilege. Also, there may be some overlap with health checks.

When run in k8s or similar orchestration platforms, failing health checks may be used to pull an instance out of load balancing (readiness). Depending on the severity of the misconfiguration, this may be desired (e.g., no point in accepting new BOM uploads if analysis will always fail).

When categorizing possible misconfigs, the different functions of the platform should be considered. It's nice to know that OSS Index may be misconfigured. but it'd be even more interesting to know when vuln analysis as a whole won't work (e.g. NVD mirroring disabled, OSS Index enabled but API key expired, and no other analyzer enabled).