Skip to content

fix: validate project_id when creating CAS mappings - #3359

Open
migmartri wants to merge 2 commits into
chainloop-dev:mainfrom
migmartri:fix/validate-cas-mapping-project-id
Open

fix: validate project_id when creating CAS mappings#3359
migmartri wants to merge 2 commits into
chainloop-dev:mainfrom
migmartri:fix/validate-cas-mapping-project-id

Conversation

@migmartri

@migmartri migmartri commented Aug 19, 2026

Copy link
Copy Markdown
Member

Closes #3358

cas_mappings.project_id is not enforced at the database level, so CASMappingRepo.Create accepted any UUID — including a project_versions.id, which has been observed in real data. A mapping carrying such a value never matches the organization_id = <org> AND project_id IN (<visible project ids>) predicate used to resolve downloads, so the artifact is unreachable for roles with project RBAC enabled while org owners and admins can still download it.

Create now validates that the referenced project exists and belongs to the CAS backend's organization, so a bad write fails at creation time rather than producing a mapping only some roles can read. This mirrors the existing validation of the other database-unenforced reference on the same write, workflow_run_id.

The check is deliberately at the application level rather than a foreign key: it is a single indexed lookup on a path that already resolves the CAS backend and validates the workflow run, and it avoids a table-wide constraint on a high-volume write path.

The download lookup also logs the visible project IDs when a digest is not accessible, which is the information needed to tell an RBAC filter miss apart from a genuinely absent mapping.

Repairing existing rows and correcting writers that pass a project version ID are out of scope.

AI assistance: implemented with Claude Code.

Review in cubic

cas_mappings.project_id is not enforced at the database level, so
CASMappingRepo.Create accepted any UUID, including a project version ID.
Such a mapping never matches the project-scoped predicate used to resolve
downloads, making the artifact unreachable for roles with RBAC enabled
while remaining downloadable for org owners and admins.

The referenced project must now exist and belong to the CAS backend's
organization, so a bad write fails at creation time.

Assisted-by: Claude Code
Signed-off-by: Miguel Martinez <miguel@chainloop.dev>

Chainloop-Trace-Sessions: e19606bd-40e5-400d-a907-29de5fd17b1a
@chainloop-platform

chainloop-platform Bot commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Security Checks — ✅ 2 passing

PR info

Status Policy Messages
✅ Passed pr-description-required -
✅ Passed pr-user-story-linked -

⏭️ 3 scans not applied

Scan Reason
vulnerability-scan no manifest/lockfile changed
github-actions-scan no workflow files changed
iac-scan no IaC files changed

View attestation ↗


Powered by Chainloop and Chainloop Trace

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All reported issues were addressed across 3 files

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

Comment thread app/controlplane/pkg/data/casmapping.go
A project row that is no longer live is not a valid target for a new
mapping, and is not guaranteed to be reachable by project-filtered
downloads. Align the check with the rest of the project lookups in the
data layer, which all filter on deleted_at.

Assisted-by: Claude Code
Signed-off-by: Miguel Martinez <miguel@chainloop.dev>

Chainloop-Trace-Sessions: e19606bd-40e5-400d-a907-29de5fd17b1a
@migmartri
migmartri requested a review from a team August 19, 2026 16:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CAS mapping creation does not validate project_id, producing mappings unreachable under project RBAC

2 participants