Topic starter
11/10/2026 6:56 pm
TL;DR: A package can pass tests and still ship source maps, fixture files or credentials unless the packaging step has its own acceptance criteria, inventory check, and verification gate before publication, according to Testifysec. The control problem is release-boundary governance, not build success.
Editorial analysis by NHI Mgmt Group, based on content published by Testifysec: “Check the Package Before You Publish It”.
Key questions
Q: What breaks when package contents are not verified before publication?
A: If the archive is not checked before upload, a package can pass tests and still ship source maps, fixtures, or embedded credentials.
Q: Why do packaging controls matter when build pipelines already pass tests?
A: Tests prove behavior, not release hygiene.
Q: How do security teams know whether a publish gate is really working?
A: A publish gate is working when a deliberately disallowed file fails before registry publication and the evidence trail shows the same artefact was checked and uploaded.
Practitioner guidance
- Define package acceptance criteria Specify which files, metadata, and generated artefacts may enter a published package, and make that policy executable at packaging time rather than at code review time.
- Inspect the actual archive Use package manager inventory commands to validate the tarball or archive that will be published, not the source directory or repository tree.
- Bind verification to the publish job Require successful verification of the same artefact that the registry upload will use, and reject workflows that rebuild after verification.
Bottom line: The core risk is not failed tests but release artefacts that contain files, maps, or credentials that were never meant to ship.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/10/2026 6:57 pm
Release-content governance is the missing control layer in modern delivery pipelines: build success does not prove that the publishable artefact is safe. The article's central point is that packaging is its own security decision, with its own inputs, predicates, and enforcement boundary. Teams that treat packaging as a mechanical afterthought create a blind spot for secrets, source maps, and test artefacts that never belonged in the release.
A few things that frame the scale:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Who should control the final package upload decision?
A: The final upload decision should sit with a publishing identity that is separate from untrusted build steps and can only act after verification succeeds. That separation keeps registry credentials from being usable inside the packaging workflow and reduces the chance that a compromised build can authorise its own release.
👉 Read our full editorial: Packaging controls fail when release contents are not verified