fix: add corepack to docker image

[dcyrille18]

Description of Change

This merge request adds Corepack to the base OWASP Dependency-Check Docker image.
The goal is to provide native support for package managers such as Yarn and pnpm without requiring downstream images or CI pipelines to manually install Corepack.

This change enables:

• Use of yarn install or pnpm install directly inside the owasp/dependency-check image
• Better compatibility for projects using modern Node.js tooling
• Reduced setup time in CI where Dependency-Check is executed alongside Node-based dependency workflows

No breaking changes are introduced:
If Node.js tooling is not needed, the image behaves exactly as before.
Corepack is now enabled and used as recommended by the pnpm and yarn projects.

[dcyrille18]

This description looks LLM generated, because it mKes.assertions about the change that are already already true before the change, but i don't believe this particular point is actually correct.

Well seen, I ask to copilot to help me to write this change description because we turn around since many hours on how to get owasp working with our NodeJS project using yarn berry and corepack.

Did you test this before/after?

Yes, of course, I tested and I thought it works but after more tests, it seems not totally in this first try. Let me add a short description on what we have before:

/src $ yarn --version
1.22.22
/src $ yarn
error This project's package.json defines "packageManager": "yarn@4.13.0". However the current global version of Yarn is 1.22.22.

Presence of the "packageManager" field indicates that the project is meant to be used with Corepack, a tool included by default with all official Node.js distributions starting from 16.9 and 14.19.
Corepack must currently be enabled by running corepack enable in your terminal. For more information, check out https://yarnpkg.com/corepack.
/src $ corepack
/bin/sh: corepack: not found

And after the first MR try (not fully automated for CI/CD):

/src $ yarn --version
! Corepack is about to download https://repo.yarnpkg.com/4.13.0/packages/yarnpkg-cli/bin/yarn.js
? Do you want to continue? [Y/n] y

4.13.0

After further test, it seems that adding the environnement variable COREPACK_ENABLE_DOWNLOAD_PROMPT=false make the yarn version download totally transparent:

/src $ yarn --version
4.13.0

[dcyrille18]

Update done as requested with prepached images for yarn (v1) and pnpm (latest):

Current:

/src $ pnpm --version
10.27.0
/src $ yarn --version
1.22.22

After MR:

/src $ pnpm --version
10.33.0
/src $ yarn --version
1.22.22

This build will now allow users to install custom package managers if needed.

[marcelstoer]

I do not support this proposal. Specific extensions should be handled in downstream images that extend from ours.

[chadlwilson]

I do not support this proposal. Specific extensions should be handled in downstream images that extend from ours.

Not sure how familiar you are with the node/npm ecosystem but it’s a bit more complex than “specific extensions” in my view. We already pre-package node, npm, yarn and pnpm using disparate approaches. The ODC code for these analyzers is already “corepack compatible/aware”.

For many years (prior to Node 25) corepack was pre-distributed with all Node versions (like with npm) and for all of these alternate package managers was the recommended approach to either bootstrap or install them, and provide a mechanism to “lock” ones version manager for reproducibility. Corepack shimmed the entry point scripts and would look at the packageManager field of the adjacent package.json, look for a config and determine whether it could run a locked version from its cache, already in source control or downloadable on-the-fly, plus verifying shas etc.

In other words, prior to Node 25, one could consider corepack being installed and enabled to be a sensible default for a “Swiss army knife” image like this which already pre-packages all sorts of tools. For some reason node voted not to package it anymore, which adds friction for every single alternate package manager. It’s worth noting that this change will not graduate to LTS until April/May 2027 so for now, corepack is still “LTS”ish.

According to OP, there appears to be a gap in the ODC image at the moment that causes yarn and pnpm to not work in a corepack aware way, and our image was possibly not “caught up” when the Yarn 2+ support was finally fixed in ODC itself. I think we need to confirm what these problems are. This is important now because yarn/pnpm are directly invoked by ODC and failure to use the correct version implied by package.json will cause scanning failures.

It’s likely only an accidental side effect of Alpine’s non-standard packaging process for node/npm that corepack has not been included earlier. Most distros follow nodes official packaging and include it. Some other distros also split corepack from node, but they include a proper package for it, so you’re not installing into the npm global space (Arch, Wolfi, newer Debian). For some reason Alpine has no distinct corepack package, however provides corepack in a compliant way with the nodejs-current packages -however these current versions are not locked to lts and are otherwise unsuitable.

Now, to summarise my earlier messages, the messy bit is determining how to move forward and requires some research into whether pnpm, yarn and others will continue to recommend corepack. It doesn’t make sense for us to add it if everyone is moving away.

In retrospect it’d probably have been better to open an issue to discuss the problem before submitting a solution, but it’s not the end of the world, as there’s not too much effort here I think.

In my personal view, if corepack still has a role, rather than using npm global space, I would suggest

• moving away from Alpine towards Wolfi
  • which is similarly a minimal security focused rolling undistro, but is glibc+based
  • with fewer breaking changes than Alpine, with much higher volume throughput on packaging
  • supports patching old versions of packages without abandoning like Alpine does
  • Also uses apk, with most packages named consistently with Alpine, making migration path easy for child packages
• install corepack package in place of npm/yarn/pnpm

But I think we need to figure out exactly which combinations are not working right now with the pre-installed versions and whether corepack still has a role - before we decide to do anything.

[marcelstoer]

👍 Thanks for the effort that went into this write-up! Much appreciated.

[dcyrille18]

Hi everyone,

Due to security and performance requirements, we must upgrade to newer Yarn versions in our CI pipelines. With our current setup, this makes the official Docker image incompatible for us in its current form.

If the preferred direction is for users to maintain their own Docker images, that’s acceptable for us, but we would appreciate some high‑level guidance on the recommended way forward.

Once we align on the approach, I’m willing to handle the required development work so we can unblock usage on recent environments.

Let us know how you’d like to proceed.

[chadlwilson]

After having looked at this a bit further and testing locally, I think it makes sense to go ahead with this with some tweaks suggested in dcyrille18#1 to clean-up cache cruft left behind in the image layers.

Current image

• Yarn 1/classic is installed manually; yarn berry (2+) is not
• pnpm latest is installed
• npm from Alpine is installed

corepack direction of tools

• pnpm: corepack is still recommended https://pnpm.io/installation#using-corepack
  • community opinion still seems to be that corepack is the best option
• yarn: corepack still recommended approach https://yarnpkg.com/getting-started/install
  • users can still source control their specific yarn versions following yarn team advice if they like

Advantages

• consistency between yarn and pnpm
• we could also enable it for npm as well, to be totally consistent and better support folks using package.json packageManager/devEngines directives for npm?

Disadvantages

• need to do a global npm install since corepack is not packaged for Alpine.
  • as noted in fix: add corepack to docker image #8386 (comment) we could address this by moving to something non-Alpine, but that's essentially a breaking change so out of scope

@dcyrille18 if you could review/merge my PR-to-your-PR and go through the comments to resolve them here it will help make it easier to review for others.

[dcyrille18]

Hi @chadlwilson,
Thanks for the time you spent on this.
I’ve reviewed and merged your proposal.

[chadlwilson]

Adding some comments to explain the changes I personally added on, for maintainer review benefit.

This LGTM now and I think is a worthwhile contribution 👍

$ docker run -it --entrypoint='' owasp/dependency-check:12.2.1-SNAPSHOT sh -c "pnpm --version && yarn --version && corepack yarn@latest --version"
10.33.0
1.22.22
4.13.0

[chadlwilson]

I made these changes, just for cleanup while we are here

• we are using --no-cache so think update was intended as upgrade
• tar no longer needed
• bundle audit update needs to be done in the user context, not cached as root
• can avoid need for rdoc by using --no-document ruby install

[abhi-markan]

Worth installing corepack from package-lock.json and then running npm ci --ignore-scripts. Thanks

[chadlwilson]

That’s not how global installs work?

[chadlwilson]

Cleaning up, since Node and Ruby leave unnecessary cruft in /tmp and root's home.

[chadlwilson]

Being a good citizen be removing undocumented internet access by yarn, and disable scripts by default during yarn install for supply chain security good practices.

Also removes cache cruft that results from running node and v8.

[Copilot]

Pull request overview

This PR updates the base owasp/dependency-check Docker image to include Corepack so Yarn/pnpm can be used via Node’s package-manager tooling without requiring downstream installation steps.

Changes:

• Add COREPACK_ENABLE_DOWNLOAD_PROMPT=false and install Corepack via npm.
• Remove manual Yarn download/symlink and global pnpm install, replacing them with Corepack preparation.
• Add a post-USER layer to prefetch/activate Yarn/pnpm and write a Yarn config file.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

corepack prepare pnpm@latest yarn@latest ... is non-deterministic and can change the image contents over time (including unexpected major upgrades). Recommend pinning explicit versions (possibly via build args) and avoiding latest for release images.

[abhi-markan]

Worth tagging to a specific SHA or a version to avoid a supply-chain attack please. Thanks

[chadlwilson]

In my opinion - no. That adds additional maintenance burden that dependabot cannot help us with and will likely lead to stale versions without security fixes in the underlying software, which is of bigger risk to users.

Whose supply chain? What's the attack vector?

• For ODC's own supply chain this is within an ODC container so it poses minimal threat because the npm install is within a docker build running inside a docker buildx container which doesn't have access to anything privileged.
• For user's supply chains it poses little risk because ODC is not released constantly. It'd require extremely bad luck for the latest version at the time of a release build to contain a vulnerable version

If yarn or pnpm publishing to npm are breached the world has MUCH bigger problems than ODC as an entrance. If you can suggest a way to keep the versions updated which dependabot can handle then it’d be OK to do this, but otherwise I do not think it is worth the trade off of additional unpaid OSS maintainer work and risk of unpatched versions staying around for longer.

As I already said earlier, this PR is really not the place for this discussion since we already have unpinned npm installs here.

[chadlwilson]

If you use this image for your paid work for your employer and are still concerned and feel you can mitigate supply chain risks better yourself - you can always build your own image?