Run vulnerability scan on latest release tags #5148
Conversation
Vulnerability scans were previously run on the latest state of currently developed branches. This provided assurance that the current branch state did not contain known vulnerabilities in dependencies, but did not provide assurance that the currently released code was free of vulnerabilities. This change runs vulnerability scans on the most recent release version tag for currently developed branches. Scan failures now indicate that a new release is required to address vulnerabilities in dependencies. Signed-off-by: Mark S. Lewis <[email protected]>
| fetch-depth: 0 | ||
| - name: Get latest release tag | ||
| id: latest-release | ||
| run: echo "tag=$(git -c versionsort.suffix=- tag --merged HEAD --sort=-version:refname | head -1)" >> "${GITHUB_OUTPUT}" | ||
| - name: Checkout ${{ steps.latest-release.outputs.tag }} | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| ref: ${{ steps.latest-release.outputs.tag }} |
There was a problem hiding this comment.
I see the value in running against the latest tags. But we also want to know if the current branches have all vulnerabilities resolved, especially heading into an upcoming release. So maybe we need to run for BOTH current branch AND latest tags?
There was a problem hiding this comment.
Typically I don't worry too much about dependency versions until there is either a vulnerability in dependencies for the current release or I am about to make a new release. In both cases I usually look to bump up all dependency versions. While I'm doing that I can run a scan manually.
There is little effort in also scanning the current code base too though. No harm in having it.
| go-version: 1.24.0 | ||
| # Always use the latest Go release to avoid false positives from older | ||
| # versions of the Go standard library | ||
| go-version: stable |
There was a problem hiding this comment.
Shouldn't we run with the same Go version that the rest of the repository uses? To know if we need to update Go to address vulnerabilities.
There was a problem hiding this comment.
I'll support @denyeart . Go should be the one you build and test with.
There was a problem hiding this comment.
Since Fabric is publishing binaries rather than being consumed as a library, that is a good point. However, that makes me think that the way Fabric is handling Go versions is wrong. Using the Go version currently being used to build Fabric doesn't help identify standard library issues when scanning previously released versions. Probably the go.mod file should be specifying an explicit toolchain version. This then allows the correct Go version for a given release to be used when retrospectively scanning for vulnerabilities. It also removes the need to keep updating specific Go versions across all the GitHub Actions workflows. They can just use stable and the Go toolchain version will actually be used. What do you think?
|
I don't like that you put everything in one action. |
This PR doesn't introduce or change that behaviour. It might be good to capture this requirement in an issue so it isn't forgotten. |
Vulnerability scans were previously run on the latest state of currently developed branches. This provided assurance that the current branch state did not contain known vulnerabilities in dependencies, but did not provide assurance that the currently released code was free of vulnerabilities.
This change runs vulnerability scans on the most recent release version tag for currently developed branches. Scan failures now indicate that a new release is required to address vulnerabilities in dependencies.