Add Security Scan workflow as part of the SSDLC requirements #603
Conversation
srbouffard
requested review from
cbartz,
yhaliaw,
javierdelapuente and
yanksyoon
as code owners
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
license-eye has checked 311 files.
| Valid | Invalid | Ignored | Fixed |
|---|---|---|---|
| 62 | 1 | 248 | 0 |
Click to see the invalid file list
- trivy.yaml
Use this command to fix any missing license headers
```bash
docker run -it --rm -v $(pwd):/github/workspace apache/skywalking-eyes header fix
</details>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
.github/workflows/security_scan.yaml
Outdated
| security-events: write | ||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
I would recommend pinning the actions to an exact version and rely on renovate to update them so that workflows are not impeding reusable builds
There was a problem hiding this comment.
What should be the recommended approach with regards to the renovate config?
From what I have read the default renovate behavior is to pickup Github workflow files. Is there anything specific I need adjust in our renoate.json?
There was a problem hiding this comment.
Ah ok, I see now ;) Updated the versions to exact versions to make sure renovate will pick them up
.github/workflows/security_scan.yaml
Outdated
|
|
||
| - name: Upload diagnostic SARIF artifact | ||
| if: (github.event_name == 'workflow_dispatch' && inputs.upload_results == true) || (github.event_name != 'workflow_dispatch' && env.UPLOAD_RESULTS == 'true') | ||
| uses: actions/upload-artifact@v4 |
.github/workflows/security_scan.yaml
Outdated
|
|
||
| - name: Upload SARIF to GitHub Security tab | ||
| if: (github.event_name == 'workflow_dispatch' && inputs.upload_results == true) || (github.event_name != 'workflow_dispatch' && env.UPLOAD_RESULTS == 'true') | ||
| uses: github/codeql-action/upload-sarif@v3 |
.github/workflows/security_scan.yaml
Outdated
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v4 |
|
|
||
| env: | ||
| # This value is used for push and pull_request triggers | ||
| UPLOAD_RESULTS: true |
There was a problem hiding this comment.
I don't see where this value might change so, why the env variable?
There was a problem hiding this comment.
You are right, it serves nothing here. My initial thoughts was as a quick and "global" way to control the default upload behavior on the various jobs/steps. Using workflow_dispatch and workflow_call provides these global inputs and controls but having the workflow trigger on pushes and PRs, did not offer an inputs section.
I can remove it. But I have a followup question, what is the "upload" behavior you would expect when it's a "push to main", push to branch and a PR?
The Github security tab supports listing security events per branch so doing on upload on pushes to branch and PRs does not pollute anything or cause much noise.
| @@ -0,0 +1,83 @@ | |||
| name: Security Scan | |||
There was a problem hiding this comment.
Is there any reason for not defining this workflow as part of the operator workflows? It would be simpler to reuse by other repositories
There was a problem hiding this comment.
100% with you on that and that is the longterm goal with this workflow.
The idea behind why I didn't go that route strait away was that the current SSDLC requirements are specifically targeting the GitHub Runner product.
- The goal is to first implement and refine this security automation for the runner. Once the process is fully ironed out and proven effective (meets the requirements of the SSDLC process), we can then look at generalizing this workflow and moving it to operator-workflows for all our projects to benefit from, especially as SSDLC requirements expand.
- Also, the workflow currently only does a
fsscan, but I would want it to be more robust and support scanning a charm, rocks. Similar to what the data-platform team have done on their side. - Then there is the whole vulnerability response aspect that I think needs to be ironed out before we propagate the security checks to other project.
Does that make any sense, or you think it would still be more worthwhile to start directly within the operator-workflow?
| @@ -0,0 +1,83 @@ | |||
| name: Security Scan | |||
There was a problem hiding this comment.
I don't see a license header in this file, not sure why
There was a problem hiding this comment.
Added the license header to the new workflow file. Seems that the whole of github folder is configured to be ignored for the license check
TICS Quality Gate❌ FailedThe following errors have occurred during analysis:❌ [ERROR 5333] Project database 'github-runner-operator' already is connected to a started TICSQServer process that has not registered a stop time. To avoid data corruption, analysis is aborted. Details of the other TICSQServer process: started at 2025-07-09 14:32:08.000 by user ubuntu. .github/workflows/tics.yaml / TICS / TICS GitHub Action |
Applicable spec: SSDLC - Vulnerability Identification
Overview
This pull request introduces a dedicated
security_scan.yamlGitHub Actions workflow. This workflow is designed to automate vulnerability management for the GitHub Runner charm, fulfilling the current SSDLC requirements.The new workflow includes the following jobs:
mainor manually via aworkflow_dispatchevent.Rationale
The primary motivation for this change is to meet the vulnerability identification requirements outlined in this cycle's SSDLC policy for our GitHub Runner product. This workflow automates the required security scans directly within our CI pipeline.
Why a Dedicated Workflow?
While the existing
integration_testsworkflow includes a Trivy scan, a dedicated security workflow was because security scanning is a distinct concern from integration testing. Decoupling them allows for more focused, maintainable, and independent jobs that can be triggered separately if needed.Why Not in
operator-workflows(Yet)?The current SSDLC requirements are specifically targeting the GitHub Runner product. The goal is to first implement and refine this security automation for the runner. Once the process is fully ironed out and proven effective, we can then look at generalizing this workflow and moving it to
operator-workflowsfor all our projects to benefit from, especially as SSDLC requirements expand.Checklist
urgent,trivial,complex).github-runner-manager/pyproject.toml.