Pipelines that ship signed builds without a cloud key in sight.
Open the settings of most CI systems and you'll find a long-lived AWS access key or Azure client secret saved as a repository secret, then copied into other repositories. We replace that with OIDC federation first, then work outward to scanning, signing and policy.
DevSecOps builds security checks into the delivery pipeline instead of adding them right before release.
Cohash designs CI/CD on GitHub Actions, GitLab or Azure DevOps that deploys to the cloud with short-lived OIDC tokens, scans code and dependencies, produces SBOMs, signs artifacts and records SLSA provenance. We map the controls to NIST SSDF (SP 800-218) so audit evidence comes from the pipeline itself.
you probably need this if
Cloud access keys sit in CI secrets and nobody knows which pipelines still use them.
A security scan runs once before release and its findings arrive too late to fix.
Auditors ask for an SBOM or proof of where a container image came from and the team has neither.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your DevSecOps, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · devsecops3 open
openCloud access keys sit in CI secrets and nobody knows which pipelines still use them.
recurringA security scan runs once before release and its findings arrive too late to fix.
blockedAuditors ask for an SBOM or proof of where a container image came from and the team has neither.
exposure
Keyless cloud deploymentSupply chain integrityCode, secret and IaC scanningPolicy as codeSecrets that expire
startrehearsehandover
Pipeline review
Remove standing credentials
Add checks by risk
Tune and hand over
we are here
ready to hand over
No pipeline holds a long-lived AWS key.
Each production image traces to a commit and a pipeline run, SBOM attached.
On new code the check blocks the few things that matter, and bypassing it stops being…
Pipeline and credential inventory with risk ranking
chapter 01 · where it hurts
Why teams reach out
Cloud access keys sit in CI secrets and nobody knows which pipelines still use them.
A security scan runs once before release and its findings arrive too late to fix.
Auditors ask for an SBOM or proof of where a container image came from and the team has neither.
chapter 02 · what we change
How we solve it
Keyless cloud deployment
Supply chain integrity
Code, secret and IaC scanning
Policy as code
Secrets that expire
chapter 03 · how it runs
Our approach
Pipeline review
Remove standing credentials
Add checks by risk
Tune and hand over
chapter 04 · where you end up
What changes
No pipeline holds a long-lived AWS key.
Each production image traces to a commit and a pipeline run, SBOM attached.
On new code the check blocks the few things that matter, and bypassing it stops being routine.
Pipeline and credential inventory with risk ranking
what we do
Where we spend the hours
5 areas of work, each one done by an engineer who has run it in production.
We set up AWS IAM roles, Entra federated credentials and Google Cloud Workload Identity Federation to trust GitHub Actions, GitLab and Azure DevOps. Each trust policy checks the subject claim for repository, branch and environment. Checking only the organization isn't enough.
An SBOM for every build, dependency and container scanning, signed artifacts and build provenance aligned to the SLSA Build track. SLSA 1.2 adds a Source track we can map your repository controls to.
Run static analysis, secret scanning on push and Terraform scanning, and post findings as comments in the pull request. Let the fast checks block the merge. Put the slow ones on a schedule.
Rules for Terraform plans and Kubernetes admission written as code, versioned and tested, so a public storage bucket fails the build rather than the audit.
Where an application still needs a secret, HashiCorp Vault issues it dynamically with a short lease, and the pipeline never sees it in plain text.
capability 01 / 05in production
Keyless cloud deployment
We set up AWS IAM roles, Entra federated credentials and Google Cloud Workload Identity Federation to trust GitHub Actions, GitLab and Azure DevOps. Each trust policy checks the subject claim for repository, branch and environment. Checking only the organization isn't enough.
An SBOM for every build, dependency and container scanning, signed artifacts and build provenance aligned to the SLSA Build track. SLSA 1.2 adds a Source track we can map your repository controls to.
Run static analysis, secret scanning on push and Terraform scanning, and post findings as comments in the pull request. Let the fast checks block the merge. Put the slow ones on a schedule.
Rules for Terraform plans and Kubernetes admission written as code, versioned and tested, so a public storage bucket fails the build rather than the audit.
We pieced these together from DevSecOps situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Two hundred repositories sharing one AWS access key
composite · not a client story
Beforethe situation
A GitHub organization has about 200 repositories. One IAM user's access key, with broad permissions, is stored as an organization secret, and CloudTrail shows it called from runners nobody can tie to a repository.
What we dothe work
Use CloudTrail and workflow logs to list which repositories use the key. Create an IAM OIDC provider for GitHub and one role per repository and environment, with trust conditions on the sub claim. Move pipelines over in batches, then deactivate the key and delete it after a quiet week.
Afterwhere you end up
No pipeline holds a long-lived AWS key. Each repository can reach only its own environments, and credentials from any single job expire on their own shortly after it ends.
case file 02
A customer contract now requires SBOMs for every shipped image
composite · not a client story
Beforethe situation
A new customer contract requires an SBOM and provenance for each container image shipped. Images are built in GitLab CI, pushed to a registry and deployed to Kubernetes, and nothing records which commit or pipeline produced them.
What we dothe work
Generate an SBOM in the build job with a tool such as Syft, sign the image and attach provenance with Sigstore cosign, and store both next to the image in the registry. Add an admission policy that rejects unsigned images in production namespaces.
Afterwhere you end up
Each production image traces to a commit and a pipeline run, SBOM attached. An unsigned image is stopped at the cluster rather than turning up later in an audit finding.
case file 03
An IaC scanner that blocks every merge and gets bypassed
composite · not a client story
Beforethe situation
A team added a Terraform scanner to every pull request. It reports hundreds of findings on old modules, developers learned to ignore it, and an admin bypass on merges is now routine.
What we dothe work
Baseline the existing findings and fail only on new ones. Pick a short blocking list (public buckets, open security groups, unencrypted storage) and send the rest to a weekly report with owners. Write each blocking rule as tested policy code.
Afterwhere you end up
On new code the check blocks the few things that matter, and bypassing it stops being routine. Old findings get worked down from a tracked backlog, so nobody faces them all in one blocked merge.
How a pipeline deploys to the cloud without stored keys
The CI job requests an OIDC token from its platform and the cloud exchanges it for a short-lived role only when the repository, branch and environment claims match. Scans, signing and policy checks run before deploy, and Vault issues any remaining secret with a short lease.
We don't start a step until the last one has produced something you can check.
step 01
Pipeline review
We inventory pipelines, runners and every stored credential, and rank them by what they can reach.
step 02
Remove standing credentials
OIDC trust set up per cloud and per environment, long-lived keys revoked once the new path is proven.
step 03
Add checks by risk
Secret scanning and dependency checks go in first. Signing, provenance and policy as code follow.
step 04
Tune and hand over
False positives cut down, reusable workflow templates published and your engineers trained to maintain them.
you keep
What you're left with
We write these for your DevSecOps setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Pipeline and credential inventory with risk ranking
yours to keep
document02
OIDC trust configuration per cloud and environment
yours to keep
code03
Reusable pipeline templates with scanning and signing built in
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your DevSecOps work. The ones who've done it answer differently from the ones who've read about it.
Q1
Show us the OIDC trust policy you'd write. Which claims does it check?
Read the trust policy. If it only checks the organization, any repository or branch can assume the role. You want conditions on repository, ref or environment in the subject claim.
Q2
Did you check our trust policies against the new default subject format GitHub is using?
Repositories created after 15 July 2026 use an immutable default subject that includes owner and repository IDs. Policies written for the older format won't match those repositories until someone updates them.
Q3
Which checks will block a merge, and which will only report?
Blocking on every finding trains developers to bypass the gate. A short blocking list plus a tracked backlog for everything else keeps the gate meaningful.
Q4
Which SLSA Build level will each product reach, and where does the provenance live?
For Build L2 you need signed provenance from a hosted build platform. L3 needs a hardened build platform. Ask the partner to state the level per product and show where the evidence is stored.
Q5
Can a pull request from a fork reach our secrets or self-hosted runners?
Workflows triggered by pull_request_target and shared self-hosted runners are common ways secrets reach untrusted code. The design should say which jobs can see which secrets.
01Will security checks slow our builds down?
Not much, if they're placed well. Secret scanning and dependency checks run in seconds on each pull request. Deeper scans run nightly or on release branches. We measure pipeline time before and after.
02Which SLSA level should we aim for?
Build L2 requires signed provenance from a hosted build platform, which most teams on hosted CI can reach. Build L3 requires a hardened build platform and usually more change. We start with L2 and decide on L3 per product.
03GitHub changed the OIDC subject claim format. Does that affect our cloud trust policies?
It can. Repositories created after 15 July 2026 use an immutable default subject that includes owner and repository IDs, and older repositories keep the previous format unless they opt in. Trust policies written against the old format need checking before anyone opts in or creates a new repository.
04Do you work with GitLab and Azure DevOps as well as GitHub?
Yes. GitLab CI issues ID tokens for OIDC and Azure DevOps supports workload identity federation for service connections, so the same keyless pattern applies. The configuration details differ.
05Do we need to replace the scanners we already license?
Usually not. We start from the tools you have, tune what blocks a merge, and fill gaps such as secret scanning or SBOM generation. Swapping scanners is rarely the cheapest fix for a noisy pipeline.
related
Often paired with
Projects on DevSecOps usually end up touching one of these, so they're worth a look.
