Testing Max-Mode Attestations #9
Conversation
WalkthroughThe updates introduce a new GitHub Actions workflow for container security scanning using Docker Scout on pull requests, enhance existing container build and publish workflows to generate maximum detail SBOM and provenance metadata, update spell checker configuration to ignore new security-related terms, and add documentation for testing max-mode attestations locally. Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant GitHub
participant GitHub Actions
participant Docker Buildx
participant Docker Scout
Developer->>GitHub: Create/Update PR (Dockerfile or workflow changed)
GitHub->>GitHub Actions: Trigger scout-pr.yml workflow
GitHub Actions->>Docker Buildx: Build Docker image with SBOM & provenance (max mode)
Docker Buildx-->>GitHub Actions: Image with attestations (local)
GitHub Actions->>Docker Scout: Scan image for CVEs, compare with production
Docker Scout-->>GitHub Actions: Scan results, SARIF report
GitHub Actions->>GitHub: Upload SARIF to Security tab, comment on PR
sequenceDiagram
participant GitHub Actions
participant Docker Buildx
participant Registry
GitHub Actions->>Docker Buildx: Build and push image with sbom: mode=max, provenance: mode=max
Docker Buildx->>Registry: Push image and attestations
Registry-->>GitHub Actions: Image and metadata stored
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (1).github/workflows/scout-pr.yml (1)🪛 YAMLlint (1.37.1).github/workflows/scout-pr.yml[warning] 3-3: truthy value should be one of [false, true] (truthy) [error] 5-5: too many spaces inside brackets (brackets) [error] 5-5: too many spaces inside brackets (brackets) [warning] 88-88: too few spaces before comment: expected 2 (comments) Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
.github/workflows/build-container.yml(1 hunks).github/workflows/docker-publish.yml(2 hunks).github/workflows/scout-pr.yml(1 hunks)CONTRIBUTING.md(1 hunks)cspell.json(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.37.1)
.github/workflows/scout-pr.yml
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
[error] 5-5: too many spaces inside brackets
(brackets)
[error] 5-5: too many spaces inside brackets
(brackets)
🔇 Additional comments (2)
.github/workflows/build-container.yml (1)
36-37: Verify thatmode=maxis supported bydocker/build-push-action@v6
Although v6’s action.yml definessbomandprovenanceinputs, it doesn’t list valid mode values. Ensure that usingmode=maxactually takes effect—otherwise these options will default or be ignored. You can:
- Review the v6 tag’s action.yml on GitHub to see if
mode=maxis accepted.- Run a quick test workflow with
sbom: mode=maxandprovenance: mode=maxand confirm SBOM/provenance artifacts are generated.Affected location:
- .github/workflows/build-container.yml (lines 36–37)
sbom: mode=max provenance: mode=maxcspell.json (1)
26-28: Dictionary update looks good.
Adding “sarif” and “cves” prevents needless spell-check noise.
…gistry, and scan for CVEs against the latest baseline
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
.github/workflows/scout-pr.yml (2)
5-5: Bracket spacing still violates YAML-lint – same comment as before.
Replace[ main ]with[main]or multi-line list.
41-41: Action version drift (v5vsv6) is still present.
Standardise on the same major (v6) as the other workflows to avoid subtle behaviour differences.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/scout-pr.yml(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.37.1)
.github/workflows/scout-pr.yml
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
[error] 5-5: too many spaces inside brackets
(brackets)
[error] 5-5: too many spaces inside brackets
(brackets)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: scout
…al network access
…add 'buildkit' to cspell ignore words
🔍 Vulnerabilities of
|
| digest | sha256:3d3828ef7deefd75087e5f0472348543dfb3cb01d3459633fa0923db0ddd375b |
| vulnerabilities |     |
| platform | linux/amd64 |
| size | 412 MB |
| packages | 1104 |
📦 Base Image ubuntu:24.04
| also known as |
|
| digest | sha256:4f1db91d9560cf107b5832c0761364ec64f46777aa4ec637cca3008f287c975e |
| vulnerabilities |   |
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (4)
.github/workflows/scout-pr.yml (4)
3-3: Quoteonto keep YAML-lint quiet.
Unquotedonis interpreted as a boolean by YAML 1.1 linters. Wrap the key in quotes ("on":) to avoid warnings.
5-5: Remove spaces inside the branch filter list.
[ main ]trips YAML-lint (“too many spaces inside brackets”). Use[main]or a multi-line list.
44-48: Guarddocker tag/push– they run even when the pull failed.If
:latestdoesn’t exist, the pull is swallowed by|| true, but the subsequent tag & push still execute and error out, breaking the job.- docker pull ${{ env.IMAGE_NAME }}:latest || true - docker tag ${{ env.IMAGE_NAME }}:latest 127.0.0.1:5000/${{ env.IMAGE_NAME }}:latest - docker push 127.0.0.1:5000/${{ env.IMAGE_NAME }}:latest +if docker pull ${{ env.IMAGE_NAME }}:latest 2>/dev/null; then + docker tag ${{ env.IMAGE_NAME }}:latest 127.0.0.1:5000/${{ env.IMAGE_NAME }}:latest + docker push 127.0.0.1:5000/${{ env.IMAGE_NAME }}:latest +else + echo "::notice title=Scout:: No :latest image found – skipping baseline seed" +fi
51-51: Standardise ondocker/build-push-action@v6.
Other workflows pin v6; keeping a mix (v5 here) can cause subtle behaviour differences (e.g. attestation flags). Bump to v6.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/scout-pr.yml(1 hunks)cspell.json(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
.github/workflows/scout-pr.yml (1)
Learnt from: johlju
PR: viscalyx/devshell-dsc#8
File: .github/workflows/docker-publish.yml:48-55
Timestamp: 2025-07-18T19:18:04.454Z
Learning: GitHub Actions does not support using secrets directly in `if:` conditions for security reasons. The correct approach is to assign the secret to an environment variable at the job level and then reference the environment variable in the condition (e.g., `env.GH_READ_TOKEN != ''` instead of `secrets.GH_READ_TOKEN != ''`).
🪛 YAMLlint (1.37.1)
.github/workflows/scout-pr.yml
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
[error] 5-5: too many spaces inside brackets
(brackets)
[error] 5-5: too many spaces inside brackets
(brackets)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: scout
🔇 Additional comments (1)
cspell.json (1)
26-29: Dictionary update looks good.
Adding “sarif”, “cves”, and “buildkit” prevents false positives from the new security-scanning workflow.
…ogin and image management
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (3)
.github/workflows/scout-pr.yml (3)
42-44: Action version still inconsistent with the rest of the repo.
Other workflows usedocker/build-push-action@v6; keeping@v5here can cause subtle attestation path differences.
54-55:sbom: mode=maxis not a valid value for v5 – job will error out.
Replace withsbom: true(orfile=…) as suggested earlier.
3-5: Fix YAML-lint defects (onkey + branch list).
Unquotedonis parsed as boolean in YAML 1.1 and the extra spaces inside[ main ]violate the brackets rule, tripping most linters.-3 on: +3 "on": -5 branches: [ main ] +5 branches: [main] # or use the multi-line list form
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/scout-pr.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
.github/workflows/scout-pr.yml (1)
Learnt from: johlju
PR: viscalyx/devshell-dsc#8
File: .github/workflows/docker-publish.yml:48-55
Timestamp: 2025-07-18T19:18:04.454Z
Learning: GitHub Actions does not support using secrets directly in `if:` conditions for security reasons. The correct approach is to assign the secret to an environment variable at the job level and then reference the environment variable in the condition (e.g., `env.GH_READ_TOKEN != ''` instead of `secrets.GH_READ_TOKEN != ''`).
🪛 YAMLlint (1.37.1)
.github/workflows/scout-pr.yml
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
[error] 5-5: too many spaces inside brackets
(brackets)
[error] 5-5: too many spaces inside brackets
(brackets)
…nst Docker Hub baseline
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
.github/workflows/docker-publish.yml (1)
76-78: Unify the secret-injection pattern to avoid empty-string edge cases.
The branch-image step injects the secret unconditionally:secrets: | gh_read_token=${{ secrets.GH_READ_TOKEN }}If a contributor’s fork lacks
GH_READ_TOKEN, the step will still run (because the job-levelifallows it) and thesecretsinput receives the literal stringgh_read_token=which makes BuildKit complain with “invalid value for secrets: expected id=value”. Use the guarded format already applied in the tag-image step:- secrets: | - gh_read_token=${{ secrets.GH_READ_TOKEN }} + secrets: | # inject read token + ${{ env.GH_READ_TOKEN != '' && format('gh_read_token={0}', env.GH_READ_TOKEN) }}This keeps both steps consistent and prevents no-secret failures on forks.
♻️ Duplicate comments (2)
.github/workflows/scout-pr.yml (2)
3-6: Quoteonkey & fix bracket spacing (YAML-lint).
Both issues were flagged previously and are still present.-"on": - pull_request: - branches: [ main ] +\"on\": + pull_request: + branches: [main]
34-47: Guard registry logins so forks don’t hard-fail.
Wrap each login step in anif:that checks the corresponding env vars, and move secrets intoenv:before referencing them, mirroring the pattern used elsewhere.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/build-container.yml(1 hunks).github/workflows/docker-publish.yml(2 hunks).github/workflows/scout-pr.yml(1 hunks)CONTRIBUTING.md(2 hunks)
🧰 Additional context used
🧠 Learnings (3)
.github/workflows/build-container.yml (1)
Learnt from: johlju
PR: viscalyx/devshell-dsc#8
File: .github/workflows/docker-publish.yml:48-55
Timestamp: 2025-07-18T19:18:04.454Z
Learning: GitHub Actions does not support using secrets directly in `if:` conditions for security reasons. The correct approach is to assign the secret to an environment variable at the job level and then reference the environment variable in the condition (e.g., `env.GH_READ_TOKEN != ''` instead of `secrets.GH_READ_TOKEN != ''`).
.github/workflows/docker-publish.yml (1)
Learnt from: johlju
PR: viscalyx/devshell-dsc#8
File: .github/workflows/docker-publish.yml:48-55
Timestamp: 2025-07-18T19:18:04.454Z
Learning: GitHub Actions does not support using secrets directly in `if:` conditions for security reasons. The correct approach is to assign the secret to an environment variable at the job level and then reference the environment variable in the condition (e.g., `env.GH_READ_TOKEN != ''` instead of `secrets.GH_READ_TOKEN != ''`).
.github/workflows/scout-pr.yml (1)
Learnt from: johlju
PR: viscalyx/devshell-dsc#8
File: .github/workflows/docker-publish.yml:48-55
Timestamp: 2025-07-18T19:18:04.454Z
Learning: GitHub Actions does not support using secrets directly in `if:` conditions for security reasons. The correct approach is to assign the secret to an environment variable at the job level and then reference the environment variable in the condition (e.g., `env.GH_READ_TOKEN != ''` instead of `secrets.GH_READ_TOKEN != ''`).
🪛 LanguageTool
CONTRIBUTING.md
[grammar] ~85-~85: Use correct spacing
Context: ...v ``` ## Testing Max-Mode Attestations Locally Max-mode attestations are automatically ...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~87-~87: Use correct spacing
Context: ...ion or troubleshoot attestation-related issues. ### Prerequisites for Local Attestation Test...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~89-~89: Use correct spacing
Context: ...### Prerequisites for Local Attestation Testing - Docker BuildKit enabled (automatically e...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~92-~92: Use correct spacing
Context: ...- Docker Scout CLI (optional, for local scanning) ### Building with Max-Mode Attestations To ...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~94-~94: Use correct spacing
Context: ...l scanning) ### Building with Max-Mode Attestations To build locally with the same attestati...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~96-~96: There might be a mistake here.
Context: ...h the same attestation settings used in production: sh # Basic build with max-mode attestations DOCKER_BUILDKIT=1 docker build \ --sbom=mode=max \ --provenance=mode=max \ -t devshell:dsc . sh # No-cache build with max-mode attestations DOCKER_BUILDKIT=1 docker build \ --no-cache \ --sbom=mode=max \ --provenance=mode=max \ -t devshell:dsc . ### Testing with Docker Sc...
(QB_NEW_EN_OTHER)
[grammar] ~115-~115: Use correct spacing
Context: ...sc . ``` ### Testing with Docker Scout Locally If you have Docker Scout CLI installed, ...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~117-~117: There might be a mistake here.
Context: ...led, you can test the security scanning locally: sh # Build with attestations DOCKER_BUILDKIT=1 docker build \ --sbom=mode=max \ --provenance=mode=max \ -t devshell:dsc . # Scan for vulnerabilities docker scout cves devshell:dsc # Compare with latest published image (requires Docker Hub access) docker scout compare devshell:dsc --to viscalyx/devshell-dsc:latest > [!NOTE] > Max-mode attest...
(QB_NEW_EN_OTHER)
[grammar] ~134-~134: There might be a mistake here.
Context: ...age overhead. They are primarily useful for: > > - Testing the full CI/CD security pipelin...
(QB_NEW_EN_OTHER)
[grammar] ~138-~138: Use correct spacing
Context: ...Docker Scout integration before pushing changes > > For regular development and testing, the...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~140-~140: Use correct spacing
Context: ...build commands without attestations are sufficient. ## Publishing Publishing happens automatic...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
🪛 YAMLlint (1.37.1)
.github/workflows/scout-pr.yml
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
[error] 5-5: too many spaces inside brackets
(brackets)
[error] 5-5: too many spaces inside brackets
(brackets)
🔇 Additional comments (3)
CONTRIBUTING.md (2)
58-60: BuildKit note looks good – resolves the earlier feedback.
The wording is concise, calls out Docker Desktop defaults, and links to the official docs.
👍 No further action required.
85-140: Tighten up Markdown spacing & fix LanguageTool nags.
Several headings/paragraphs in the new “Testing Max-Mode Attestations” section are missing the blank line that should follow a heading, which triggers the LanguageTool spacing warnings. Adding a single blank line after each heading keeps the Markdown spec-compliant and silences the linter.-## Testing Max-Mode Attestations Locally -Max-mode attestations are automatically enabled ... +## Testing Max-Mode Attestations Locally + +Max-mode attestations are automatically enabled ... @@ -### Prerequisites for Local Attestation Testing -- Docker BuildKit enabled ... +### Prerequisites for Local Attestation Testing + +- Docker BuildKit enabled ...(The same pattern repeats for the subsequent
###headings.)Likely an incorrect or invalid review comment.
.github/workflows/build-container.yml (1)
35-38: Good use of guardedsecrets:block and max-mode flags.
The conditional formatting prevents empty secret values and the v6 action fully supportssbom: mode=max/provenance: mode=max.
| tags: | | ||
| ghcr.io/${{ github.repository }}:${{ env.TAG }} | ||
| sbom: mode=max # max-mode SBOM for Scout | ||
| provenance: mode=max # max-mode provenance for Scout | ||
| push: true # push both tags to GHCR | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Comment/tag mismatch – clarify which tags are pushed.
The step comment says “push both tags to GHCR” but only one tag (pr-<nr>) is listed. Either add the second tag (e.g. :latest-pr) or update the comment to avoid confusion.
🤖 Prompt for AI Agents
In .github/workflows/scout-pr.yml around lines 60 to 65, the comment states that
both tags are pushed to GHCR, but only one tag is specified in the tags field.
To fix this, either add the second tag (such as :latest-pr) to the tags list so
both tags are pushed, or update the comment to accurately reflect that only one
tag is being pushed to avoid confusion.
Recommended fixes for image
|
| Name | 24.04 |
| Digest | sha256:4f1db91d9560cf107b5832c0761364ec64f46777aa4ec637cca3008f287c975e |
| Vulnerabilities | |
| Pushed | 5 days ago |
| Size | 30 MB |
| Packages | 131 |
| OS | 24.04 |
The base image is also available under the supported tag(s):latest,noble,noble-20250714
Refresh base image
Rebuild the image using a newer base image version. Updating this may result in breaking changes.✅ This image version is up to date.
Change base image
| Tag | Details | Pushed | Vulnerabilities |
|---|---|---|---|
25.04Major OS version update Also known as:
|
Benefits:
|
5 days ago |  |
25.10Major OS version update Also known as:
|
Benefits:
|
4 weeks ago |   |
|
Fails on compare: |
This change is