For DevSecOps and platform teams
Hold every pipeline to the purpose it was written for.
Pipeline security usually stops at the build. Ordrani follows the pipeline into the cloud, linking each GitHub workflow run to the AWS session it created and evaluating what that session does against what the workflow is meant to do.
The challenge
The most privileged automation is often the least observed once it runs.
CI/CD systems are among the most privileged automation in any organization. A deployment workflow may federate directly into production with the authority to change infrastructure — and the workflow definition, the branch it runs from and the actions it imports can all be altered by an attacker.
Supply-chain and pipeline controls focus on what goes into a build. Far less attention is paid to what a pipeline’s cloud identity does once the build is running.
How Ordrani helps
- Lineage from repository, workflow and run to the cloud session it created
- Detection of runs from unexpected branches, forks, environments or workflow revisions
- Identification of cloud operations outside a deployment’s declared scope
- Evidence that tells engineering exactly which run, commit and job to examine
Signals evaluated
- unexpected ref or environment
- workflow file changed
- OIDC subject mismatch
- out-of-scope resource
- activity after run end
Who it serves
DevSecOps, platform engineering and application security teams who own delivery pipelines.
Pipeline to cloud
The lineage from a workflow run to every cloud operation.
Each link is joined by specific evidence and carries its own attribution level.
01
Repository
org/payments-service
workflow file
02
Workflow
deploy.yml · production
run id
03
Execution
run 4182 · job deploy
OIDC claims
04
Federated token
sub · job_workflow_ref
AssumeRoleWithWebIdentity
05
Role session
prod-deploy-role
session ARN
06
Operations
API calls and resources
How it works
Following a pipeline into the cloud.
01
Observe the run
Collect GitHub workflow runs and audit events: repository, workflow revision, ref, environment and trigger.
02
Follow federation
Match OIDC claims to the AWS role session that each run creates.
03
Compare with purpose
Evaluate the session’s operations against what that workflow normally does and is declared to do.
04
Hand off precisely
Give engineering the exact run, commit and job to examine when something does not fit.
What it detects
Pipelines acting outside their scope.
01
Unexpected ref or fork
02
Workflow tampering
03
Subject mismatch
04
Out-of-scope operations
05
Activity after run end
06
Behavior after dependency change
Continue exploring
Related reading.
Follow your pipelines past the build.
We would welcome a conversation about how your workflows federate into the cloud and what they are permitted to do there.