[cmainas]

Description

This is a follow up of #1128. It performs the following fixes:

• The nightly fuzzing could not build because the root .dockerignore only allows a fixed list of paths and did not include .clusterfuzzlite/, so COPY .clusterfuzzlite/build.sh failed.
• A missing fuzz target was reported as successful, which would lead to a successful workflow after a function rename. This will also get addressed from future improvements in fuzzing, but adding it here as well.
• Upload the SARIF from batch fuzzing action, since output-sarif only writes cifuzz-sarif/results.sarif. The batch workflow now saves it as an artifact and a separate upload-sarif job uploads it. The ClusterFuzzLite actions run mutable :v1 images, so the job running them only gets read access, and only the upload job gets security-events: write.
• Rename fuzz_nightly.yml to fuzz_batch.yml (daily at 00:00 UTC, 30 minutes of fuzzing). and make fuzz_prune.yml to run weekly (Sundays 13:30 UTC) instead of daily, since each run rebuilds the fuzzers and the corpus of a single target grows slowly. Both share the clusterfuzzlite-corpus concurrency group, because each run downloads the corpus, changes it and uploads it again.
• Track the base-builder-go image digest through dependabot.

Related issues

• Ref Add fuzzing and robustness testing #852

How was this tested?

In a separate repository. Workflow runs:

• batch: https://github.com/urunc-dev/urunc_test/actions/runs/40735777362/job/122983792426
• prune: https://github.com/urunc-dev/urunc_test/actions/runs/40747529704/job/123025199882

LLM usage

Opus 5.5

Checklist

• I have read the contribution guide.
• The linter passes locally (make lint).
• The e2e tests of at least one tool pass locally (make test_ctr, make test_nerdctl, make test_docker, make test_crictl).
• If LLMs were used: I have read the llm policy.

[netlify]

✅ Deploy Preview for urunc canceled.

Name	Link
🔨 Latest commit	bb6c65c
🔍 Latest deploy log	https://app.netlify.com/projects/urunc/deploys/6ae33ff7792567af3f826425

[cmainas]

Hello @pocopepe can you also review this?

[ananos]

thanks @cmainas! This fixes the actual reason the scheduled fuzz runs fail on main (eg. run 40791889402):

COPY .clusterfuzzlite/build.sh /src/: "/.clusterfuzzlite/build.sh": not found

The allowlist .dockerignore from eba28d3 dropped .clusterfuzzlite/, and !/.clusterfuzzlite brings it back. The rest looks good too: the fuzz job is down to contents: read / actions: read with security-events: write only on the upload job, there is no pull_request_target, action SHAs match the rest of the repo, and actionlint + shellcheck are clean. The build.sh guard now fails on a missing target, which was a false green on main.

The fuzz workflows only run on schedule/dispatch, so the files in this PR have not run here (the urunc_test runs use a shared fuzz.yml). We should trigger batch and prune manually once after merge.

Nits:

• fuzz_batch.yml:48-57: upstream batch mode writes the SARIF from the last fuzz target only (TODO: Handle multiple crashes). Fine with one target today. Once we add a second one, a crash in an earlier target would leave the SARIF empty and close the alert, although the job still fails. Maybe a one-line comment next to output-sarif: true?
• the concurrency group keeps one pending run, so a queued manual dispatch could be cancelled by the next scheduled run. Unlikely with these schedules.
• a03bc8a has a double space in the subject (ci: upload SARIF ...).

I intend to approve -- let me know if you want to touch any of the nits first.

[cmainas]

Thank you @ananos for the review. Let;s wait @pocopepe as well.

[pocopepe]

Hi @cmainas, thanks for the fixes! looked through it, LGTM. Agree with the SARIF note above, we'll need to handle it before a second target.

[ananos]

thanks @cmainas & @pocopepe! LGTM.