Files field restricts published contents
Why it matters
Without a files allowlist or .npmignore, running npm publish sends your entire repository — test fixtures, CI configs, editor settings, source TypeScript, internal tooling, and potentially .env.example files — to every consumer who installs your package. ISO 25010 confidentiality is directly impacted: internal implementation details that weren't meant to be public are now permanently embedded in a versioned npm release. SLSA L2 requires artifact provenance; publishing unpredicted files breaks that guarantee. Bloated packages also slow installs for all downstream users.
Severity rationale
High because the absence of a `files` allowlist exposes internal source code, test fixtures, and configuration files to all npm consumers permanently, with no way to remove them from published versions.
Remediation
Add a files allowlist to package.json restricting publication to only built output and essential metadata.
{
"files": [
"dist",
"README.md",
"LICENSE"
]
}
Verify what gets published before releasing: npm pack --dry-run prints every file that would be included. Anything outside dist/, README.md, and LICENSE should raise a question. The files allowlist is safer than .npmignore — new directories are excluded by default rather than accidentally included.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the SDK / Package Quality Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · security.confidentiality — Confidentiality — avoid publishing internal source/config files
- ssdf:800-218 · PS.3.2 — Archive and protect each software release
- slsa:1.0 · L2 — SLSA L2 — controlled publish process limits artifact scope
Taxons
History
- 2026-04-18·v1.0.0·Initial import from sdk-package-quality·automated