[Umbrella] Enhancement of Karmada maturity based on Clomonitor check sets

[zhzhuang-zju]

What would you like to be added:
CLOMonitor is a tool that periodically checks open source projects repositories to verify they meet certain project health best practices, and will provide a score card for each project based on the check results. Here is the score card for karmada: https://clomonitor.io/projects/cncf/karmada. As you can see, there's still some work to be done.
Here list the check set that karmada did not pass.

• license scanning (@B1F030 [License]Add foaas badge in README.md #5050)
  Karamda completes the license scanning software scans in fossa workflow, so we only need add the FOSSA link in the README file. Regexps used: "(https://app.fossa.(?:io|com)/projects/[^"'\)]+)"

• Artifact Hub badge (@B1F030 Add Artifact HUB badge #5051)

• OpenSSF Scorecard badge (@B1F030 Modify OpenSSF Scorecard badge #5055)
  We have added the OpenSSF Scorecard badge in the README file in Add OSSF scorecard badges #5022, but the url https://api.scorecard.dev/projects/github.com/karmada-io/karmada/badge does not match the specified regexps "(https://api.securityscorecards.dev/projects/github.com/[^/]+/[^/]+)/badge" and needs to be modified.

• Dependencies policy （@zhzhuang-zju）

• Software bill of materials (SBOM)(@zhzhuang-zju add sbom to release assests #5110)

• Security insights (@zhzhuang-zju)

• Signed releases
  Karmada images have been signed with cosign since release1.7, but we need add the SLSA provenance file in the assets for release (*.intoto.jsonl)

• Token permissions
  define topLevel permission for each workflow

  • ci-image-scanning.yaml (@aditya7302 Define top level Permission for ci-image-scanning workflow #5059)
  • ci-schedule-compatibility.yaml (@aditya7302 Define top level Permission for ci-schedule-compatibility workflow #5068 )
  • ci-schedule.yml (@aditya7302 Define top level Permission for ci-schedule workflow #5069)
  • ci.yml (@Akash-Singh04 Define top level Permission for ci.yml workflow  #5078)
  • cli.yaml (@Akash-Singh04 Define top level Permission for cli.yml workflow #5079)
  • dockerhub-latest-chart.yml (@aditya7302 Define top level Permission for dockerhub-latest-chart.yml (latest chart to Dockerhub) work flow #5082)
  • dockerhub-latest-image.yml (@zhzhuang-zju )
  • dockerhub-released-chart.yml (@zhzhuang-zju )
  • dockerhub-released-image.yml (@zhzhuang-zju )
  • fossa.yml (@aditya7302 Define top level Permission for fossa.yml (FOSSA) workflow #5080)
  • lint-chart.yaml(@aditya7302 Define top level Permission for lint-chart.yaml (Chart Lint) workflow #5081 )
  • release.yml (@zhzhuang-zju )
  • swr-latest-image.yml (@zhzhuang-zju )
  • swr-released-image.yml (@zhzhuang-zju )

Reference:

• https://clomonitor.io/projects/cncf/karmada
• https://clomonitor.io/docs/topics/checks/
• https://scorecard.dev/viewer/?uri=github.com/karmada-io/karmada

Why is this needed:
Improving scores is not the ultimate goal, I hope to use this issue to make Karmada healthier and more mature

[zhzhuang-zju]

/help

[karmada-bot]

@zhzhuang-zju:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[zhzhuang-zju]

cc @B1F030

[B1F030]

I'm glad to help! Can I take the license scanning first?

[zhzhuang-zju]

I'm glad to help! Can I take the license scanning first?

done~

[RainbowMango]

Maybe we can have the badge of CLomonitor. See example at https://github.com/kubeflow/kubeflow/blob/master/README.md.

[aditya7302]

@RainbowMango I have added the CLOMonitor badge in my PR.

[Akash-Singh04]

Hey does this issue require any more help?If so, I would like to work on it

[zhzhuang-zju]

Hey does this issue require any more help?If so, I would like to work on it

Sure, go ahead. Please pick what interests you and do it~

[aditya7302]

@RainbowMango @zhzhuang-zju I have added top-level permission for ci-image-scanning workflow. Please review it.

[Akash-Singh04]

@RainbowMango @zhzhuang-zju I have added top-level permission for ci.yml and cli.yml workflow. Please review it.

[zhzhuang-zju]

@aditya7302 @Akash-Singh04 Thanks for your efforts on task Token permissions. Defining the minimal permission set for workflow is actually difficult, do you have any experiences to share? Besides, how can we effectively go about verifying the results(all I can think of at the moment is local verification)? Other than that, have you encountered any other difficulties? Looking forward to your feedback!

[zhzhuang-zju]

@aditya7302 @Akash-Singh04 Thanks for your efforts on task Token permissions. Defining the minimal permission set for workflow is actually difficult, do you have any experiences to share? Besides, how can we effectively go about verifying the results(all I can think of at the moment is local verification)? Other than that, have you encountered any other difficulties? Looking forward to your feedback!

I found the recommended steps and an online tool to complete the task Token permissions!
refer to https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions:

The highest score is awarded when the permissions definitions in each workflow's yaml file are set as read-only at the top level and the required write permissions are declared at the run-level.

Following this criterion, the recommended steps are:

• Set top-level permissions as read-all or contents: read as described in GitHub's documentation.
• Set any required write permissions at the job-level. Only set the permissions required for that job; do not set permissions: write-all at the job level.

So, we had a problem with the previous implementation and needed to be revised.

To help determine the permissions needed for our workflows, we can use StepSecurity's online tool by ticking the "Restrict permissions for GITHUB_TOKEN".
NOTE: Cleanup workflow's previously defined permissions before using it, and the result may be more precise.

[aditya7302]

@zhzhuang-zju As I am new to learning workflows, I primarily use local verification to test them. This method helps me ensure that the workflows function correctly within a controlled environment. However, I think that defining the minimal permission set for large workflows can be quite challenging.

[zhzhuang-zju]

@zhzhuang-zju As I am new to learning workflows, I primarily use local verification to test them. This method helps me ensure that the workflows function correctly within a controlled environment. However, I think that defining the minimal permission set for large workflows can be quite challenging.

I can't agree more~ Local verification is actually the safest way. Now with the tool Scan, this process is even easier. However, in some cases, the tool's database does not have permissions information of a certain action, we can only verify them locally or refer to other user-defined permissions.
BTW, thank @aditya7302 and @Akash-Singh04 for your contributions.