Possiblity to run Syft on a Dockerfile

[vargenau]

What would you like to be added:

It would be nice to be able to run Syft on a Dockerfile.

Why is this needed:

Additional context:

Tern allows this.

[joshbressers]

@vargenau Do you know how tern accomplishes this?

[bureado]

In case it helps, https://github.com/tern-tools/tern/blob/main/tern/analyze/default/dockerfile/run.py

But also see moby/buildkit#2773

I would love to hear more about the use cases here. Is this something that should sit between hadolint and docker sbom? If so, why? Build tool independence? Fast inner loop? Honestly interested.

[vargenau]

@vargenau Do you know how tern accomplishes this?

I do not really know. I am testing both Syft and Tern and comparing features and results.

[joshbressers]

In case it helps, https://github.com/tern-tools/tern/blob/main/tern/analyze/default/dockerfile/run.py

That process looks very heavy and error prone. I think it would make more sense given the state of all tooling to just build a dockerfile then scan it rather than having Syft try to untangle the layers

[bureado]

In case it helps, https://github.com/tern-tools/tern/blob/main/tern/analyze/default/dockerfile/run.py

That process looks very heavy and error prone. I think it would make more sense given the state of all tooling to just build a dockerfile then scan it rather than having Syft try to untangle the layers

I tend to agree.

I'm still curious about the use cases but IMHO static analysis will be extremely limited for the SBOM use case, and anything related to packages/dependencies at that level can probably be handled (if it isn't already) by linters.

There's a spectrum of dynamic analysis options (like the buildkit one mentioned above, another one that comes to mind is docker-slim) that all basically involve building the image anyway at which point running syft over the built image yields the best results.

In general, I think trying to produce an SBOM from an otherwise non-annotated Dockerfile can only yield an "envelope" SBOM, e.g., reference the base file, reference it's part of a larger codebase but not actually get into component substance without dynamic introspection at which point the OCI image has already materialized somewhere syft can catalog it.

[bureado]

Only somehow adjacent, for future reference: https://medium.com/nttlabs/buildg-ide-90cf200abe0a

(Update) And also https://github.com/docker/scan-cli-plugin#:~:text=If%20you%20want%20more%20details%2C%20you%20can%20provide%20the%20Dockerfile%20used%20to%20create%20the%20image

[willmurphyscode]

It looks like tern is just building the image and then analyzing it: https://github.com/tern-tools/tern/blob/717ea47be7310d055b86fb1b80d39fb472c0ddbf/tern/analyze/default/dockerfile/run.py#L177

We're closing this as "not planned" because we don't think it's correct for Syft to execute docker build on a user's behalf, and we don't think there's any great way to know what a Dockerfile will do before building it. Users who need to scan a Dockerfile they trust can docker build it, and then point Syft at the resulting image.

The reason we're taking a sort of firm stance here is this: Syft is a security tool, and it doesn't trust the artifacts it's pointed at, and building a Dockerfile requires trusting it.