Bring all monitored repositories to 100% in CLOMonitor

[yada]

The CLOMonitor audit conducted on 2026-09-18 reports an overall Microcks score of 98.49% (A). Fourteen of the twenty monitored repositories are already at 100%.

The remaining work is:

• hub.microcks.io: publish a recent release.
• microcks-backstage-provider: publish a recent release.
• microcks-jenkins-plugin: publish a recent release.
• import-github-action: publish a recent release and address the SBOM and signed-release checks.
• test-github-action: publish a recent release and address the SBOM and signed-release checks.
• microcks-docker-desktop-extension:
  • Publish a recent release.
  • Provide or document an SBOM.
  • Sign the release artifacts or provide provenance.
  • Define restrictive GITHUB_TOKEN permissions in .github/workflows/build-verify.yml.

For the two source-only GitHub Actions, maintainers should decide whether to produce signed release artifacts and SBOMs or declare documented exemptions in each repository's .clomonitor.yml when those checks are not applicable.

References:

• Microcks CLOMonitor report
• CLOMonitor check and exemption definitions

Completion criteria: every monitored repository reports 100% after the next CLOMonitor refresh.

[yada]

Another option to consider is using CLOMonitor’s code-lite check set for secondary code repositories.

Based on SUBPROJECTS.md, we could keep code for the core products (microcks and microcks-operator) and evaluate code-lite consistently for SDKs, libraries, integrations and tooling. hub.microcks.io could also be considered secondary code rather than a documentation-only repository.

For the repositories listed in this issue, switching to code-lite would:

• Remove the SBOM and signed-release checks from import-github-action and test-github-action.
• Remove the SBOM, signed-release and token-permission checks from microcks-docker-desktop-extension.
• Not change the findings for hub.microcks.io, microcks-backstage-provider or microcks-jenkins-plugin.

The recent-release check is part of both code and code-lite, so all six repositories would still require a release less than one year old.

This should be treated as a classification decision applied consistently to secondary repositories, not as a way to hide failing checks. It also reduces security coverage because code-lite does not include SBOM, signed releases, token permissions, code review, maintenance or dependency-update checks.

Reference: CLOMonitor check-set definitions.

[yada]

As CLOMonitor defines:

• code: primary code repositories.
• code-lite: secondary code repositories.

I think this is a legitimate update. @lbroudoux, what's your point of view?