Your organization is designing a multi-project CI/CD security architecture using Artifact Registry and Artifact Analysis. You maintain a centralized security-metadata-prod project (acting as the metadata provider) to store compliance and attestation notes, while multiple application team projects host Artifact Registry repositories (acting as metadata customers) where container images are built and stored. You need to configure Identity and Access Management (IAM) roles and security controls to meet the following requirements: CI/CD service accounts running in the application projects must be able to generate metadata occurrences for container images and attach them to the centralized notes in security-metadata-prod. Central security compliance auditors must be able to list all occurrences across every customer project that are attached to a specific note in security-metadata-prod. Application developers with repository access in customer projects must be strictly prevented from tampering with or deleting automated vulnerability metadata generated by Artifact Analysis. Which IAM role configuration and security mechanism should you implement?

Grant CI/CD service accounts the Container Analysis Occurrences Editor role in application projects and the Container Analysis Notes Attacher role in `security-metadata-prod`. Grant compliance auditors the Container Analysis Occurrences for Notes Viewer role in `security-metadata-prod`. Rely on the built-in Artifact Analysis security model that blocks customer write permissions to third-party vulnerability provider occurrences.: ### What the Provider-Customer Metadata Model Is The **Artifact Analysis metadata model** distinguishes between **metadata providers** (which create and manage centralized `notes` describing policies, vulnerabilities, or build attestations) and **metadata customers** (which attach `occurrences` targeting specific container images to those notes). In an enterprise CI/CD architecture, isolating notes into a dedicated provider project ensures centralized governance across distributed application repositories. ### How It Meets the Requirements - **Occurrences creation and attachment:** CI/CD service accounts require **`roles/containeranalysis.occurrences.editor`** (**Container Analysis Occurrences Editor**) granted in the **customer project** to instantiate new occurrences targeting container images, and **`roles/containeranalysis.notes.attacher`** (**Container Analysis Notes Attacher**) granted in the **provider project** (`security-metadata-prod`) to bind those occurrences to the centralized note. - **Central audit visibility:** Granting security auditors **`roles/containeranalysis.occurrencesForNotes.viewer`** (**Container Analysis Occurrences for Notes Viewer**) in the provider project allows them to retrieve and list all attached occurrences across all external customer projects linked to a given note. - **Preventing tampering of vulnerability scans:** Artifact Analysis enforces an inherent authorization boundary for vulnerability data. Automated vulnerability scan metadata created by third-party providers cannot be edited or deleted by customer project principals, even if they possess occurrence editing permissions for their own custom occurrences in the customer project. ### Key Advantages - **Principle of least privilege:** Service accounts only receive attachment privileges in the centralized metadata project without gaining permission to create or alter notes. - **Centralized auditability:** Security teams query the central note to inspect global compliance across all microservices. - **Tamper-resistant scanning:** Prevents developers from masking or removing vulnerability findings. ### Why This Is Optimal This solution uses native Google Cloud IAM role mappings and built-in Artifact Analysis security protections without requiring custom IAM policies or complex manual perimeter synchronizations.