Notifications
Clear all
Topic starter
20/08/2026 5:28 pm
TL;DR: Unexpected Microsoft Defender installation on GitHub-hosted Ubuntu runners was detected within hours, surfacing abnormal network traffic that would otherwise have stayed invisible across many workflow runs, according to StepSecurity. The incident shows that runtime monitoring and baseline-driven controls now matter as much as build-time hardening for CI/CD governance.
NHIMG editorial — based on content published by StepSecurity: How StepSecurity Harden Runner Detected Unexpected Microsoft Defender Installation on GitHub-hosted Ubuntu Runners
Questions worth separating out
Q: What breaks when CI/CD runner behaviour changes without notice?
A: When runner behaviour changes without notice, trust in the pipeline becomes unreliable.
Q: Why do unexpected processes in GitHub Actions matter for identity security?
A: Unexpected processes matter because CI/CD jobs often run with secrets, tokens, and deployment permissions that behave like non-human identities.
Q: How do teams know if pipeline runtime monitoring is actually working?
A: It is working if it can detect new processes, new domains, and unexpected command patterns quickly enough to stop or explain a job before sensitive steps complete.
Practitioner guidance
- Implement per-workflow egress baselines Define the expected outbound destinations for each high-value workflow, then block or alert on any new domain that appears outside that baseline.
- Preserve process lineage for runner sessions Capture command arguments, parent-child process relationships, and binary provenance for workflows that handle deployment credentials or release artifacts.
- Treat hosted runner drift as a control exception Create an escalation path for unexpected software on managed runners, even when the platform says the change was unintentional.
What's in the full article
StepSecurity's full article covers the operational detail this post intentionally leaves for the source:
- The specific GitHub runner observations, including the exact Microsoft endpoints and repository example used to validate the anomaly.
- The distinction between community-tier network visibility and enterprise-tier process intelligence for runner investigations.
- The GitHub Support response and configuration correction details that explain how the issue was confirmed and resolved.
- The practical deployment example for Harden Runner, including the audit mode configuration used to surface the traffic.
GitHub Actions runtime monitoring: are your pipeline controls keeping up?
Explore further
20/08/2026 6:17 pm
Runtime trust is the new control plane for CI/CD. Build pipelines increasingly run in environments that are transient, shared, and partially opaque to the team operating them. That makes repository controls necessary but insufficient. The control question is no longer only who can commit or approve a workflow, but what the workflow is actually doing at runtime. Practitioners should treat runtime observability as a first-class governance control for pipeline trust.
A question worth separating out:
Q: Who is accountable when a hosted runner changes unexpectedly?
A: Accountability usually sits across the platform provider, the pipeline owner, and the security team. The provider is responsible for the managed environment, but the organisation remains responsible for deciding what the workflow is allowed to do, what it can reach, and how anomalies are handled. Governance must define that split before an incident occurs.
👉 Read our full editorial: Runtime visibility is now essential for GitHub Actions pipeline security
