Architectural Question for the Gatsby Team: Hardening pipelines with ignore-scripts and sharp binaries

Everything Else
,
1

Hi everyone,

Since the Gatsby team is now part of Netlify, I wanted to bring an architectural and security-focused question to this community, as it involves the core compilation pipeline of Gatsby sites.

I am currently working on hardening our Gatsby projects against npm supply-chain risks. Following security frameworks, we want to disable install-time lifecycle scripts globally by setting ignore-scripts=true in our .npmrc. To allow necessary packages to function without introducing blind risks, we are leveraging @lavamoat/allow-scripts to implement a strict script allowlist.

The Challenge

In a standard Gatsby setup, the installation phase fails because sharp (via gatsby-plugin-sharp) requires lifecycle scripts to fetch or compile its native binaries (libvips).

While explicitly adding sharp to our allowlist unblocks local development, we want to ensure this architecture is resilient, cross-platform, and optimized before scaling it across multiple production pipelines—whether they run on Netlify, AWS S3, or standard Docker containers.

Since the experts on Gatsby’s build mechanics are here, I would love to get your insights on these platform-agnostic questions:

  1. Gatsby Ecosystem Dependencies: Beyond sharp, are there other official or common Gatsby plugins/dependencies that hiddenly rely on install/postinstall scripts to function or compile correctly?

  2. Deterministic Binary Caching: When deploying to serverless environments or stateless CI/CD runners, does overriding scripts via tools like @lavamoat/allow-scripts clash with standard npm/yarn/pnpm caching strategies for pre-compiled binaries?

  3. Best Practices for Hardening: Is there a recommended approach or a community allowlist recognized by the Gatsby team for running fully hardened builds without breaking image processing?

I appreciate any guidance or architectural best practices you can share on this!

Here is a discussion I opened on GitHub and a minimal implementation for replication if that helps.

Thanks in advance.

2

A little update on this topic: using can-i-ignore-scripts, I was able to pinpoint some packages that should be allowed in this example, and the ones that can be safely ignored.

{
    "lavamoat": {
    "allowScripts": {
      "@lavamoat/preinstall-always-fail#3.0.0": false,
      "gatsby#5.16.1": false,
+     "gatsby-plugin-sharp>sharp#0.32.6": true,
+     "gatsby>@parcel/cache>lmdb#2.5.2": true,
      "gatsby>@pmmmwh/react-refresh-webpack-plugin>core-js-pure#3.24.1": false,
      "gatsby>core-js#3.48.0": false,
      "gatsby>gatsby-cli#5.16.0": false,
+     "gatsby>lmdb#2.5.3": true,
+     "gatsby>lmdb>msgpackr>msgpackr-extract#3.0.3": true,
      "gatsby>memoizee>es5-ext#0.10.64": false,
+     "sass>@parcel/watcher#2.5.6": true,
    }
  }
}

can-i-ignore-scripts will suggest you check other packages:

You have 4 packages identified as 'check' that are not yet allowed.
  es5-ext,
  gatsby,
  gatsby-cli,
  ljharb-monorepo-symlink-test
Please review these packages and update your 
lavamoat allowlist in package.json as needed.

es5-ext and ljharb-monorepo-symlink-test can be ignored. I’m not sure whether gatsby and gatsby-cli need to be allowed.

Should I also treat build-time scripts or Gatsby lifecycle scripts as a separate risk in this scenario?

Community, or maintainers input are still appreciated.