Verifying signed Flowable Docker images

Verifying signed Flowable Docker images before they run

Flowable images from version 6.7.3 carry cosign signatures that you can check against the published public key before a container starts. A platform or security team pulling Flowable images into an internal registry and cluster needs that proof: the image it stores is the one the project published, unchanged since signing. A valid signature shows who signed the image and that its contents have not been altered afterward. It does not show that your process models, Java delegates or engine configuration are safe. Those remain your responsibility and belong to application testing and review. A signature also says nothing about known vulnerabilities in the base layers, so verification sits alongside vulnerability scanning and version pinning.

Teams usually need this check at two points: when an image enters the internal registry, and when the cluster admits a pod. In the first, a CI job verifies the signature before the image is pushed or promoted. In the second, an admission controller or policy engine your cluster already runs refuses images without a valid signature. Pinning complements both. Reference the image by an exact version and, where your tooling supports it, by digest, because a mutable tag can point at different content over time and a verified tag is only as stable as its tag. Before you write the policy, confirm with the project which Flowable images and tags carry signatures and how the public key is distributed and rotated.

The policy decisions are where most of the work sits. Decide who holds the public key, who approves a key change, and whether a failed check blocks the deployment or only raises an alert. Decide how emergency exceptions are approved, recorded and removed, so a bypass does not become permanent. Ask a partner or your own team to test the policy against an unsigned image, a re-tagged image and an image signed with a different key, and keep the results as evidence. The Flowable open source page is the starting point for release information, and your own change process should record which version you verified and when.

Where to verify and when each point fits

This table compares four places to check a signed Flowable image: a manual operator check, a CI gate before promotion, an admission policy at deploy time, and a runtime or host check. Read each row against your own estate, since a single-host Compose stack and a multi-cluster Kubernetes estate need different points. The main takeaway is that coverage rises with each point, but so do pipeline time and the number of people who must own the policy.

Verification point	What it checks	When it fits and trade-off
Manual operator check	Operator runs cosign verify against the image digest and the published public key before pulling or updating the stack	Fits a small single-host Compose stack with infrequent updates. Low tooling cost, but it depends on someone remembering to run it and leaves no enforced record
CI pipeline gate before promotion	Pipeline verifies the signature and pins the digest before the image is copied to a registry or promoted to a higher environment	Fits teams that build and promote images through stages. Catches problems early and adds verification time to each pipeline run, and the pipeline team owns the key handling
Admission policy at deploy time	Cluster admission controller rejects pods whose images lack a valid signature from the approved key	Fits Kubernetes estates with several clusters or teams. Gives the strongest enforcement for anything that reaches the cluster, but the policy engine, its exceptions and its upgrades need a named owner
Runtime or host check	Host or agent confirms the running image digest matches the verified digest and flags drift after deployment	Fits environments where images may be started outside the pipeline. Detects drift late rather than blocking it, and adds monitoring work for the platform team
Key and policy ownership	Which team holds the public key, rotates it and decides which signing identities are trusted	Confirm this with your security team before choosing points. The signing key and policy engine choices are yours to make and should be documented alongside the chosen verification points

Pinning Flowable versions alongside signature checks

A signature check only proves something about the artifact it verified. If the deployment then pulls a floating tag such as latest, the name can point to a different image by the time a pod starts, and the earlier check will not notice. Registry tags are mutable pointers. Anyone with push access to the repository can move a tag to a new manifest, so the verification has to attach to something that cannot move. Pin by digest, the sha256: identifier of the manifest that was verified, and deploy that exact reference. An exact Flowable version tag is useful as a human label, but it is still a pointer, so let the digest carry the trust. Before you write the policy, confirm with Flowable which image names and repositories it publishes and whether each release is signed under the same identity.

The verified digest should be the same value that the admission policy and the deployment manifest both reference. Verify it once in CI, then promote that reference through each environment and resolve nothing again by tag. Signing begins with Flowable 6.7.3, so older images may carry no signature at all, and the policy should treat them as unverified. Flowable has also shipped several later major lines, including 7.0.0 and 8.0.0 (released February 27, 2026, according to the 8.0.0 release notes), each with its own Java, Spring and Jakarta baseline. A pinned digest therefore fixes both the artifact and the runtime requirements that come with it, so an upgrade to a new line is a planned change with its own verification and testing, not a routine digest refresh.

Record the pinned digest in the deployment manifest and in Git, in the same commit that changes the configuration the image runs with. A Kubernetes Deployment, a Helm values file or a Compose file should carry the full digest in its image field, so the commit history shows who changed the pin, when, and which verification run approved it. Treat every pin change as a planned upgrade: run the signature check again, review the release notes for the target line, and test the process definitions against that image. Ask your partner or Flowable to confirm the signing identity and how new signed builds are announced before you commit the first pin, and agree who owns the job that refreshes digests when a fix ships on the same version line.

Setting up cosign verification for Flowable images

This sequence takes Flowable images from the public registry to a pinned, verified copy in your own registry, with a recorded result. Each step ends with a check so the verification can be trusted before a cluster or pipeline depends on it.

Confirm which Flowable tags are signed
Start by listing the Flowable image tags you plan to run. Signatures are documented from version 6.7.3 onward, so older tags need a separate trust decision. Confirm the signed tag set in Flowable's current release documentation, then run a cosign lookup against each candidate tag to see whether a signature is attached. Record the tag, the digest it resolves to and whether a signature was found. The step is done when every version you intend to run has a recorded result.
Obtain the published public key
Download the cosign public key from the location Flowable documents for image signing. Take the key only from that documented location, not from a mirror, a blog post or an unchecked copy in another repository. Confirm the file name, path and key format in the current Flowable documentation before you run any command. Store the key with its source URL and download date noted, in version control or your secrets tooling. The step is done when the key file is stored with its origin documented.
Check the key fingerprint through a second channel
Compute the fingerprint of the downloaded key and compare it with a value obtained through a different channel, such as the vendor's documentation, a signed release note or a colleague who has checked it independently. A match on both channels makes a swapped key unlikely. A mismatch means you stop and resolve the source before using the key. The step is done when the fingerprints match and the comparison is written down with the date and the name of the person who checked.
Pin each image to a digest
Resolve each signed tag to its immutable digest and use that digest in every deployment reference. A tag can be moved to a different image, so the tag alone does not identify the artifact that cosign checks. Write the digest into your deployment manifests, Helm values or pipeline variables. Compare the digest in each manifest with the digest you recorded in the first step. The step is done when no deployment file refers to a Flowable image by tag alone.
Mirror the image and signature internally
Copy the pinned image into your internal registry along with its signature. Use the copy tool your registry team supports, and confirm that it carries the cosign signature with the image, because a copy without the signature cannot be verified there. Compare the digest in the mirror with the digest recorded earlier. The step is done when the mirrored digest matches the source and the signature lookup against the internal registry returns the same result as the source.
Run cosign verify against the pinned digest
Run cosign verify with the public key against the mirrored image reference, using the digest rather than the tag. Confirm the exact command syntax in the cosign documentation and in Flowable's guidance for your cosign version. Capture the output, the exit code and the verified digest. The step is done when the command exits successfully for each pinned image and the output names the digest you expected.
Confirm verification rejects a bad image
Test the negative case in a test registry before you trust the check. Push an unsigned copy of a Flowable image, and separately push a copy with altered content, then run the same verification command against each. Both should fail. If either passes, the command is not checking what you think it checks, and it should not go into an admission or pipeline gate. The step is done when both images are rejected and the failure output is saved with the test record.
Record the result and set re-check triggers
Write a verification record for each image, covering the tag, digest, key fingerprint, verification date, cosign version and the person who ran the check. Name an owner for the key and confirm with Flowable how keys are rotated or replaced. Schedule verification to repeat whenever you change the Flowable version, the cosign version or the registry. The step is done when a record exists for every pinned image and an owner is named for both the key and the re-check.

Enforcing verification in CI or at Kubernetes admission

The CI gate runs verification in the pipeline that builds, mirrors or promotes a Flowable image, before the image reaches the registry that deployments read from. The platform or release engineering team usually owns the policy, and the pipeline definition goes through the same merge review as the rest of the delivery code. A failed check stops the job, so the deployer sees a failed pipeline with the image digest and the failed step named.

What gets blocked: promotion of any image whose signature cannot be verified against the public key your team pinned, including images re-tagged or copied through a mirror.
Error the deployer sees: a failed job at the verify step, with the digest, the key identity used and the verifier's exit message in the log.
Exceptions: granted as a separate, time-limited change request with a named approver and ticket reference, then passed to the pipeline as an explicit variable that the job logs.
Policy changes: key rotation and verifier upgrades go through merge request review by security and platform owners, tested against one known-good image and one deliberately altered test image.

Confirm that the verify step fails closed when the key is missing or the registry is unreachable, and that no later stage can skip it.

Security risks in trusting Flowable images

A valid signature proves that a specific key signed a specific image. The risks below sit around that proof: where the key came from, which image the tag points to, which copy runs in your cluster, and whether the signed image is configured safely. Each card names the control to apply and the team that should own it.

Trust in the published public key

A key downloaded from the same place as the image proves little. If an attacker can change the download page, the registry or the release notes, they can publish a matching key and an image signed with it. Obtain the public key through a channel you trust, record its fingerprint, and store that copy in your own configuration repository. Compare the fingerprint again when the key is updated. Security engineering or the supply chain owner should hold this step, because the key is the root of every later check.

Tag mutability after verification

A tag such as a version number can point to a different image after you verified it. Verification run against a tag only proves the image behind the tag at that moment. Resolve each tag to its digest, verify the signature on that digest, and reference the digest in deployment manifests and admission rules. Re-verify when you update a manifest. Platform engineering should own the mapping from tags to approved digests, because deployment tooling is where a tag gets resolved.

Mirror copies that differ from the source

Your internal registry may hold an image that is not byte-identical to the one Flowable signed. Mirroring tools can re-tag, rebuild or drop the signature artifact, and a copy can also be altered inside your network. Verify the signature at the point of import into your registry, confirm the digest matches the source digest, and keep the signature with the image. If you re-sign internal copies under your own key, record that step and who approved it. The registry team should own this boundary.

Unsigned images and community forks

Images with no signature cannot be checked, and forks can be signed by someone else. Releases before the signing version named for this topic may carry no signature at all, and community builds may be signed by keys you have never reviewed. Build an inventory of every Flowable image in use, mark which ones are signed and by which key, and set admission rules to refuse unsigned images or images from unlisted identities. Confirm the first signed version in the project's release notes before you write the rule. Security and compliance should set the policy, with platform engineering enforcing it.

Key rotation and revocation

A signature made with a compromised or retired key still verifies until your policy stops trusting that key. Keep signing keys as a list with validity dates in your policy rather than a single hard-coded value, so you can retire one without breaking every cluster. Write a runbook that covers how you learn of a rotation, who approves the new key, how you re-verify running images, and what you redeploy. Security operations should watch project announcements and own this runbook, since the response depends on how quickly it is applied.

Valid signatures and vetted configuration

An image that passes verification can still run with default credentials or unsafe database settings. The signature confirms origin, not how the engine is configured. Change every default credential before the first deployment, review database and REST settings against the project's configuration guidance, and add those checks to the same CI or admission stage as the signature check. Application owners and the platform team should share this review, because the signed image alone does not establish that the running system is ready for production.

Rolling out enforcement without breaking deploys

Start enforcement in audit or warn mode, not in enforce mode. Run the admission or CI policy against every namespace that pulls Flowable images and record each workload whose image would fail verification, grouped by image reference. Most failures at this stage are pinning gaps rather than bad images: a tag that moves after the signature was made, a registry mirror that re-pushes the image without carrying the signature, or a Helm chart that still points at a floating tag. Fix those first, confirm that your internal mirror copies signatures along with images, and then switch to enforce for newly created namespaces. Move existing namespaces only after they show a clean record for a period you set yourself, and confirm with your team which owners will be notified before any workload is blocked.

Emergency patches are where verification most often gets bypassed. A patched image has a new digest, so the pinned reference in your manifests must change, and the new digest must carry a valid signature from the published key before the policy will admit it. Agree a fast path in advance: the image is verified with the same key, the digest is updated through the normal change record, and the exception is not a blanket disable of the policy. If a temporary exception is unavoidable, scope it to one workload and one digest, name the approver, and remove it in the same change window. Ask the vendor or your partner which artifacts accompany a rebuilt image so that the verification step can be tested before an incident forces it.

Upgrades need their own verification test because a new Flowable major version can change the Java, Spring or database baseline that your application image is built on. The signature check itself does not depend on the Java version inside the container, but your build and base image do change. Run the verification step against the candidate tag in CI before any cluster admits it, and keep the last verified version pinned until the new one passes your tests. The Flowable 8.0.0 release notes document an upgrade to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, so plan the application image rebuild and the signed-image cutover as one tested change.

Limits to confirm before you rely on signature checks

A signature check only proves something when it covers the exact images you run, verified against a key you trust. The items below are the gaps most often assumed rather than confirmed. DeployOpen does not issue attestations, so confirm each one in writing with Flowable or your own platform owners before it goes into a policy.

Which images carry signatures

Confirm which image names and tags for your chosen Flowable product are signed, starting from the version where signing begins. Signing may apply to the REST application but not to every engine image, or to new tags but not to older ones. Record the exact repository and tag pairs you intend to pull, and treat any pair you cannot confirm as unverified.

Coverage across your configuration

A signed image in one file does not protect the stack. Check every image referenced by your Docker Compose files, Helm charts or manifests, including database sidecars, proxies and init containers. Any unsigned image left in the configuration becomes the weak point in an otherwise verified deployment.

Public key location and rotation

Confirm where the published public key is served, whether it is versioned, and how Flowable announces a key change. Ask how a rotated key is distributed and how long the old key stays valid. Pin the key in your own store with a documented owner, so a key change is a reviewed event and not something the policy quietly accepts.

Registry support for signature storage

Signatures are stored alongside images in the registry, and not every registry handles this the same way. Confirm that your registry, including any mirror or pull-through cache inside your network, keeps the signature artifacts when images are copied. A mirror that drops them leaves your verification step with nothing to check.

Policy engine calling cosign

Confirm that your admission controller or CI policy engine can call cosign verification, supply the trusted public key, and fail the deployment when verification fails. Test a deliberately unsigned image in a non-production cluster. A policy that reports a warning instead of blocking the pull gives you no enforcement.

Scope of what DeployOpen confirms

DeployOpen can help design and test the verification step, but it does not issue attestations, audit reports or certifications. Any statement that an image is authentic for your auditors must come from Flowable, from your own assessment, or from an independent assessor. Put each confirmed item in writing and name the person who owns it.

Common questions about verifying Flowable Docker images

Can our own team verify Flowable Docker images without outside help?

Often yes, if the team already runs container pipelines and a Kubernetes cluster. The core work needs a short list of skills: running cosign verification against the published public key, pinning image versions in manifests, writing admission or CI policy in the tool your platform uses, and reading signature failures well enough to tell a bad image from a bad configuration. Most of the difficulty sits in policy engineering and key handling, not in Flowable itself. Before deciding, confirm which Flowable image tags your team will pull, whether your registry mirrors them without breaking signatures, and who in your organization owns the trust decision about the signing key. An outside partner is most useful when the policy must cover many clusters and pipelines at once.

What drives the effort of verifying signed Flowable images?

The main drivers are the number of clusters, registries and build pipelines that pull Flowable images, plus any admission policy already in place.

Clusters and namespaces: each enforcement point needs its own policy testing and exception handling.
Registries and mirrors: copies held in internal registries must keep their signatures intact, or verification fails.
Pipelines and existing controls: an admission policy engine already in place can be extended, while a new one must be introduced, tested and documented.

Most of the cost is people time to design, test and roll out the policy, plus review each time Flowable versions change. Ask any quote to list every cluster, registry and pipeline in scope, and to state which costs are one-time and which recur. DeployOpen does not publish prices, so figures come only from a written scope.

How long does a first signature enforcement rollout usually take?

It depends on how many environments start in audit or warn mode and how many teams must fix deployments that fail verification. The rollout generally moves through the same phases: an inventory of the Flowable images currently in use, verification added to CI, admission checks run in audit mode, and then enforcement. Each phase waits on change windows and on owners who must approve exceptions, so calendar time often matters more than technical effort. No duration is stated here because it depends on your environment. Ask for phase-level milestones in the written scope, and ask which clusters will be enforced first.

What does the work need from our team before it starts?

Three things need to be in place before the work begins.

Registry access: read access to every registry or mirror that stores Flowable images, and write access to the pipeline configuration that pulls them.
Key custody decisions: your organization must decide whether it trusts the published public key, who approves any key rotation, and where the key reference lives in your pipelines.
Change windows: time in non-production and production clusters for policy changes, with a named owner who can approve exceptions when a deployment fails verification.

A test cluster that mirrors production is useful for proving the policy before it blocks real workloads. Confirm each of these items with your team early, because they often set the pace of the work more than the policy itself.

Do signature checks replace vulnerability scanning of Flowable images?

No. A valid signature shows that the image was published by the holder of the signing key and was not altered afterward. It does not show that the libraries inside the image are free of known vulnerabilities, and it does not show that the configuration is safe for your environment. Keep vulnerability scanning on your own schedule, and pin image versions so scan results match what actually runs. Signature checks and scanning answer different questions, so a mature image policy usually includes both. Ask the vendor to confirm exactly what its signatures cover before you write policy that depends on them.

What does a fixed-scope engagement for this work typically cover?

Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For this topic, a written scope would normally name the Flowable images and tags in use, the verification step added to CI, the admission or CI policy for named clusters, test evidence from non-production environments, a runbook for verification failures and key rotation, and a handover to your team. DeployOpen implements this work inside your own infrastructure. Ongoing upgrades and continuous testing are available as retainers, and they are priced separately from the initial scope.

Does DeployOpen certify our Flowable deployment for compliance audits?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports, attestations and certifications. Signature verification can produce evidence for change management and software supply chain controls that an auditor may test, such as logs of verification results and records of policy exceptions. Ask your auditor early which evidence they expect to see, and agree that format before the policy is built. This keeps the evidence useful for the assessment instead of something assembled after the fact.

How DeployOpen scopes Flowable image verification

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, including Flowable engines and their REST application. For image verification, we start from a written scope that sets which Flowable images your clusters pull, where signatures are checked, and how the checks fit your existing delivery pipeline.

How we scope

Inventory every Flowable image your build and runtime pipelines pull, including tags and registries in use.
Agree in writing which verification points apply: CI build, registry admission or cluster admission.
Confirm whether your Flowable images are at version 6.7.3 or later, where signatures are published.
Define who holds the trusted public key, how it rotates and who approves exceptions to pinning.

How we build

Configure cosign verification against the published Flowable public key in your CI pipeline.
Pin image references to digests in deployment manifests so verified artifacts are the ones that run.
Add an admission policy in your cluster that rejects unsigned or unverified Flowable images.
Test failure paths with an unsigned image, a wrong key and a tag that changed after verification.

How we hand over

Deliver the verification configuration, policy files and pipeline changes in your own repositories.
Document the key location, rotation steps, upgrade steps for new Flowable versions and rollback.
Walk your platform and security teams through the test results and the exception process.
Record which controls the evidence supports, while your auditors decide whether it meets their criteria.

How we support

Review each new Flowable release for changes to signing, image names or the public key.
Update pinned digests and policies when you move to a new Flowable version, such as 8.0.0.
Offer ongoing support, upgrades and continuous testing as a retainer if your team wants it.
Keep verification checks running on a schedule so drift in pipelines or policies is caught early.

Verifying signed Flowable Docker images