What Is Package Integrity? Definition and Best Practices

Package integrity in software development is the assurance that a code package—whether from npm, PyPI, Maven, or another registry—is authentic, unmodified, and contains exactly what its maintainers intended to publish. When a package has integrity, what you downloaded matches what the author released, with no tampering during distribution.

If you searched for "package integrity" expecting information about sterile seals and vacuum decay testing, you're in the wrong place (but you're not alone—that's the more common usage in pharma and medical devices). This article covers the software side: how to verify that your dependencies haven't been compromised, the common attack vectors that threaten package integrity, and practical methods for implementing integrity checks in your CI/CD pipeline.

What is package integrity in software development

Package integrity in software development means that a software package—from npm, PyPI, Maven, or another registry—is authentic, unmodified, and contains exactly the code its maintainers intended to publish. When a package has integrity, what you downloaded matches what the author released, with no tampering during distribution.

If you arrived here expecting information about physical packaging integrity, you're not alone. In pharmaceuticals and medical devices, "package integrity" typically refers to seal testing and sterile barriers that protect contents from contamination. In software, the concept is similar but the verification methods are entirely different: cryptographic hashes and digital signatures rather than vacuum decay tests.

A software package is considered "intact" when its contents can be verified through checksums, signatures, or provenance records. Think of it like a tamper-evident seal, except the seal is mathematical rather than physical.

Why package integrity matters for software supply chains

Modern applications pull in hundreds of transitive dependencies, which account for 64% of open source components in a typical application. A single compromised package doesn't just affect one project—it propagates to every downstream consumer. The event-stream incident in 2018 showed this clearly: a malicious maintainer added code targeting a specific Bitcoin wallet, and the package had millions of weekly downloads before anyone noticed.

The downstream impact of a compromised package can include:

• Unauthorized code execution: Malicious code runs with the same permissions as your application
• Credential theft: Install scripts can exfiltrate environment variables and secrets
• Build pipeline compromise: Attackers gain access to CI/CD systems and deployment credentials

Compliance frameworks increasingly recognize supply chain risk. FedRAMP, the Cyber Resilience Act (CRA), and NIST guidance now reference controls that include verifying the integrity of third-party components. Organizations subject to these frameworks often demonstrate that they're generating SBOMs and verifying dependencies come from trusted sources.

The operational challenge is that compromised packages can remain undetected for months. The longer malicious code sits in your dependency tree, the larger the blast radius when it's finally discovered.

Common package integrity threats

Malicious package injection

Attackers publish packages containing backdoors, data exfiltration code, or cryptominers directly to public registries, with over 877,000 malicious packages tracked across major registries to date. The malicious code often hides in obfuscated install scripts that execute during npm install or pip install, before your application even runs. Base64-encoded strings, dynamic imports, and network calls buried in setup routines are common patterns.

Dependency confusion attacks

When an organization uses private packages with names that don't exist on public registries, attackers can register those names publicly. If the package manager checks the public registry first, it might pull the attacker's version instead of the internal one. Security researcher Alex Birsan demonstrated this namespace collision problem in 2021, affecting companies like Apple, Microsoft, and Tesla.

Typosquatting

Attackers register packages with names similar to popular libraries—reqeusts instead of requests, lodahs instead of lodash. A single typo in a requirements file or package.json pulls in malicious code. Typosquatting attacks exploit human error—accounting for 61% of malicious packages in one peer-reviewed study—and often target packages with high download counts.

Compromised maintainer accounts

Sometimes the threat comes from inside the house. When maintainer credentials are stolen through phishing or credential stuffing, attackers can publish malicious versions of legitimate packages. The package's history looks clean, the maintainer is trusted, but a new version contains code that shouldn't be there. This attack vector is particularly difficult to detect because the package name and source appear completely legitimate.

Build system tampering

Not all integrity attacks happen at the registry level. Attackers who gain access to CI/CD systems can modify packages between download and installation, inject code during the build process, or replace artifacts after they've been verified. Build system attacks bypass registry-level protections entirely.

Package integrity testing methods

Cryptographic signature verification

Package maintainers can sign releases with GPG keys or through services like Sigstore. When you verify a signature, you're confirming that the package was published by someone who controls a specific private key. npm's registry signatures, Python's PEP 458, and Sigstore's keyless signing all provide mechanisms for this verification.

One limitation: signatures confirm authenticity, not safety. A maintainer with compromised credentials can sign a malicious package, and it will pass signature verification.

Checksum and hash validation

Lockfiles like package-lock.json, yarn.lock, and requirements.txt (with hashes) contain SHA-256 or SHA-512 checksums of package contents. When you install dependencies, the package manager can verify that downloaded content matches the expected hash. If someone tampers with a package after you've locked your dependencies, the hash won't match.

This approach catches tampering but doesn't help if you lock a malicious package in the first place.

Provenance attestation

SLSA (Supply-chain Levels for Software Artifacts) provenance traces a package back to its source repository and build system. A provenance attestation answers questions like: Was this package built from the claimed source repository? Was it built by an automated system rather than a developer's laptop? Did the build process follow expected steps?

Provenance verification is still maturing, but tools like Sigstore's cosign and the SLSA verifier are making it more accessible.

Behavioral analysis and malware detection

Static and dynamic analysis examine what a package actually does—network calls, file system access, obfuscated code patterns, suspicious install scripts. This approach catches threats that signatures and checksums miss entirely, including zero-day supply chain attacks that haven't been reported yet.

Endor Labs analyzes packages using 150+ signals of supply chain risk, covering security vulnerabilities, malicious code patterns, license compliance, project activity, and code quality. When the in-house security research team identifies a real threat, it's escalated and blocked before it reaches your codebase.

SBOM integrity validation

Software Bills of Materials (SBOMs) track all components in your application. By generating SBOMs at build time and continuously monitoring them, you can verify that declared dependencies match what's actually installed. SBOMs also enable rapid response when a previously-clean package is flagged—you know immediately which applications are affected.

Package integrity testing tools

The tooling landscape for software package integrity spans several categories, each addressing different verification layers:

Tool CategoryWhat It VerifiesExample ToolsRegistry signature verificationPackage authenticitynpm audit signatures, pip-auditLockfile integrityHash matchingBuilt into npm, yarn, pipProvenance verificationBuild attestationSLSA verifier, Sigstore cosignMalware detectionBehavioral signalsEndor Labs Malware Detection, SocketSBOM generation and monitoringComponent inventoryEndor Labs SBOM Hub, Syft

Most organizations benefit from combining multiple approaches. Signature verification confirms authenticity, lockfile hashes catch post-lock tampering, and behavioral analysis catches threats that other methods miss.

Endor Labs combines behavioral analysis, SBOM tracking, and full-stack reachability analysis. The reachability component adds important context: a flagged package that isn't actually called by your code is lower priority than one in your critical execution path.

How to implement package integrity testing in CI/CD

Pre-commit verification

The earliest place to catch integrity issues is before code enters the repository. Lockfile enforcement ensures that developers can't add dependencies without updating hashes. Signature verification at install time blocks packages that fail authenticity checks. Pre-commit hooks can scan for known malicious packages before they're committed.

Build-time integrity checks

CI/CD pipelines can include steps that verify checksums, validate provenance attestations, and scan for known malicious packages. The key decision is whether to warn or fail the build when checks fail. For high-severity issues like known malware or failed signatures, failing the build prevents compromised code from reaching production.

Continuous monitoring

Package integrity isn't a one-time check. New vulnerabilities and malware are discovered in already-installed packages regularly. Continuous monitoring alerts when a previously-clean package is flagged, so you can respond before the next deployment.

AURI, the security intelligence layer for agentic software development from Endor Labs, provides continuous monitoring across code, dependencies, and container images. When a package in your dependency tree is flagged, you know immediately—and you know whether it's actually reachable in your application.

How to evaluate package integrity tools

When selecting tools for package integrity verification, consider the following criteria:

• Detection coverage: Does it catch typosquatting, dependency confusion, and post-install malware, or only CVE-listed vulnerabilities? Many tools focus exclusively on known CVEs and miss novel supply chain attacks entirely.
• Signal-to-noise ratio: How many false positives does the tool generate? Tools that flag every package as suspicious get ignored. Look for tools that provide context about why a package was flagged and how severe the risk actually is.
• Integration points: Does it work with your registries, build systems, and CI/CD platforms? A tool that requires manual scans or separate dashboards creates friction that reduces adoption.
• Response capabilities: Can it block bad packages automatically, or does it only alert? Automated blocking prevents compromised packages from entering your codebase in the first place.
• Policy customization: Can you define risk tolerance for your organization's specific needs? Different teams have different thresholds—a fintech company might block packages with any suspicious signals, while a startup might accept more risk for faster iteration.

Strengthen package integrity with full-stack reachability

Not all dependencies are equal. A flagged package that your application never actually calls is lower priority than one in your authentication flow. Reachability analysis adds this context to integrity findings, helping you prioritize verification efforts where they matter most.

Endor Labs builds a call graph across your entire application—code, dependencies, and container images—to verify which packages are actually reachable. This approach delivers up to 95% noise reduction because every finding is backed by deterministic, reproducible evidence. When a package integrity alert fires, you know whether it's in your critical path or sitting unused in a transitive dependency.

The combination of behavioral analysis (catching malicious packages) and reachability analysis (prioritizing what matters) means security teams can focus on real risks rather than chasing alerts that don't affect their applications.

Book a Demo to see how full-stack reachability reduces noise from package integrity alerts.

FAQs about package integrity

What is the difference between software package integrity and physical packaging integrity?

Software package integrity verifies that code hasn't been tampered with using cryptographic methods like checksums, signatures, and provenance attestations. Physical packaging integrity—common in pharmaceutical, medical device, and food industries—tests seals and barriers to prevent contamination using methods like vacuum decay, dye penetration, and burst testing. The goals are similar (ensuring contents are unmodified), but the verification methods are entirely different.

How do I verify npm or PyPI package integrity?

For npm, use npm audit signatures to verify registry signatures and check that lockfile hashes match downloaded content. For PyPI, pip-audit can scan for known vulnerabilities, and you can enable hash checking in requirements files by adding --hash flags. Both ecosystems are also adopting Sigstore for keyless signing and provenance attestation.

What is package-lock.json integrity and how does it work?

The integrity field in package-lock.json contains a SHA-512 hash of the package contents. When npm installs dependencies, it downloads each package and computes its hash, then compares that hash to the value in the lockfile. If they don't match, npm refuses to install the package. This catches tampering that occurs after you've locked your dependencies.

Can package integrity testing detect zero-day supply chain attacks?

Behavioral analysis can catch malicious patterns even in packages without known CVEs—obfuscated code, suspicious network calls, unusual file system access. Signature verification alone only confirms authenticity (that the package came from who it claims), not safety. For comprehensive protection against novel attacks, you want tools that analyze what packages actually do, not just who published them.

What standards govern software package integrity?

SLSA (Supply-chain Levels for Software Artifacts) defines provenance requirements across four levels of increasing rigor. Sigstore provides transparency logs for package signing. NIST SP 800-218 (Secure Software Development Framework) and CISA guidance increasingly reference package verification in supply chain security frameworks. The Cyber Resilience Act (CRA) in Europe will require software producers to demonstrate supply chain security controls, including component verification.

‍