Repository navigation
feat(setup): capture verified security image identity - #351
Conversation
Reviewer's GuideSetup now scaffolds security matrices only from the canonical template and optionally populates them with per-version/component container image identity. It resolves release tags to full commits, verifies published OCI revision labels before accepting image rows, preserves dynamic repository and ecosystem mappings, and requires review before writing; documentation and Setup evals define and exercise the updated contract. Sequence diagram for verified security matrix populationsequenceDiagram
participant Setup
participant ReleaseRepo
participant Registry
participant User
participant Matrix
Setup->>ReleaseRepo: Read release tags/history
ReleaseRepo-->>Setup: Versions, builds, source commits, pinning methods
Setup->>Registry: Resolve image reference and inspect revision label
Registry-->>Setup: Image digest, CPE, org.opencontainers.image.revision
Setup->>Setup: Compare revision label with resolved release commit SHA
alt Evidence missing or mismatched
Setup-->>User: Ask for corrected evidence
Setup-->>Matrix: Leave matrix unchanged
else Evidence verified
Setup-->>User: Present complete proposed matrix and revision checks
User->>Setup: Confirm review
Setup->>Matrix: Write matrix and Last-Updated timestamp
end
Entity relationship diagram for container image identityerDiagram
PRODUCT_VERSION ||--o{ CONTAINER_IMAGE : has
CONTAINER_IMAGE {
string product_version
string component
string release_tag
string resolved_release_commit_sha
string image_reference
string image_digest
string cpe
string revision_label
}
RELEASE_TAG ||--|| CONTAINER_IMAGE : resolves_to
RELEASE_TAG {
string tag
string commit_sha
}
CONTAINER_IMAGE }o--|| SOURCE_REPOSITORY : supports
SOURCE_REPOSITORY {
string repository
string source_pinning_method
}
Flow diagram for canonical security matrix scaffoldingflowchart TD
A[Configured security-matrix.md path] --> B{Matrix exists?}
B -->|Yes| C[Report existing matrix and skip]
B -->|No| D[Read security-matrix.template.md]
D --> E[Expand source repository columns and pinning entries]
E --> F[Retain ecosystem mappings]
F --> G[Offer scaffold for confirmation]
G --> H[Write confirmed scaffold]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 4 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="plugins/sdlc-workflow/skills/setup/SKILL.md" line_range="560" />
<code_context>
+| 1.94 | `setup` MUST preserve one Supportability Matrix source-commit column and one Source Pinning Method entry per configured Source Repositories entry, and preserve Ecosystem Mappings; it MUST present the complete proposed matrix for review before writing and leave it unchanged while image evidence is missing or mismatched. | `setup/SKILL.md` — Steps 10.5–10.6 |
### Prior Art — Cross-phase integrity (§1.33–1.35)
</code_context>
<issue_to_address>
**Concurrent matrix edits get overwritten**
When the target matrix changes after Setup checks or reads it but before Setup writes after confirmation, setup writes a scaffold over a matrix created after its existence check, or writes its proposed matrix over changes made after its earlier read. A concurrent triage-security population or another Setup run therefore loses its newer matrix contents.
Re-read and compare the target immediately before writing, use create-if-absent for scaffolds, and merge or abort if the target changed.
Also at `plugins/sdlc-workflow/skills/setup/SKILL.md:597-600`.
</issue_to_address>
### Comment 2
<location path="plugins/sdlc-workflow/skills/setup/SKILL.md" line_range="580-581" />
<code_context>
+> "Would you like me to populate the Supportability Matrix and Container Images table
+> from release history and published-image evidence?"
If the user declines, skip to Step 11. The matrix can be populated later on demand
by `/triage-security` during CVE investigation.
If the user accepts, for each Version Stream:
</code_context>
<issue_to_address>
**Image identity evidence stays incomplete**
When triage-security is relied on to populate an empty or incomplete matrix after Setup population is declined, `triage-security` writes legacy supportability data without Container Images rows or revision-label checks, so the matrix appears populated while lacking verified image identity evidence.
Update on-demand population to add Container Images rows and verify revision labels against release SHAs before writing the matrix.
Also at `plugins/sdlc-workflow/skills/setup/SKILL.md:590-592`.
</issue_to_address>
### Comment 3
<location path="plugins/sdlc-workflow/skills/setup/SKILL.md" line_range="566" />
<code_context>
- to write it to the configured path in the project directory. The user must confirm each file.
-- **If it DOES exist**: Report "security-matrix.md already exists at <path> — skipping."
+- **If it exists**: Report "security-matrix.md already exists at <path> — skipping."
+- **If missing**: Scaffold only from the plugin-root
+ `docs/templates/security-matrix.template.md`; `docs/templates/security-matrix.md` is a
+ worked example. Expand `{source-repo-name}` / `{source-ref}` and matching separator
</code_context>
<issue_to_address>
**Other products get an RHTPA header**
When the configured product is not RHTPA, setup now scaffolds from the canonical template, whose Supportability Matrix header is hard-coded as `RHTPA Version`; projects for other products therefore receive a matrix that labels their versions as RHTPA versions.
Use a product-neutral `Version` header or make the product name a scaffold placeholder.
</issue_to_address>
### Comment 4
<location path="evals/setup/files/security-matrix-image-identity.md" line_range="35-36" />
<code_context>
+
+| Product Version | Component | Image Reference | Immutable Image Digest | CPE | `org.opencontainers.image.revision` |
+|---|---|---|---|---|---|
+| 2.1.0 | api-rhel9 | `registry.example.test/trustify/api:2.1.0-rhel9` | `sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` | `cpe:2.3:a:example:trustify_api:2.1.0:*:*:*:*:*:*:*` | `0123456789abcdef0123456789abcdef01234567` |
+| 2.1.0 | api-rhel10 | `registry.example.test/trustify/api:2.1.0-rhel10` | `sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb` | `cpe:2.3:a:example:trustify_api:2.1.0:*:*:*:*:*:*:*` | `0123456789abcdef0123456789abcdef01234567` |
+| 2.1.1 | api-rhel10 | `registry.example.test/trustify/api:2.1.1-rhel10` | `sha256:cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc` | `cpe:2.3:a:example:trustify_api:2.1.1:*:*:*:*:*:*:*` | `fedcba9876543210fedcba9876543210fedcba98` |
</code_context>
<issue_to_address>
**Duplicate CPEs contradict eval**
When the grader interprets “distinct … CPE values” as requiring different CPEs for the two platform rows, when the grader requires distinct CPEs for the two platform rows, Setup eval 7’s assertion at `evals/setup/evals.json:116` fails even when Setup correctly preserves its input: the `api-rhel9` and `api-rhel10` fixture rows have the same CPE. Changing the output to satisfy the assertion would instead make it inaccurate.
Give the platform rows distinct CPEs in the fixture, or clarify that only image references and digests must be distinct.
</issue_to_address>Sourcery assessment
Needs a human reviewer. 4 findings to address first, and if Setup records an incorrect release commit, image digest, or source pin in the security matrix, later CVE triage could associate evidence with the wrong product image and produce an inaccurate impact assessment. The matrix is a persisted but editable record, so correcting it can repair the mapping; reverting the skill change alone would not undo rows already written.
Blocking findings: plugins/sdlc-workflow/skills/setup/SKILL.md:560, plugins/sdlc-workflow/skills/setup/SKILL.md:581, plugins/sdlc-workflow/skills/setup/SKILL.md:566, evals/setup/files/security-matrix-image-identity.md:36
|
[sdlc-workflow/verify-pr] Re: @sourcery-ai[bot] review — Classified as code change request for each of the four distinct requests: protect concurrent matrix writes (TC-7145); add image identity checks to triage-security on-demand population (TC-7143); make the shared-template version header product-neutral (TC-7144); clarify CPE uniqueness expectations in the eval (TC-7142). The review-body items duplicate the corresponding inline findings. |
Verification Report for TC-7136 (commit 2dde9e4)
Overall: FAILThe direct acceptance criteria are met, but the required Setup eval suite has one failing assertion. The review fixes are tracked in TC-7142–TC-7145. Jira also has a This comment was AI-generated by sdlc-workflow/verify-pr v0.13.10. |
Eval ResultsSource head: 4b0faf5 Eval Results: setup
Pass rate: 100% · Tokens: 76,967 · Duration: 36s Baseline ( Generated by sdlc-workflow/run-evals v0.13.10 Eval Results: triage-security
Pass rate: 100% · Tokens: 126,654 · Duration: 63s Baseline ( Generated by sdlc-workflow/run-evals v0.13.10 |
Implements TC-7136 Assisted-by: Claude Code
Implements TC-7136 Assisted-by: Claude Code
Clarify that image references and digests distinguish platform images while a valid product-version CPE may be shared. Implements TC-7142 Assisted-by: Claude Code
Add component-keyed image rows to interactive on-demand matrix updates and block writes while revision evidence is unresolved. Add valid/mismatch eval coverage. Implements TC-7143 Assisted-by: Claude Code
Update the canonical template and add eval coverage for non-RHTPA projects. Implements TC-7144 Assisted-by: Claude Code
Recheck matrix snapshots before writing, create scaffolds only if absent, and require renewed review or abort when targets change. Implements TC-7145 Assisted-by: Claude Code
Apply final snapshot checks to fallback saves and format repairs, and trigger completion for missing component rows. Implements TC-7145 Assisted-by: Claude Code
There was a problem hiding this comment.
Native Fullsend Eval Results
Head: 4b0faf5
Merge: b48b31e
Trusted workflow: e1c811c
Reviewed eval source: e1c811c
Native job: success; complete: true.
Execution evidence: valid; quality score (advisory): 27/28 passed.
| Case | Execution evidence | Quality score (advisory) |
|---|---|---|
| 033-absent | valid | 4/4 |
| 034-empty | valid | 5/5 |
| 035-malformed | valid | 4/5 |
| 036-valid | valid | 7/7 |
| 037-release | valid | 7/7 |
|
🤖 Finished Verify Pr · ✅ Success · Started 3:49 PM UTC · Completed 4:00 PM UTC Commit: Runtime: claude · Model: claude-opus-4-8 · Effort: high · Cost: $6.17 |
Verification Report for TC-7136 (commit 4b0faf5)
Overall: WARNThe direct acceptance criteria (5/5) are met and CI is green at head 4b0faf5: all check-runs pass or skip, the
This was an idempotent re-run at a new commit: all sub-tasks (TC-7142-TC-7145), classification replies, and root-cause Tasks (TC-7146-TC-7148) already existed, so no new Jira or PR writes were made - only this per-commit report was refreshed. Note (unchanged from the prior verification): Jira has a This comment was AI-generated by sdlc-workflow/verify-pr v0.13.10. |
Summary
docs/templates/security-matrix.template.mdas the sole scaffold and turn its sibling.mdfile into a worked example.Implements TC-7136
Evidence
uvx skillsaw: 0 errors (9 warnings).claude plugin validate plugins/sdlc-workflow: passed (existing missing-icon warning).Merge Danger
Door: Two-way
Blast Radius: Workflow
The change affects Setup and triage-security instructions, matrix templates, constraints, and evaluations; it does not modify customer project matrices.
Summary by Sourcery
Require verified container image identity and review-gated, concurrency-safe security matrix updates across Setup and triage-security.
New Features:
Bug Fixes:
Enhancements:
Documentation:
Tests:
Chores: