I filed a pull request against a CloudBees CI repository running PCT and it failed with

java.lang.AssertionError: 

Expected: not a string containing "cloudbees"
     but: was "Started\n[Pipeline] Start of Pipeline\n…+ env\n…\nCHANGE_TITLE=…a PR title mentioning the word cloudbees at one point…\n…\nFinished: SUCCESS\n"
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
	at org.jvnet.hudson.test.JenkinsRule.assertLogNotContains(JenkinsRule.java:1602)
	at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepWorkflowTest.lambda$sshAgentDocker$1(SSHAgentStepWorkflowTest.java:282)

I tried to reproduce this locally by defining an environment variable containing that text, but the test still passed—environment variables from the host were not copied into the container. Perhaps the difference is that PCT was running inside a Docker container and docker-workflow automatically switched to DooD mode as a result and picked up variables from the Docker host.

I also tried to just revert the src/main/ portion of 3a8abe1 but the test still passes, perhaps because the change here was only a second line of defense and jenkinsci/docker-workflow-plugin#167 also fixed it. I tried to go back to 3a8abe1 including its pom.xml and test addition and just revert the src/main/ portion, which required running on Java 8, but that eventually failed with a different assertion because the build failed perhaps due to a stdin problem (this predates #50)

$ docker exec --env SSH_AGENT_PID=30 --env SSH_ASKPASS=/tmp/jenkinsTests.tmp/jenkins5412142432079061933test/workspace/sshAgentDocker@tmp/askpass_5042191538143735518.sh --env SSH_AUTH_SOCK=/tmp/ssh-XXXXXXlNAiaK/agent.24 --env SSH_PASSPHRASE=cloudbees 522401b81c9d0f0184fe3108e0b716a3621823ff667a4908e18c696e9751f6f5 ssh-add /tmp/jenkinsTests.tmp/jenkins5412142432079061933test/workspace/sshAgentDocker@tmp/private_key_2138780056053273533.key
Enter passphrase for /tmp/jenkinsTests.tmp/jenkins5412142432079061933test/workspace/sshAgentDocker@tmp/private_key_2138780056053273533.key: [Pipeline] // sshagent
…
ERROR: Failed to run ssh-add

At any rate, the log of the failed build did mention SSH_PASSPHRASE=cloudbees which matches the reported vulnerability, so I think it is appropriate to tighten up the assertion to match that string. Better of course would be to pick a more random passphrase for the test key, but it is hard-coded and I do not feel like going to the bother of generating a new one, or improving the test utility to generate a key on the fly.