Shared workflows can reduce duplicated security work without forcing different application teams to test and release every service the same way.
Start with a pilot that shares one repeated security task, such as a base-image update, and keep existing security controls in place while you test it.
Name an owner for each part of the workflow, and count an update as complete only when the patched application reaches verified deployment.
Chainguard Containers can supply the maintained components in a shared workflow under applicable support terms and its CVE policy, while your teams maintain added software, test compatibility, and roll out updated applications.
Security automation can create a maintenance backlog of its own. As more teams add checks and update jobs to their pipelines, someone has to keep those jobs current, troubleshoot failures, and confirm that fixes reach production. If each team maintains its own version of the process, adopting more automation can also mean more duplicated work.
Platform teams can scale DevSecOps automation by bringing maintained components, shared security checks, update automation, and release evidence into one workflow. Application teams retain ownership of their code, compatibility testing, and deployment for each service. Test that model with one recurring security task, such as a base-image update. Use the pilot to set expansion criteria. Require reliable deployment, unresolved exposure within agreed limits, and manageable ongoing support effort.
What is DevSecOps automation?
DevSecOps automation turns security work your teams repeat—such as running checks, enforcing policies, and collecting evidence—into jobs that run within the workflows they already use to build, release, and operate software.
The controls in a DevSecOps workflow depend on the application and its risk model. Common elements include:
Security checks and monitoring, including static application security testing (SAST), software composition analysis (SCA), dynamic application security testing (DAST), secrets scanning, runtime monitoring, and scans of infrastructure-as-code and container images.
Evidence for build and release pipelines, such as software bills of materials (SBOMs), provenance attestations, and artifact signatures.
Release gates that evaluate an artifact and its associated evidence, including scan results and approved exceptions, before deployment.
Security automations can surface a finding, block a release, or route work to an owner. When independently deployable services share a component, a common security workflow can reduce duplicated maintenance and standardize update handling, checks, and evidence.
Decide what to share and who owns the work
The controls above can be turned into an effective shared workflow when teams standardize how those controls are configured, how findings and updates move through delivery, and who acts when automation stops. To start building shared security automation workflows, begin with one repeated task, then separate the common mechanics from the decisions that require more specific application or risk context.
Choose a workflow your teams are already repeating
Review recent update PRs, failed builds, and requests for help to find repeated manual work. Ask application owners where those issues delay updates or vulnerability fixes. Choose a task that occurs often, follows similar steps across services, and has a measurable outcome.
For example, one practical candidate that is relevant to many organizations is keeping a common base image current, especially when teams are repeatedly handling vulnerabilities in that image.
DORA recommends improving the most common workflow first and using developer feedback to choose what to improve next. Start with a small set of services and owners who can test the process. Agree on the supported component versions, required checks, rollout method, and completion condition. Then set the risk and reliability criteria you’ll use to judge the pilot, and agree how much time platform and application teams can spend on it. Keep each pilot service’s existing security controls in place until the shared workflow has shown it can run or preserve them.
Determine responsibility and shared ownership
When services follow the same rules, it’s ideal to share update discovery, scanner configuration, and evidence collection if possible. Application teams should keep control of their tests and deployment settings, since those are more unique to how each service works.
Before the pilot, use the table to name an owner and supporting roles for each responsibility.
Work | Primary owner | Supporting responsibilities | Evidence of completion |
|---|---|---|---|
Component upkeep | The maintainer or provider publishes updates for components within its support scope. | Platform manages the approved source, supported streams, and access. Application owners select compatible supported versions and maintain added software. | An updated supported build is available from the approved source, with applicable release or advisory information. |
Shared jobs and update automation | The platform owner maintains common jobs, updater access, evidence collection, and supported workflow versions. | Application owners test workflow changes with representative services and update their consuming references. Platform resolves failures in the shared automation, while application owners resolve failures caused by service-specific configuration. | The workflow revision passes its required tests, and records show which revision each participating service uses. |
Release policy | The security owner defines risk-based requirements, required checks, and exception criteria. | Platform implements the rules. Application owners help validate that the rules reflect service context and resolve application findings. | Versioned policy records the applicable criteria, and check results and decisions are linked to the relevant commit or artifact. |
Application update delivery | The application owner tests compatibility, deploys updates, and handles regressions. | Platform resolves shared-workflow failures. Suspected defects in supplied components are escalated through the maintainer’s or provider’s applicable support process. | The intended artifact is running in the target environment, contains the component update, and passes the required deployment and health checks. |
Risk exceptions | A designated risk owner approves or rejects a temporary exception or risk acceptance. | Security assesses the risk. The application owner explains the service impact, applies agreed mitigations, and owns follow-up work. | The decision records the affected service, artifact or finding, rationale, mitigation, approver, follow-up owner, and expiration date. |
Your platform team can combine provider-maintained capabilities with its own jobs. It should own how the shared workflow integrates, configures, accesses, and maintains those capabilities. Application teams should retain responsibility for service-specific compatibility testing and rollout.
Test the ownership model with a base-image update
A responsibility map becomes especially useful when one shared change produces different outcomes across services with various owners. The following hypothetical example gives an illustration of how this might work in practice.
Let’s say a component provider publishes a patched base-image build. Your platform team’s shared update workflow proposes that build for two independently deployable services: Service A and Service B. The platform team collects evidence linking each source commit, application artifact, and set of check results. The application owners remain responsible for testing compatibility and deploying their respective services.
Service A passes its required checks. Its application owner deploys the updated application, and the team verifies that the running artifact is the one that passed the checks and contains the patched base image. Service A’s update is complete.
Service B fails a compatibility test, so the workflow blocks its release and routes the failure to the application owner. The security team assesses the exposure created by continuing to run the existing image, and the designated risk owner decides whether to authorize a time-limited mitigation or exception. That decision documents how the team will manage the exposure but does not count as deploying the fix. Service B’s remediation remains open until the patched application passes its required checks and reaches verified deployment.
The shared workflow gives both services the same update path, policy, and evidence without forcing them to reach the same outcome. That distinction is why workflow adoption and merged update pull requests must be measured separately from verified deployment and unresolved exposure.
Make failure ownership and risk decisions explicit
Even a well-maintained shared workflow will encounter failures it cannot resolve automatically. When that happens, the workflow should preserve the relevant evidence, route the problem to the right owner, and invoke an agreed policy for deciding what happens next.
Return to Service B, whose update stopped at its compatibility test. Its application owner must now resolve the failure while security and the designated risk owner decide how to handle the exposure in the currently deployed image.
Different failures require different owners. In our example, it might look something like this:
The application owner resolves Service B’s compatibility failure.
The platform owner resolves failures in the shared job itself, such as an updater that cannot authenticate to the registry.
Security or vulnerability-management specialists assess disputed vulnerability findings. The platform team confirms which artifact and data sources were evaluated, and the application owner supplies service context.
If the shared workflow cannot classify the failure, the platform owner should coordinate the initial triage until the next action has a named owner. This does not make platform responsible for resolving every application or security issue.
Useful feedback identifies the affected service, source commit or artifact digest, failed check, supporting evidence, responsible owner, and next action. A failed policy check should also identify the rule that blocked progress. Keep credentials, tokens, and other secrets out of logs and notifications.
The same principle applies to release rules and exceptions. Use a policy-as-code approach to express agreed release criteria as version-controlled rules that teams can review before enforcement. When the pipeline applies a rule, record the affected service and artifact, the policy and workflow versions the pipeline used, the check result, and the release decision. For Service B, include the failed compatibility test and the policy rule that blocked the release.
If your policy permits an exception, create a separate record identifying key evidence, as well as the approver and person responsible for follow-up. Preserve changes to the exception so reviewers can see who extended, narrowed, or closed it and why.
Keep shared workflows current and protected
Clear ownership keeps individual failures moving, but the shared workflow itself also needs upkeep. The platform team must maintain the common jobs and give each service a controlled way to adopt new workflow revisions.
Use reusable workflows without losing version control
A reusable workflow lets application repositories call jobs the platform team maintains. Application teams keep their service-specific tests and configuration in their repositories. In GitHub Actions, a shared workflow library lets teams run common security checks without copying job definitions into every repository.
By contrast, a copied workflow file must be updated in every repository that contains it. Pin the reference to a full commit SHA to keep the repository on a specific workflow revision. Update the reference when you’re ready to adopt another revision. GitHub identifies a commit SHA as the safest reference for stability and security.
That stability also means consumers do not receive workflow fixes or improvements automatically. Treat a new workflow revision like a dependency update: propose changes to the consuming references, test the revision with representative services, and roll it out in small groups. Track which revision each service uses so the platform team can identify stale consumers and pause the remaining rollout if unexpected failures appear.
Protect shared workflows
Treat any changes to a shared workflow as changes that can affect every service using that workflow. Require review for those changes, restrict who can modify the workflow, and limit its credentials and permissions to what its jobs need.
If the workflow calls third-party actions, maintain and update those dependencies as part of the shared job. If a revision causes failures, the platform and application owners should determine whether the problem lies in the common workflow or the service-specific configuration before continuing the rollout.
Measure completed work before expanding automation
Once the pilot is running, measure whether the shared workflows reduce repeated work and deliver updates reliably. Track the ongoing maintenance effort required from platform and application teams. Compare the pilot with recent updates from similar services. Record the participating services and measurement period. Track setup separately from recurring maintenance and support.
Review failed attempts and the oldest unresolved exposures alongside the aggregate results. This helps prevent successful updates from hiding stalled work. A merged update pull request counts as adoption or workflow progress, not completed remediation. For this pilot, count an update as complete when the application team deploys the updated application and verifies the running artifact.
We recommend using the following measures to assess your pilot, at a minimum:
Measure | Definition | Decision it supports |
|---|---|---|
Workflow adoption | Eligible services using a supported workflow revision divided by all services eligible for the pilot. | Is the shared workflow reaching its intended users? |
Manual intervention | Human interventions per service-update attempt, grouped by cause. Distinguish expected approvals from investigations, configuration repairs, and other unplanned work. | Where does the workflow still leave repeated work or require support? |
Patch-to-deployment time | Elapsed time from an applicable patched base image becoming available through the approved source to verified deployment of the updated application. | Where does an available fix stall before reaching production? |
Failures and rollbacks | Failed update attempts divided by all attempts, and rolled-back deployments divided by all update deployments. | Is the process reliable enough to extend? |
Unresolved exposure | The number and age of services still running the affected component, grouped by whether they are awaiting a fix, temporarily mitigated, or covered by an approved exception. | What security work remains incomplete? |
Ongoing effort | Recurring platform maintenance, support, and application-team effort required per update or reporting period. | Can the organization support the workflow as adoption grows? |
Decide whether to expand your workflow to another team
Compare the results with the reliability and risk criteria established before the pilot. Expand to other teams when all three of these conditions hold:
The workflow delivers updates reliably to verified deployment.
Unresolved exposure remains within the agreed limits.
The recurring effort is sustainable for both platform and application teams.
If any condition isn’t met, address the recurring failures or support burden before expanding your shared workflows to more services.
When it’s time to expand to new teams and services, choose a team whose services can use the supported component and workflow versions. Before onboarding, name the application owner and the owners responsible for failed updates and risk decisions. Record the service-specific tests, deployment controls, rollback procedure, and completion checks that the shared workflow must invoke or preserve.
Run one update through the service’s normal build, tests, and deployment, then verify the running artifact, service health, and applicable fix. Keep service-specific test and deployment settings under the application team’s control. If the service cannot yet satisfy the workflow’s requirements, preserve its existing security controls and defer adoption until the platform and application owners agree on a supported approach.
Build shared workflows with maintained components
Standardizing and automating security workflows only solves part of the challenge of scaling DevSecOps automation. If your platform team must also rebuild and patch every common base image, component maintenance can remain a bottleneck even after you establish effective shared workflows.
Chainguard Containers takes on the provider side of that responsibility. Chainguard publishes maintained container images for supported version streams and addresses qualifying CVEs under applicable support terms and its published CVE policy. Platform teams can connect this maintained component source to their shared workflows. Application teams retain control of added software, compatibility testing, deployment, and verification. Maintained components reduce the base-image work your platform team carries. Your shared workflow still needs application security checks, compatibility tests, and runtime controls for each service.
To test this approach, you can use Chainguard’s free plan to select up to five container images for a shared workflow pilot. Carry an update through the shared jobs, service-specific tests, and deployment verification described above, then use the results to decide whether to continue expanding.
Related articles