Understanding Dependency Chain

1. The problem I’m having:

Hi Caddy Community, I’m building my own Caddy Docker image located here: caddy-docker-proxy-cloudflare/Dockerfile at main · dbrennand/caddy-docker-proxy-cloudflare · GitHub

I’m scanning the Caddy dependencies using Snyk and it’s reporting several critical vulnerabilities with plugins, but it looks to me like these are being introduced further down the dependency chain and I’m struggling to identify where in the dependency chain they’re being introduced.

I understand this isn’t directly related to Caddy, but is there any way with maybe xcaddy I can identify which top level dependency is introducing this vulnerable sub-dependency? I checked the go.mod files for the two plugins I install but I couldn’t see these vulnerable dependencies which makes me think why they’re sub-dependencies of one of these plugins.

I was thinking maybe I can generate a SBOM somehow for the project to find out but I’m not sure how to do that as I’m not massively familiar with Golang.

2. Error messages and/or full log output:

No error message per say, as mentioned above this is a generic question on how to identify sub-dependencies.

3. Caddy version:

caddy:2.10.2

4. How I installed and ran Caddy:

Built using Docker in GitHub Actions.

a. System environment:

N/A

b. Command:

c. Service/unit/compose file:

N/A

d. My complete Caddy config:

N/A

5. Links to relevant resources:

I checked the go.sum file for the caddy-docker-proxy plugin and it looks like the vulnerable dependency is being introduced there: caddy-docker-proxy/go.sum at master · lucaslorentz/caddy-docker-proxy · GitHub

EDIT: Raised a PR in the plugin repository to fix it.

Yeah that is the stupid and harmful thing about most security scanners – they’re broken.

In, I’d say about 90% of reports, Caddy never even uses the vulnerable code path.

Additionally, go.sum is not a dependency list. It is used for build integrity, but many items in the list may not even be included in the compiled binary.