The supply chain runs through your build.
NIS 2's Art. 21(2) lists the cybersecurity risk-management measures in-scope entities must take, and point (d) is supply-chain security: managing the security risks in the relationships with your suppliers and the components you depend on. For most teams the supply chain is concrete and lives in code: the dependencies you install, the versions you pin, and the scripts you trust at build time.
The shapes the same control failure takes.
Supply-chain security weakens whenever a change pulls in third-party code with less verification than before. The recurring shapes:
A remote script is piped to a shell
A build or setup step fetches a script from the internet and runs it directly (curl piped to bash), executing unverified remote code with whatever privileges the build has.
A dependency is unpinned
A pinned version is changed to a floating range or a moving tag (latest, a branch), so a future, unverified version can be pulled in silently.
An integrity check is removed
A lockfile, checksum, or signature verification that ensured you got the expected artifact is removed or bypassed to make an install work.
A new component arrives with no provenance
A dependency or image is added from an unvetted source, with no record of where it came from or who maintains it.
An internal mirror or allowlist is bypassed
A change pulls a package directly from upstream instead of the vetted internal mirror or registry, sidestepping the controls on it.
A build step that runs a remote script.
A Dockerfile needs a CLI tool. The quickest install is the vendor's one-liner that downloads and runs a script. It works, and it means every build executes whatever is at that URL, unpinned and unverified, with the build's privileges.
FROM node:22-slim+ RUN curl -fsSL https://get.example-tool.dev/install.sh | bashCOPY . /appPiping a remote script to a shell runs unverified third-party code at build time, and what that URL serves can change without you knowing. Art. 21(2)(d) (supply chain security) expects the risks in your dependencies and suppliers to be managed. Pin the tool to a specific version and verify it (a checksum or a known package), rather than executing whatever the URL returns today.
Supply-chain risk is assessed at the dependencies you actually pull.
An inspection under NIS 2 looks at how an entity manages the security of its suppliers and the components it relies on: are dependencies vetted, pinned, and tracked, and are build inputs trusted. A change that introduced an unpinned dependency or ran a remote script at build is the concrete supply-chain risk behind that, and it is visible in the diff to the manifest, lockfile, or build config.
A review, not a full supply-chain programme.
heygrc flags changes that touch a NIS 2 measure and cites the point so the fix happens in the pull request. It does not run your software-composition analysis or your supplier risk assessments. It catches the moment a change pulls in third-party code with less verification, at the diff. heygrc is in early access.