From pull request to npm: protecting secrets and publishing rights

npm is changing trusted publishing configurations while GitHub adds a merge condition related to exposed secrets. These two announcements do not form one lock: merge rights, publishing identities and distribution approval must be examined separately.

Two announcements, two decision points

On 3 September 2026, npm announced general availability of multiple trusted publishing configurations per package. They are independent and additive: matching one may be sufficient, with no guaranteed evaluation order. Pending status is proposed by default; direct publishing is an option specific to each configuration. Approval of a pending package becomes possible once malware analysis is finished. That analysis already existed. [npm announcement]

On 9 September, GitHub presented in public preview a rule for GitHub Secret Protection or GitHub Advanced Security customers: before merge, the head commit scan must be complete and no relevant alert introduced by pull-request commits may remain open. Detected categories are configurable and bypass rights must be reviewed. This rule complements protection when code is pushed; it does not replace it. [GitHub announcement]

Describing every right before the delivery chain

CI/CD means continuous integration and continuous delivery: the chain that builds, checks and distributes software. A pull request is a proposed change; a workflow is a set of automated steps. OIDC, OpenID Connect, identifies the workflow here with a short-lived token. That identity alone does not describe all team permissions.

The review proposed by Partitech starts with possible paths: repository, workflow, environment, owner and possibility of direct publishing. An additional configuration must have an owner and a justification. Also retain accounts and mechanisms that can bypass the nominal path, instead of limiting the inventory to the most visible automation file.

An OR model between configurations, not double validation

In this fictional example, A denotes the stable workflow configuration and B the prepublication one. The table only illustrates matching the OIDC token to configurations. It does not replace other controls and does not mean the package immediately becomes public.

Human approval of the pending package is a separate step: it is not the second term of this OR condition. During review, ask for every path what evidence is retained, who can change its criteria and what decision justifies any direct publishing.

Linking evidence without confusing controls

A closed alert does not attest that a secret was revoked. Depending on the provider concerned, document revocation or rotation, check affected uses and retain the handling decision. An absence of alerts means only that no relevant alert is open in the controlled scope; it does not prove exhaustive detection.

The proposed design separates change review, secret scanning, application testing, npm identity, pending status and approval. Each step retains its owner and evidence. No atomic sequence between merge and publication is assumed. The explicit-trust principle echoes our article on agent writes and their isolated environment, but the rights studied here are GitHub/npm delivery rights.

For an authorized, isolated pilot, prepare fictional identities and a demonstration package: no matching configuration, one match, multiple matches, analysis still in progress and a merge exception. Define what should be accepted or refused at every step, then collect the results actually obtained. None of these scenarios has been run for this article; no real secret or production package is needed for documentation preparation.

The review deliverable is the matrix of paths, with owners, exceptions and missing evidence. Revisit it after each workflow change. The GitHub preview, detection limits and residual permissions remain items to monitor; the number of controls alone does not measure delivery security.