Notifications
Clear all
Topic starter
20/08/2026 5:22 pm
TL;DR: Runtime controls are being used to detect supply chain abuse, anomalous workflow behaviour, and AI-assisted pipeline risks, according to StepSecurity. The strategic issue is not just visibility, but whether identity, privilege, and execution controls can keep pace with increasingly trusted build systems, as Harden-Runner now protects more than 8,000 repositories and monitors over 8 million CI/CD jobs weekly.
NHIMG editorial — based on content published by StepSecurity: 8,000 Strong: Harden-Runner's Growing Impact on CI/CD Security
By the numbers:
- StepSecurity says Harden-Runner is protecting more than 8,000 repositories.
Questions worth separating out
Q: How should security teams reduce risk from secrets in CI environments?
A: They should minimise the number of long-lived credentials available to build jobs, use short-lived scoped tokens where possible, and treat runners as privileged systems.
Q: Why do CI/CD pipelines create non-human identity risk?
A: CI/CD pipelines create non-human identity risk because they authenticate to other systems, carry secrets, and perform privileged actions automatically.
Q: What do teams get wrong about supply chain protection in build systems?
A: Teams often focus on code integrity alone and overlook the runtime actions of the build job itself.
Practitioner guidance
- Instrument runner runtime behaviour Deploy controls that record process launches, network destinations, and file access inside CI/CD jobs so unusual execution is visible in real time.
- Reduce workflow privilege scope Audit every GitHub Actions workflow for the minimum secret set, cloud permission, and repository access it actually needs.
- Treat workflow identities as governed NHIs Catalogue runners, service accounts, tokens, and automation accounts as part of the NHI estate, then assign ownership, rotation, and offboarding rules.
What's in the full article
StepSecurity's full blog post covers the operational detail this post intentionally leaves for the source:
- Detection logic and runtime baseline methods used to flag anomalous CI/CD behaviour in GitHub Actions
- Details of the Microsoft Defender runner anomaly and the AWS tag-movement investigation
- Examples of how Harden-Runner responds to compromised packages and malicious workflow execution
- The AI coding-agent security examples that show how workflow telemetry is applied in practice
👉 Read StepSecurity's analysis of CI/CD runtime monitoring and pipeline supply chain defence →
CI/CD runtime monitoring: are your pipeline controls keeping up?
Explore further
20/08/2026 6:12 pm
CI/CD pipelines now function as non-human identity environments, not just build systems. Once workflows carry secrets, tokens, and cloud access, the runner becomes an identity-bearing execution context that deserves the same governance discipline as service accounts or privileged automation. The article correctly highlights runtime monitoring, but the deeper issue is identity sprawl inside delivery pipelines. Practitioners should treat every workflow principal as a governed non-human identity.
A question worth separating out:
Q: Who is accountable when an AI agent or workflow modifies a release pipeline?
A: Accountability should rest with the system owner who approved the automation path, not with the agent or the pipeline alone. Organisations need explicit ownership for workflow identities, release permissions, and audit trails so that changes can be traced to a responsible team and governed before production impact.
👉 Read our full editorial: CI/CD runtime monitoring is becoming essential for supply chain defense
