Fixing the issue can be done in a few different ways, depending on where the problem originated.
If the secret was found in an in-house, locally produced artifact, you should modify the source to remove the secret from the CI/CD pipeline. In general, it's recommended to use a variable or a form of encryption instead of a hard-coded password. With a CI/CD pipeline, the modification should build a new, more secure binary.
If the modified binary passes a new scan, delete the old insecure binaries. Don't forget to remove them from the trash can too, this will permanently delete the vulnerable file:
If the secret was found in an external package, it can be modified and redeployed. For this example we'll be using Docker. First, pull the vulnerable image:
Remove or otherwise scrub the file of this information. Now we can save the modified Docker Container as an image:
Finally, tag and push the fixed image to a Local Docker repository:
If the secret was found in an in-house, locally produced artifact, you should modify the source to remove the secret from the CI/CD pipeline. In general, it's recommended to use a variable or a form of encryption instead of a hard-coded password. With a CI/CD pipeline, the modification should build a new, more secure binary.
If the modified binary passes a new scan, delete the old insecure binaries. Don't forget to remove them from the trash can too, this will permanently delete the vulnerable file:
If the secret was found in an external package, it can be modified and redeployed. For this example we'll be using Docker. First, pull the vulnerable image:
docker pull example.jfrog.io/docker-dev-local/docker-app:152Depending on the nature of the image, you can usually start it with a bash terminal. This way you can manually correct the bad file:
docker run -it example.jfrog.io/docker-dev-local/docker-app:152 bashUsing the file path from JAS, locate the exposed secrets:
cd /home/exec/apache-tomcat-8.0.32/conf/ cat tomcat-users.xml
Remove or otherwise scrub the file of this information. Now we can save the modified Docker Container as an image:
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES fd6a146b8e5a example.jfrog.io/docker-dev-local/docker-app:152 "/docker-entrypoint.…" 19 minutes ago Exited (0) 35 seconds ago cranky_goldwasser $ docker commit fd6a146b8e5a sha256:b1ab644c5b332f8188d42357dd23e9a230c0a9f65ad4af84a68ee3b4adb1f2a6 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE <none> <none> b1ab644c5b33 2 seconds ago 760MB
Finally, tag and push the fixed image to a Local Docker repository:
docker tag b1ab644c5b33 example.jfrog.io/docker-dev-local/docker-app:152-fixed docker push example.jfrog.io/docker-dev-local/docker-app:152-fixedYou can separate out these corrected images from the vulnerable public images to ensure any applications you develop don't have the public vulnerability. The Artifactory "Priority Resolution" setting can help with this task.