I understand the concern, but can re-assure that the existence of this binary does not expose an attack vector.
I recommend reaching out to the vendor that provides your scanning service and alerting them that they are flagging false positives and identifying tmate as a potential threat, despite being legitimate software. Otherwise I am sure your corporate security team understands that sometimes these scanning services flag false positives, in which case exceptions need to be made.
Will harness consider releasing a version of docker runner, that do not deliver with tmate in it?
Alternatively the source code is public, which means you can build from source and remove the tmate binary from the dockerfile [1][2]. Or in lieu of building from source, you may be able to use our official docker image as a base when building and publishing your own custom image:
FROM drone/drone-runner-docker:1-linux-amd64 as drone
FROM scratch
ENV GODEBUG netdns=go
ENV DRONE_PLATFORM_OS linux
ENV DRONE_PLATFORM_ARCH amd64
COPY --from=drone /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=drone /bin/drone-runner-docker /bin/
LABEL com.centurylinklabs.watchtower.stop-signal="SIGINT"
ENTRYPOINT ["/bin/drone-runner-docker"]
NOTE: the above Dockerfile assumes your are using Linux amd64. The Dockerfile copies the runner binary from our official image into a scratch image (which is an empty image). This scratch image will not contain the tmate binary, which should prevent the image from being flagged by your scanner, but also means you will be unable to use Drone’s remote debugging feature.
[1] https://github.com/drone-runners/drone-runner-docker/blob/master/BUILDING.md
[2] https://github.com/drone-runners/drone-runner-docker/blob/master/docker/Dockerfile.linux.amd64