Security teams should correlate the AWS control plane, workload activity, and GitHub Actions data to identify the human or automation identity behind indirect privileged access. A role alone often shows what changed, not who initiated it. The practical goal is to pivot from cloud activity into the source repository and pipeline logs so investigators can reconstruct the full chain of action quickly.
Why tracing the originating identity matters in AWS, GitHub, and CI/CD
When AWS actions arrive through GitHub Actions or a CI/CD role, the cloud trail often identifies the assumed role, not the human committer, approver, or automation path that caused it. That gap matters because it weakens accountability, slows incident response, and makes it harder to separate routine deployments from suspicious use of the same trust path. Security teams should treat this as an identity reconstruction problem, not just a cloud audit problem.
For this reason, investigators need to connect AWS CloudTrail events to repository history, workflow runs, job metadata, and the identity that approved or triggered the pipeline. In practice, the same role may be used by many branches, service accounts, or automation paths, so the role name alone rarely answers attribution questions. The NHI challenge is not the presence of AWS activity itself, but the indirect chain of trust that masks who initiated it.
GitGuardian’s State of Secrets Sprawl 2025 found that 15% of commit authors have leaked at least one secret in their contribution history, which is a useful reminder that code and pipeline activity can become an identity and credential exposure channel, not just a delivery mechanism. In practice, many security teams notice the attribution gap only after an unusual AWS change has already been executed through an otherwise trusted workflow.
How to reconstruct the identity chain in practice
The practical workflow is to start with the AWS event, then walk backward through every system that could have issued or delegated the action. CloudTrail can show the assumed role, session context, source IP, and timing. From there, GitHub Actions logs, runner metadata, workflow file history, and repository commit history help map the role session back to a specific run, branch, pull request, or actor. If the workflow uses OIDC federation, the claims in the identity token become especially important because they can tie the AWS session to the repository, workflow, and environment that minted the token.
The strongest investigations usually correlate three layers:
- AWS control plane evidence: the exact API call, assumed role, session name, and time window.
- Pipeline evidence: workflow run ID, job name, runner identity, approval path, and artifact or deployment step.
- Source evidence: commit SHA, pull request, branch protection state, and the user or bot that caused the run.
This is where least-privilege design and short-lived credentials help the investigation as much as the security posture. If each pipeline session is narrowly scoped and time bound, the search space for attribution is smaller and the blast radius is easier to reason about. NIST’s Security and Privacy Controls remain relevant here because audit logging, identity proofing, and access control are not separate concerns; they are the mechanism that makes attribution feasible after the fact. For NHI-focused operational depth, NHIMG’s Ultimate Guide to NHIs is useful because it frames secrets, service accounts, and workload identities as governed assets rather than incidental plumbing.
Teams should also preserve the join keys that make correlation possible: workflow run IDs, OIDC subject claims, repository and environment names, role session names, and deployment timestamps. Without those, responders end up reconstructing identity from indirect clues, which is slower and less reliable. These controls tend to break down when multiple repositories reuse the same role without unique session naming, because the investigation loses the ability to distinguish one automation path from another.
Where attribution gets ambiguous and what to watch for
Tighter pipeline attribution usually improves traceability, but it also increases operational overhead, especially in organisations that share roles across many repositories or use self-hosted runners. The main tradeoff is between convenience and evidentiary clarity: shared roles are easy to operate, but they are hard to investigate. If a role session does not carry a unique and durable link back to the triggering workflow, the cloud record may be technically valid yet practically useless for attribution.
One common edge case is delegated automation, where a bot, scheduled job, or reusable workflow triggers another workflow that ultimately assumes the AWS role. In those environments, the originating identity may be several hops away from the AWS session, so teams need a consistent rule for which identity is considered the initiator and which is merely an executor. Another edge case is emergency access, where a trusted maintainer manually reruns a pipeline or edits a workflow file outside the normal merge path; that often changes the attribution chain even though the AWS permissions look unchanged.
Current guidance suggests treating provenance as an evidence problem: if you cannot explain who triggered the session, through which workflow, and from which source revision, then the activity is not fully attributable. For broader context on pipeline abuse and secret exposure paths, NHIMG’s Reviewdog GitHub Action supply chain attack and CI/CD pipeline exploitation case study both illustrate how trusted automation paths can obscure where activity truly began. This approach breaks down most often in multi-tenant CI/CD estates where session naming is inconsistent and provenance data is not retained long enough for incident review.
Risk and Threat Considerations
The material risk is attribution failure: organisations may know which AWS role was used but still be unable to prove which human, bot, repository, or workflow initiated the action. That weakens detection, complicates containment decisions, and can leave malicious or mistaken activity effectively anonymous inside an otherwise trusted automation channel.
Failure mechanism: Indirect access paths such as GitHub OIDC federation, reusable workflows, shared runners, and long-lived role reuse collapse multiple actors into the same cloud identity. If session metadata, workflow logs, or repository history are missing or overwritten, responders lose the join points needed to reconstruct provenance.
Impact: Teams may misattribute an AWS change, miss signs of compromised automation, delay revocation of the right credential chain, or retain a risky pipeline path because no one can confidently identify the originator.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Inventory and Ownership | GitHub and CI/CD roles are machine identities that need clear ownership and provenance. |
| NHI-03 — Secrets and Credential Lifecycle | Tracing role use depends on short-lived, attributable credentials and session context. | |
| NHI-06 — Auditability and Monitoring | Investigators need logs that connect AWS sessions back to GitHub runs and actors. | |
| Recommendation — Inventory every non-human identity and tie each one to an owner and source workflow. Use short-lived credentials and rotate shared secrets to preserve attribution and reduce reuse. Preserve session, workflow, and repository logs so every assumed role can be reconstructed. | ||
| CIS Controls v8 | 8 — Audit Log Management | Correlation across AWS and GitHub depends on retained, queryable audit evidence. |
| 5 — Account Management | Shared CI/CD access paths obscure the originating user unless accounts are governed tightly. | |
| 6 — Access Control Management | AWS role sessions should be scoped so a pipeline cannot hide excessive originating access. | |
| Recommendation — Centralise and retain logs that link cloud actions to pipeline and source-control events. Separate human and automation accounts and avoid shared access paths where provenance matters. Constrain pipeline roles to the minimum access needed and bind them to explicit trust paths. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Attackers often abuse trusted GitHub or CI/CD identities to execute AWS actions. |
| Recommendation — Hunt for misuse of trusted identities when cloud actions appear legitimate but lack clear provenance. | ||
Practitioner Guidance
What to verify: Verify that every AWS session assumed from GitHub or CI/CD can be traced back to a unique workflow run, source revision, and triggering actor. If the session name, OIDC subject, or pipeline logs do not make that join possible, treat the environment as insufficiently attributable even if the role is functioning as designed.
What to prioritise: Prioritise provenance fields that survive incident response, especially unique run IDs, immutable logs, and repository-level audit trails. The goal is not merely to log more data, but to preserve the minimum set of evidence needed to reconstruct who initiated the action before logs roll over or runners are recycled.
Common mistake: Do not accept the AWS role as the final identity. A role tells you which permission set executed the call, but not which person or automation path caused it, and that distinction becomes decisive when you are assessing abuse, misconfiguration, or blast radius.
Practitioner takeaway: The best attribution designs make identity reconstruction routine, not forensic improvisation; if provenance cannot be reassembled quickly, the trust path is too opaque to be operationally safe.
Related resources from NHI Mgmt Group
- How do security teams map AWS Console events back to the identity's actual actions?
- How should security teams scan CI/CD logs for leaked secrets before they are exposed to attackers?
- What do security teams get wrong about workload identity in cloud and CI/CD environments?
- How should security teams harden GitHub repositories used in CI/CD pipelines?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
