Module 4: Enforce Policy and Promote Safely

In this step, you will configure ACS to scan images stored in Quay and validate that vulnerability data can be evaluated as part of the trusted supply chain.

You will use the ACS API to create the integration programmatically, mirroring how platform teams automate integration setup in production environments.

In the Showroom terminal, run the following command to create the Quay integration:

curl -k -X POST \
  -u "{rhacs_admin_user}:{rhacs_admin_password}" \
  -H "Content-Type: application/json" \
  {rhacs_admin_console}/v1/imageintegrations \
  -d '{
    "name": "acs_quay",
    "type": "quay",
    "categories": ["REGISTRY", "SCANNER"],
    "quay": {
      "endpoint": "{quay_host}",
      "oauthToken": "{quay_admin_token}",
      "insecure": true
    },
    "skipTestIntegration": false
  }'

This command creates a new image integration in ACS with the following configuration:

Upon successful execution, you will receive a JSON response confirming the integration has been created and tested.

At this point, ACS can securely access images stored in Quay and perform scans automatically.

To confirm that scanning and policy evaluation are working end to end, you will now scan the signed image you produced in module 2.

This next command retrieves vulnerability data for the image and returns a detailed scan report.

In the Showroom terminal, run:

This command evaluates the image against ACS policies and reports whether it meets deployment requirements.

Together, these checks demonstrate that:

This ensures that vulnerability scanning and policy evaluation are applied consistently across all workloads, as an integrated part of the delivery pipeline exposed through our Software Template.

Up to this point, you’ve been working in the role of a platform engineer.

Now let’s switch personas and step into the role of a developer (User1), which you created earlier.

As a developer, your goal is simple, get a ready-to-use development environment so you can focus on building your new feature.

This is exactly what Software Templates, or Golden Paths, are designed to provide.

Under the hood, they use the Backstage scaffolder to automate the creation of repositories, configuration, and CI/CD resources based on platform-approved patterns, as you’ll see in the next section.

You will be guided through a four-step, wizard-style form to collect the required inputs.

Instead of raising tickets and waiting for manual setup, this workflow applies platform standards automatically, as defined by the template.

In the first form, you are prompted to enter application-specific parameters.

Default values are already provided by the template, so keep the defaults and click Next.

The second form provides container image registry details.

In this workshop, container images are pushed to Quay.io.

The required values are pre-filled, so click Next to continue.

In the third form, you configure the source code repository, which is GitLab in this environment.

Click Review to proceed.

You will now see a summary of all the parameters that will be passed to the scaffolder when executing the template steps.

These values are used to:

Review the values, then click Create to start the scaffolding process.

After a short time, the scaffolder workflow will complete and you will see a confirmation screen with green checkmarks indicating each step has succeeded.

Click Open Component in Catalog to view your newly created application in the Developer Hub.

Before committing any code, verify that Git commit signing is correctly configured in your OpenShift Dev Spaces workspace.

The development environment has already been configured to use gitsign based on the configuration applied earlier in the Devfile.

To see code signing in action, you will apply a simple change by adding a comment to the documentation.

The first task executed after the Git repository is cloned is to verify that the code change you just committed was made by a trusted identity.

This task succeeds only if the pipeline can validate the signature on the commit that triggered the run. This is the signature you created using gitsign when you committed the change from OpenShift Dev Spaces.

Click on the verify-commit task to view the logs.

In the output, you can see that the commit signature you created earlier has been successfully validated. The log confirms a good signature from user1, along with successful verification of the Fulcio certificate, Rekor transparency entry, and certificate claims.

Close the log and return to the pipeline view to explore the next task.

After the source code is packaged, the build-container task builds a container image from the verified source. As part of this step, the image is attested and a Software Bill of Materials (SBOM) is generated.

On successful completion, the container image, along with its associated attestations, signatures, and SBOM, is pushed to Red Hat Quay.

The SBOM is stored in the image registry alongside the container image, ensuring that composition data travels with the artifact.

Switch to the Image Registry tab and observe that the generated signature, attestation, and SBOM files appear side-by-side with the container image produced by the pipeline.

Switch back to the CI tab to explore the next task.

Once the SBOM has been generated, the next step is to upload it to Red Hat Trusted Profile Analyzer (RHTPA).

Just like in Module 1, you can now inspect the packages included in the container image and assess identified vulnerabilities directly in Red Hat Trusted Profile Analyzer. This provides security teams and auditors with an end-to-end supply chain view, establishing verifiable software provenance, confirming open source licence compliance, and delivering a tamper-evident record of when components were introduced, updated, or removed across the build lifecycle.

Switch back to the pipeline view. The next task, acs-image-check, assesses whether the container image adheres to predefined security and compliance policies.

The acs-image-check task evaluates the image against policies such as running as a non-root user, using approved base images, and avoiding prohibited or high-risk packages.

Switch back to the pipeline view, the acs-image-scan task scans the container image for known vulnerabilities by comparing its components against vulnerability databases. This identifies any CVEs that could affect the security of the image.

The acs-deploy-check task evaluates whether the container image is allowed to be deployed into the target environment.

Unlike the image scan and image check tasks, which analyse the image itself, this task enforces deployment-time policies such as blocking images with critical vulnerabilities, failed policy checks, or missing attestations.

This ensures that only images that meet all security and compliance requirements are permitted to progress toward deployment.

You can review the vulnerability scan results generated by ACS directly from the pipeline. Click the Output icon under Actions for the pipeline run.

The report summarises detected vulnerabilities by severity and status, highlighting critical findings, whether fixes are available, and which components are affected. This allows teams to quickly assess risk and determine whether the image meets deployment requirements.

You can also review the policy check results directly here, switch to the Image Check Output.

This report highlights policy violations detected by ACS, including which violations break the build and which are informational. For each violation, you can see the affected component, the reason for the failure, and the recommended remediation, helping teams understand exactly why an image may be blocked and how to fix it.

Finally, review the deployment-time policy checks by switching to the Deployment Check output.

This report shows whether the image is permitted to be deployed into the target environment. It highlights any policy violations, distinguishes between build-breaking and non-blocking findings, and provides remediation guidance for issues that would prevent deployment.

If you are not already logged in to GitLab, click the GitLab Console tab in the Showroom and log in using:

Username:

Password:

The release pipeline begins with the extract-destination-image-tag task, which resolves the destination image tag from the Git release. This ensures the release is explicitly tied to a specific version, rather than a moving branch or commit.

Next, the gather-images-to-verify task identifies the container image that was previously built and validated during staging. Using the Git tag, it locates the correct image and generates metadata that links the image back to its source repository and release, establishing clear traceability before promotion.

Wait for the verify-enterprise-contract task to reach Succeeded.

As part of this validation, Enterprise Contract ensures that:

Once the image has passed all verification and policy checks, the copy-image task promotes it to production.

This task retags the previously validated image with a production label (for example, prod-v1.0), clearly identifying it as production-ready.

Only images that successfully pass Enterprise Contract validation reach this stage, ensuring that unverified or non-compliant artifacts cannot be promoted.

The final task, update-deployment, updates the deployment configuration to reference the newly promoted production image.

This integrates seamlessly with GitOps, allowing tools such as Argo CD to automatically deploy the validated image into the production environment.

At this point, security validation transitions into customer value, with promotion and deployment handled automatically and consistently.

By combining signed commits, SBOMs, provenance, vulnerability scanning, and Enterprise Contract validation, only verified container images are promoted to production. Release promotion becomes automated, auditable, and policy-driven, reducing risk while significantly accelerating delivery.

Security is enforced by design, and production readiness is proven, not assumed.

In this module, you addressed a critical customer challenge: “Unverified or unsafe images are slipping through to staging and production.”

As a participant, you executed an end-to-end trusted software supply chain workflow, observing how Red Hat Advanced Cluster Security (RHACS), Enterprise Contract (EC) policies, and release promotion work together to ensure only verified images are allowed to progress.

For customers, this means releases become safer, auditable, and fully governed. Every promotion decision is backed by cryptographic evidence, vulnerability data, and policy enforcement, ensuring confidence at every stage of the delivery process.

For consultants, this module provides a reusable pattern for embedding policy enforcement and release governance into real-world CI and CD pipelines, without introducing friction or slowing development teams down.

For technical sellers, this completes the workshop story: Red Hat Advanced Developer Suite (RHADS) prevents unsafe releases and turns every deployment into a controlled, compliant, and predictable outcome.

The key takeaway is this: with RHADS, developer velocity is preserved because trust is verified automatically, and enterprise risk is reduced because policy-driven guardrails ensure only trusted, compliant artifacts are promoted to production.