Does Anchore only analyse the first Docker image referenced in a Dockerfile

[jonico]

While scanning Dockerfiles that reference multiple Docker images, Anchore only reported findings for the first referenced Docker image used to build:

https://github.com/corona-warn-app/cwa-server/blob/7059232b48d2507d142fe683fbebdda371a98652/services/distribution/Dockerfile#L1

whereas no single finding was reported for the base of the resulting Docker image:

https://github.com/corona-warn-app/cwa-server/blob/7059232b48d2507d142fe683fbebdda371a98652/services/distribution/Dockerfile#L27

Details of the workflow run can be found in https://github.com/jonico/cwa-server/runs/763539187?check_suite_focus=true

My question is whether
a) Anchore only scans the first Docker image it finds in a Dockerfile or
b) whether the second referenced base image (gcr.io/distroless/java:11) was just flawless or
c) gcr.io/distroless/java:11 only contained a subset of the findings of the image used to build (maven:3.6.3-jdk-11) and was hence not referenced

[nurmi]

hi @jonico - I can provide some info that should help clarify!

The anchore scan action explicitly will only scan one image per invocation, which is the actual container image passed in using the 'image-reference' parameter. It is also necessary to explicitly reference the Dockerfile that was used to generate this image, if you would like for everything to line up correctly. In other words, anchore isn't actually scanning any given Dockerfile itself, it is scanning a built and present container image, and using the dockerfile-path specified Dockerfile as additional context.

Let us know if that helps clarify!

[jonico]

hi @nurmi: Thanks a lot for your explanation, I now understand what is scanned. I was fooled by the fact, that the reported security alerts explicitly refer to the first line in the Dockerfile:

Line one refers to an image that is only used for building, not for shipping (which would be the base image in line 27)

I wonder whether it would be less confusing to either mark the entire file as relevant for the finding or refer to a line which is pointing to a base image actually used in the docker image referred to in the 'image-reference' parameter.

[nurmi]

hi @jonico - I agree this is something to look into. The reason we implemented it this way (as essentially a 'marker' to the beginning of the Dockerfile) is that in our initial investigations, the UI rendered oddly when the entire file (all lines) were referenced, which washed out the CVE detail element to the point where it was not viewable. There may be a way to omit line numbers entirely - we'll be able to investigate and of course if you try some options and find something that renders well and is less specific to a line in the Dockerfile, we'd love to hear back!

[alfredodeza]

@jonico the scan-action has a new release and I don't think that the new features and changes will apply to this issue. Can you try again and let us know if you are seeing similar problems? Thanks again!

[jonico]

@alfredodeza: I played around with the latest version of your integration but could not get it to work, see my failed attempts here: https://github.com/Beer-Ops/Beer-Ops.github.io/runs/1209441020#step:4:16843

[alfredodeza]

@jonico the workflow doesn't look quite right... there is an error that mentions the following:

Error: Cannot use both 'image' and 'path' as sources

Looking at the step:

Run anchore/scan-action@v2
  with:
    image: docker.pkg.github.com/beer-ops/beer-ops.github.io/octocat-generator-docker:master
    fail-build: false
    debug: false
    acs-report-enable: true
    severity-cutoff: high
    path: .

It has to be either a path or an image. The action supports scanning a path (e.g. the current repo) or a container. Can you update to use only one of the options?

Additionally, this brings light to a probable source of confusion... would love to make it more clear in the docs. Did you find an example that had both? Or a section in the docs that didn't clarify this situation?

Finally... the action should've halted execution when it encountered this condition, vs. just continuing and producing massive output. I'll follow up with a fix for that

[jonico]

@alfredodeza: also without path it did not work for me: https://github.com/Beer-Ops/Beer-Ops.github.io/runs/1209368959#step:4:16841

[alfredodeza]

@jonico I think you can try the action from a branch instead of the v2 tag. I would suggest giving this PR a try #69 which uses the undefined-links branch: https://github.com/anchore/scan-action/tree/undefined-links

After testing it locally, I found the issue went away. Hope it works for you as well!

[jonico]

@alfredodeza: worked for me now 🎉 , but I still get a lot of verbose debug output although I set debug to false: https://github.com/Beer-Ops/Beer-Ops.github.io/runs/1291294062?check_suite_focus=true#step:4:24

[jonico]

furthermore, the new output references files that are not part of my repo and cannot be previewed:

... to me, the old format looked nicer as it referenced the line where my project was introducing the problematic docker image, especially as I cannot change the source of the problem other than upgrading to a newer docker image:

[alfredodeza]

@jonico that's great. I'll follow up with a new issue to track the verbosity (this is grype getting output without taking into account the verbosity of the action.

As for the content of the files, the problem is that the yarn.lock really doesn't exist in the current repo, and I believe there is no way to tell CodeQL the contents or how to display them. There are some missing capabilities that we need to tweak for line numbers, hope that will enhance that in the future.

Are you OK with me closing this issue now? Again, we aren't doing anything with the Dockerfile at all in this new version.

[jonico]

closing issue as the new version of Anchore do not refer to Dockerfile any more