Professional Cloud DevOps Engineer

Artifact Analysis and Vulnerability Scanning

Artifact Analysis and vulnerability scanning work together to catch security issues before they reach production. In a typical pipeline, a build process produces a container image and pushes it to Artifact Registry. The registry automatically triggers a vulnerability scan, often powered by Container Analysis, which compares the image’s packages against known vulnerability databases. The scan produces a list of vulnerabilities with severity levels (e.g., CRITICAL, HIGH) and metadata such as the Common Vulnerabilities and Exposures (CVE) identifier.

The scan results feed directly into deployment policies. For example, Binary Authorization can be configured to block any deployment that uses an image containing a CRITICAL vulnerability. This creates a hard boundary: the image cannot be promoted to a production environment until the vulnerability is fixed or a waiver is approved. The relationship is sequential—the scan runs after the image is built but before it is deployed, and the policy engine reads the scan result to make a decision. Teams can also set up notifications (e.g., Pub/Sub) to alert security engineers when a new vulnerability is discovered in an already-deployed image, enabling a remediation pipeline that triggers a rebuild.

Software Supply Chain Security (e.g., Binary Authorization, SLSA Framework)

Software supply chain security focuses on ensuring that every artifact in the pipeline comes from a trusted source and has not been tampered with. Binary Authorization is a GCP service that enforces deployment-time policies. It requires that each container image carry a signed attestation from an approved attestor before it can be deployed to a GKE cluster or Cloud Run. The attestor is a trusted entity that verifies the image was built from a known pipeline and passed required checks (e.g., vulnerability scan, unit tests). The policy is set at the project level and can be scoped to specific clusters or environments.

The SLSA (Supply-chain Levels for Software Artifacts) framework provides a maturity model for supply chain integrity, with levels from SLSA 1 (basic provenance) to SLSA 4 (fully hardened). Binary Authorization can enforce SLSA requirements by requiring attestations that include provenance metadata (e.g., the build platform, source repository, build script hash). The flow is: a CI system builds the image, generates a provenance statement, signs it with a key, and stores the attestation in Container Analysis. During deployment, Binary Authorization verifies the attestation against the policy. This chain of trust ensures that only artifacts that meet the organization’s security bar can move from build to production.

IAM Policies Based on Environment

Securing the deployment pipeline requires different IAM policies for each environment (e.g., development, staging, production) to enforce least privilege. The typical approach is to use separate GCP projects for each environment, or at minimum separate service accounts and roles. A CI/CD system, such as Cloud Build, uses a service account to perform deployments. That service account should have different permissions per environment: in development it may have broad access to create and modify resources, while in production it should only be allowed to deploy approved images and update a limited set of resources.

The relationship between environments is one of escalation. A developer’s personal credentials might have access to development but not production. The deployment pipeline itself uses a deployment service account that is granted the roles/container.developer or similar role only in the target environment. To prevent a compromised pipeline from affecting production, the production project’s IAM policy should explicitly deny direct access from the CI/CD service account unless the request carries a valid attestation (e.g., from Binary Authorization). Additionally, IAM conditions can be used to restrict access based on attributes such as IP address, time of day, or the presence of a specific tag on the artifact. This layered approach ensures that even if a developer’s credentials are stolen, the attacker cannot bypass the environment-specific policies to reach production.