A source map, test fixture, internal configuration file, or credential can reach a release even when the application’s tests pass. The packaging step needs its own acceptance criteria.
The original article used the reported Claude Code source-map exposure as its example. This revision focuses on a reproducible packaging control; it does not claim to know Anthropic’s internal root cause or demonstrate that TestifySec would have prevented that incident.
Define the contents you intend to publish
Decide which files belong in the package and which do not. Source maps and TypeScript files can be legitimate release contents, so a blanket ban is a product decision, not a universal security rule.
Use your package manager’s inventory facilities to inspect the exact release artifact. For npm, consult the npm pack reference. Reviewing a source directory is not the same as reviewing the archive sent to the registry.
Capture the artifact that will be accepted
Run the packaging step in a defined environment and retain the resulting archive and its digest. If policy depends on the archive’s entries or file contents, collect those explicitly. A top-level product digest does not, by itself, enumerate everything inside a tarball or establish whether a file contains a secret.
The original simplified scripts did not establish a complete npm packaging workflow. Their CLI and policy fragments have been replaced with the maintained CI/lock instructions.
Write a policy with observable inputs
Require the data needed for the decision: the exact package, its inventory, the expected producer, and the checks you intend to enforce. Match the rule to the actual predicate schema produced by the selected release. Do not assume a field exists because it appears in an illustrative Rego snippet.
Signing a policy protects its integrity under an approved signer. It does not make the policy correct, publish it to every verifier, or activate it at a gate. Those are separate operations.
Verify before publication
The publish job must depend on successful verification of the same artifact it uploads. Observing npm publish after it has already contacted the registry is too late to prevent publication. Rebuilding after verification can also break the binding between the checked artifact and the delivered one.
Keep registry credentials outside the authority of untrusted build steps. Test what happens if evidence is missing, the inventory is incomplete, the artifact changes, or an unexpected producer signs the record.
Show both outcomes
A useful demonstration includes a clean package and a package containing an intentionally disallowed file. The second case should fail before registry publication. Preserve the package digests, policy version, evidence, and verification result so another person can inspect the basis of the decision.
That walkthrough validates a defined control in a defined environment. It does not establish that every supply-chain attack is prevented.
Read the trust architecture for producer and signing boundaries. Pushgate checks Git pushes; a package-publication gate is a separate enforcement point.