IBM Cloud Code Engine occupies a particular niche: a fully managed Knative-style serverless platform that abstracts away the Kubernetes machinery while still running container images and supporting long-lived workloads alongside event-driven functions. For organizations that landed on IBM Cloud through regulated-industry requirements, mainframe modernization, or hybrid-deployment commitments, Code Engine is the natural target for modern container workloads. The supply chain security model that applies to Code Engine is different in instructive ways from what defenders typically bring over from AWS Lambda, GCP Cloud Run, or Azure Container Apps. The differences are not principally about better or worse — they are about which controls compose well, which require additional integration work, and which gaps need to be filled with non-IBM tooling. This is what to know if Code Engine is in your scope.
What is Code Engine actually running?
Code Engine runs container images on managed Kubernetes infrastructure that is invisible to the customer. You can deploy a long-running application, a job, a function, or a build, each as a Code Engine project resource. The project is the isolation boundary; workloads in different projects do not share network or compute, and the platform handles scaling and lifecycle. The container image must live somewhere Code Engine can pull it, which in 2026 deployments is typically IBM Cloud Container Registry, an external public registry, or a private registry reachable via configured credentials. The supply chain implication is that Code Engine itself is a deployment target; the build, signing, and scanning happen upstream of it. Your provenance and integrity controls have to be enforced before the image reaches the Code Engine project, because the platform itself does not provide a Binary-Authorization-equivalent policy gate that rejects images failing your trust criteria.
How does identity work for workloads?
Code Engine workloads authenticate to IBM Cloud services through trusted profiles, the IBM Cloud IAM mechanism that lets a workload assume a managed identity without holding a long-lived API key. The trusted profile is bound to the Code Engine project and the specific workload, and the workload can request short-lived IAM tokens from the metadata service. This is operationally similar to AWS IAM Roles for Service Accounts or GCP Workload Identity, and the same supply chain reasoning applies: scope the trusted profile to the minimum service access the workload requires, audit cross-account trust relationships, and rotate the trust criteria when the workload's source repository or owning team changes. The mistake that recurs in Code Engine rollouts is over-broad trusted profiles inherited from a prior IBM Cloud Functions deployment, where the original scope was set permissively for development and never tightened for production.
# Inspect trusted profile bindings for a Code Engine project
ibmcloud ce app get --name my-app \
--output json | jq '.spec.template.spec | {trustedProfileName, serviceAccountName}'
Where does image scanning happen?
IBM Cloud Container Registry includes Vulnerability Advisor, which scans pushed images for known CVEs and configuration issues. The scan results are accessible via the IBM Cloud CLI and Vulnerability Advisor API. The integration with Code Engine is operational rather than policy-enforcing: scans run on push, results are available for inspection, but Code Engine itself does not refuse to deploy images with critical findings. Defenders who want pre-deployment gating need to add an explicit check in the CI/CD pipeline: query Vulnerability Advisor for the image's scan results, evaluate against your acceptance criteria, and fail the pipeline before the ibmcloud ce app create or ibmcloud ce app update step. Without this check, an image with critical findings will deploy successfully, and the only signal that something is wrong is the scan result sitting in the registry view nobody looks at.
How do you sign and verify images for Code Engine?
The Code Engine documentation supports configuring images with Cosign-style or Notation-style signatures, but verification of those signatures at deployment time is not enforced by the Code Engine platform in the way GKE's Binary Authorization or EKS's signature verification can be configured. The supply chain pattern that works is: sign the image in your CI pipeline (using a signing key custodied in IBM Cloud Hyper Protect Crypto Services for FIPS Level 4 custody, or via an external Sigstore Fulcio deployment for keyless signing), publish the signature alongside the image in Container Registry, and verify the signature in the deployment job before pushing the new image revision to Code Engine. The verification step is the gate; Code Engine receives only images that have already passed it. This pattern is more brittle than platform-enforced verification because a deploy that bypasses your pipeline also bypasses the gate, so the defense in depth is to also restrict who can call the Code Engine API directly through IAM policies that funnel deployments through the pipeline's service identity.
What about secrets and configuration?
Code Engine projects can reference secrets and config maps in IBM Cloud Secrets Manager or in project-local secret resources. The supply chain reasoning is straightforward: secrets are configuration that affects what the deployed code can do, and changes to them should be audited and reviewed the same way code changes are. The pattern that fails in practice is teams that manage code through Git and pipelines but secrets through console clicks; the resulting drift means a deployment can pass every code-side check while running with secrets that grant access far beyond what the team intended. The mitigation is to treat secret bindings as code: define them in a manifest, deploy them through the same pipeline that deploys the workload, and audit the deployed bindings against the manifest periodically. Hyper Protect Crypto Services or Secrets Manager can be the storage; the Git-and-pipeline workflow is the discipline.
How does Code Engine fit alongside other IBM Cloud security services?
The services that compose meaningfully with Code Engine for a supply chain posture are: IBM Cloud Activity Tracker for control-plane audit logging, IBM Cloud Security and Compliance Center for posture management and compliance assessment, IBM Cloud Identity and Access Management for identity bindings, Vulnerability Advisor for image scanning, and Hyper Protect Crypto Services for FIPS Level 4 key custody. The composition that works is to wire Activity Tracker to an immutable log archive (preferably outside IBM Cloud for tamper-resistance), let Security and Compliance Center evaluate your Code Engine projects against a custom or pre-built profile that includes your supply chain controls, and have Hyper Protect Crypto Services hold any signing keys used by your CI pipeline. The composition that fails is to assume that "Code Engine plus IBM Cloud" is a turnkey supply chain solution; the services compose well but they require deliberate integration, not just enablement.
What does a healthy Code Engine deployment look like in 2026?
A defended Code Engine deployment has: images that are scanned, signed, and verified before deploy, with the verification done by a pipeline whose identity is the only IAM principal authorized to call the Code Engine deploy API for that project. Trusted profiles scoped to the minimum service access required, reviewed quarterly and rotated when ownership changes. Secrets and config bindings defined in source, deployed through the same pipeline as code, audited against source on a regular cadence. Activity Tracker logs archived outside IBM Cloud with at least one year of retention. Vulnerability scanning results fed into the same prioritization workflow as scans from other registries. Continuous compliance assessment in Security and Compliance Center against a profile that reflects the organization's controls, not just IBM defaults. And explicit playbooks for what happens when an IBM Cloud incident affects services Code Engine depends on, because a fully managed platform amplifies the impact of provider-side incidents.
How Safeguard Helps
Safeguard inventories every Code Engine project across your IBM Cloud accounts, mapping deployed workloads to their source repositories, container images, scan results, signatures, and trusted profile bindings. Policy gates block deployments through your pipeline when an image lacks a valid signature, has unmitigated critical findings, or would run with a trusted profile granting access beyond the approved scope. Griffin AI translates a fresh disclosure — whether a CVE in a base image you use or an IBM Cloud incident bulletin affecting a service Code Engine depends on — into a specific list of affected projects with their responsible teams. Continuous monitoring brings IBM Cloud workloads into the same supply chain discipline that covers your AWS, Azure, and GCP footprint, so a defender does not have to maintain a separate mental model for each cloud they touch.