ci(github): specify unique & self-explained jobs IDs across workflows

Djaytan commented 9 months ago

The not ideal naming for jobs IDs has been highlighted by the usage of act (https://github.com/nektos/act), especially when listing the detected jobs:

Stage  Job ID           Job name           Workflow name             Workflow file               Events
0      security-scan    Security scan      CI                        ci.yml                      workflow_dispatch,push,pull_request,schedule
0      build-and-test   Build & Test       CI                        ci.yml                      schedule,workflow_dispatch,push,pull_request
0      analyze          Analyze            OpenSSF Scorecard - Scan  openssf-scorecard-scan.yml  workflow_dispatch,branch_protection_rule,push,schedule
0      release-perform  Release - Perform  Release                   release.yaml                workflow_dispatch
1      release-sign     Release - Sign     Release                   release.yaml                workflow_dispatch

The most problematic job's ID was "analyze" which is by no way self-explained.

The purpose is not to ensure full self-explaining of a job ID, but since we can encounter it lonely (that's being said: without its associated workflow), then it's convenient to opt for an ID which would be enough by itself to get quickly a grasp of what the job is doing independently of the workflow from which it comes. Until now, the naming was considered acceptable since we were able to get an idea of the job role by looking at the combination of its name with the workflow one. In this case, finding the following title in the GitHub commit status was enough: "OpenSSF Scorecard - Scan / Analyze". But since we plan to rely on the act CLI for local development of workflows, facing "analyze" as a lonely job ID can be considered as not convenient.

More concretely, the following usage is expected with the act CLI:

act workflow_dispatch --job analyze

But ending with a command similar to this one is preferable:

act workflow_dispatch --job scorecard-secure-supply-chain-analysis

As a comparison standpoint, here is the generated output of the act -l command after applying the proposed changes:

Stage  Job ID                                  Job name                                             Workflow name  Workflow file  Events
0      build-and-test                          Build & Test                                         CI             ci.yml         workflow_dispatch,push,pull_request,schedule
0      codeql-sast                             CodeQL - Static Application Security Testing (SAST)  CI             ci.yml         schedule,workflow_dispatch,push,pull_request
0      scorecard-secure-supply-chain-analysis  Scorecard - Secure supply-chain analysis             OpenSSF        openssf.yml    workflow_dispatch,branch_protection_rule,push,schedule
0      release-perform                         Release - Perform                                    Release        release.yaml   workflow_dispatch
1      release-sign                            Release - Sign                                       Release        release.yaml   workflow_dispatch

While updating the aforementioned job ID, the other ones have been reviewed as well and ended-up by updating the ID of the job in charge of executing the CodeQL security scanner against the source code. The new ID rely on a more precise term well-known in security domain.

More details about source code analysis can be found directly on the OWASP website: https://owasp.org/www-community/Source_Code_Analysis_Tools. Mentions of "SAST" can be found there. Another great article explains the differences between a couple of security terms that are used when it comes to speak about security testing topics: https://crashtest-security.com/sast-dast-iast-rasp/#interactive-application-security-testing-iast