.png)
StepSecurity Harden-Runner continuously monitors outbound network calls from CI/CD runners to help developers secure their builds. Recently, it flagged an anomalous outbound call observed across multiple customer environments. This call was originating from Docker and was directed to a domain that was not present in the expected baseline.
Investigating the Anomaly
Upon further investigation, we found that the outbound call was being made to:
docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com
A search for this domain in Docker's documentation returned no relevant results. This was unexpected, as Docker publishes a list of its expected outbound destinations.
Correlating with Docker’s Published Allow List
Reviewing Docker’s list of allowed outbound destinations, we noticed that a new domain had recently been added:
https://docker-images-prod.r2.cloudflarestorage.com
This domain was similar but not identical to the one Harden-Runner had flagged. This discrepancy raised a key question: Was Docker inadvertently omitting a required outbound destination from its documentation?
Reporting the Issue to Docker
To clarify this, we raised an issue with Docker, highlighting the missing domain and its presence in CI/CD environments. Our issue summary was as follows:
Summary
At StepSecurity, we monitor outbound network calls from CI/CD runners to help developers secure their builds. We recently noticed outbound calls to:
docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com
However, searching for this domain in Docker's documentation does not return any results.
Potential Issue
A recent update added the following domain to the allow list:
https://docker-images-prod.r2.cloudflarestorage.com
Could it be that `docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com` should also be included in the allow list?
Supporting Information
We’ve seen developers using Harden-Runner detect this domain as an anomaly in their builds. Would appreciate any clarification!
Docker Allow List Documentation
Docker’s Response
The Docker team acknowledged the issue and updated their documentation accordingly:
Thank you for spotting and reporting this issue. We have now updated the docs to include `docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com`.
This confirms that Harden-Runner was instrumental in identifying a legitimate outbound call that had not yet been documented.
Why This Matters
One surprising aspect of this discovery is that Docker Desktop also makes the same outbound call, yet no Endpoint Detection and Response (EDR) solution flagged it as an anomaly. If an EDR tool had detected it, someone would have reported it and gotten it updated sooner. Instead, it went unnoticed—until Harden-Runner detected it. This raises an important question: how many other undocumented outbound calls are being made in developer environments without detection?
This case highlights how Harden-Runner helps organizations:
- Detect new outbound destinations from CI/CD runners that are not in the expected baseline.
- Identify potential misconfigurations or missing documentation in widely used software.
- Catch anomalies that even traditional EDR tools might overlook.
In an era where supply chain security threats are on the rise, visibility into outbound network calls is crucial. Harden-Runner continues to play a key role in helping developers secure their CI/CD pipelines by detecting unexpected and potentially malicious outbound calls from CI/CD runners.
If you're not monitoring outbound network activity in your builds, now is the time to start!
.png)
