Run recordIssues inside the container that grype scanned

Using Jenkins
1

I have a job that builds a docker image and after the build I run a grype scan on it

    stage('Docker Image Scan'){
      steps {
        sh "grype docker:myimage:$VERSION -o json --file grype.json"
      }
    }

I later use the grype.json in the post section with warnings plugin’s recordIssues to show the result in my job interface.

The issue is that when grype reports that say /usr/bin/apt is vulnerable to X vulnerability, the warnings plugin tries to resolve that file on the host to record a fingerprint for future builds, and it just is not correct.

One way to fix it was to run the recordIssues in the same container that the grype scans like

  post {
    always {
        script {
            docker.image("myimage:$VERSION").inside {
                recordIssues skipBlames: true,
                    skipDeltaCalculation: true,
                    skipPostProcessing: true,
                    skipPublishingChecks: true,
                    sourceCodeRetention: 'NEVER',
                    tools: [grype(pattern: 'grype.json')]
            }               
        }

But this does not work as the docker pipeline’s documentation says that

External processes like sh will be wrapped in docker exec so they are run inside the container. Other steps (such as test reporting) run unmodified: they can still access workspace files created by build steps.

So the recordIssues step does not get run inside the container.

Any advice as to how I can go about solving this, I don’t think I’m the only person that has faced this issue.

Jenkins setup:
Jenkins: 2.477
OS: Linux - 5.15.0-119-generic
Java: 17.0.12 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)

analysis-model-api:12.5.0
ansible:403.v8d0ca_dcb_b_502
ansicolor:1.0.4
antisamy-markup-formatter:162.v0e6ec0fcfcf6
apache-httpcomponents-client-4-api:4.5.14-208.v438351942757
apache-httpcomponents-client-5-api:5.3.1-117.v4d95117cd34f
asm-api:9.7-33.v4d23ef79fcc8
authentication-tokens:1.119.v50285141b_7e1
authorize-project:1.7.2
bootstrap5-api:5.3.3-1
bouncycastle-api:2.30.1.78.1-248.ve27176eb_46cb_
branch-api:2.1178.v969d9eb_c728e
build-name-setter:2.4.3
caffeine-api:3.1.8-133.v17b_1ff2e0599
checks-api:2.2.1
cloudbees-folder:6.951.v5f91d88d76b_b_
command-launcher:115.vd8b_301cc15d0
commons-lang3-api:3.17.0-84.vb_b_938040b_078
commons-text-api:1.12.0-129.v99a_50df237f7
credentials:1378.v81ef4269d764
credentials-binding:681.vf91669a_32e45
data-tables-api:2.1.6-1
dependency-check-jenkins-plugin:5.5.1
display-url-api:2.204.vf6fddd8a_8b_e9
docker-build-publish:1.4.0
docker-commons:443.v921729d5611d
docker-java-api:3.3.6-90.ve7c5c7535ddd
docker-workflow:580.vc0c340686b_54
durable-task:577.v2a_8a_4b_7c0247
echarts-api:5.5.1-1
eddsa-api:0.3.0-4.v84c6f0f4969e
favorite:2.221.v19ca_666b_62f5
font-awesome-api:6.6.0-2
forensics-api:2.6.0
git-client:6.0.0
grypescanner:1.8
gson-api:2.11.0-41.v019fcf6125dc
htmlpublisher:1.36
instance-identity:185.v303dc7c645f9
ionicons-api:74.v93d5eb_813d5f
jackson2-api:2.17.0-379.v02de8ec9f64c
jakarta-activation-api:2.1.3-1
jakarta-mail-api:2.1.3-1
javax-activation-api:1.2.0-7
javax-mail-api:1.6.2-10
jaxb:2.3.9-1
jdk-tool:80.v8a_dee33ed6f0
job-dsl:1.89
joda-time-api:2.13.0-85.vb_64d1c2921f1
jquery3-api:3.7.1-2
json-api:20240303-41.v94e11e6de726
json-path-api:2.9.0-58.v62e3e85b_a_655
junit:1300.v03d9d8a_cf1fb_
mailer:472.vf7c289a_4b_420
mapdb-api:1.0.9-40.v58107308b_7a_7
mask-passwords:173.v6a_077a_291eb_5
matrix-project:832.va_66e270d2946
mina-sshd-api-common:2.13.2-125.v200281b_61d59
mina-sshd-api-core:2.13.2-125.v200281b_61d59
parameterized-trigger:806.vf6fff3e28c3e
pipeline-build-step:540.vb_e8849e1a_b_d8
pipeline-graph-analysis:216.vfd8b_ece330ca_
pipeline-groovy-lib:730.ve57b_34648c63
pipeline-input-step:495.ve9c153f6067b_
pipeline-milestone-step:119.vdfdc43fc3b_9a_
pipeline-model-api:2.2214.vb_b_34b_2ea_9b_83
pipeline-model-definition:2.2214.vb_b_34b_2ea_9b_83
pipeline-model-extensions:2.2214.vb_b_34b_2ea_9b_83
pipeline-rest-api:2.34
pipeline-stage-step:312.v8cd10304c27a_
pipeline-stage-tags-metadata:2.2214.vb_b_34b_2ea_9b_83
pipeline-stage-view:2.34
plain-credentials:183.va_de8f1dd5a_2b_
plugin-util-api:4.1.0
prism-api:1.29.0-17
resource-disposer:0.23
scm-api:696.v778d637b_a_762
script-security:1362.v67dc1f0e1b_b_3
snakeyaml-api:2.3-123.v13484c65210a_
ssh-agent:376.v8933585c69d3
ssh-credentials:343.v884f71d78167
ssh-slaves:2.973.v0fa_8c0dea_f9f
sshd:3.330.vc866a_8389b_58
structs:338.v848422169819
subversion:1275.va_7b_014f3fc2c
timestamper:1.27
token-macro:400.v35420b_922dcb_
trilead-api:2.147.vb_73cc728a_32e
variant:60.v7290fc0eb_b_cd
warnings-ng:11.6.0
workflow-aggregator:600.vb_57cdd26fdd7
workflow-api:1336.vee415d95c521
workflow-basic-steps:1058.vcb_fc1e3a_21a_9
workflow-cps:3964.v0767b_4b_a_0b_fa_
workflow-durable-task-step:1371.vb_7cec8f3b_95e
workflow-job:1436.vfa_244484591f
workflow-multibranch:795.ve0cb_1f45ca_9a_
workflow-scm-step:427.v4ca_6512e7df1
workflow-step-api:678.v3ee58b_469476
workflow-support:926.v9f4f9b_b_98c19
ws-cleanup:0.46
2

It does not make sense to run recordIssues within the docker step. It is sufficient to run it on the controller.

The plugin currently tries to read all affected files to create fingerprints and then it copies these files to be shown in the source code view later on. For all files it does not find it creates an error message. Is this the problem you are trying to avoid? Then we might need to add a new feature that either

  1. marks some parsers to ignore the fingerprinting (and source code copying)
  2. or filters the allowed files to fingerprint and to copy by extension (or any other algorithm)
3

That is the issue I am trying to avoid, yes.

I think the first option would be much more suited in this case. Grype scans a docker container, then jenkins tries to find the files it found inside the container, but searches on the host/agent itself. The reason it would make sense to run recordIssues within the docker step is that it would properly record the evidence that grype provides it, something that I think is quite useful.

4

I see. Please create an issue in our issue tracker, or if you are interested, also provide a PR.

5

I’d gladly create an issue, but I don’t understand whose issue this is.

As far as I understood Cloudbees maintains the docker plugin and you maintain the warnings plugin (the issue should be submitted to Jenkins JIRA). But I don’t understand which plugin restricts recordIssues from running inside a container, Docker or Warnings. That is, if we agree that there are some cases where there’s a need to run recordIssues inside a container.