Artifact Integrity Verification

Artifact integrity verification checks that downloaded dependencies match trusted cryptographic hashes or signatures. It helps detect accidental corruption and unauthorized modification in the software supply chain.

A dependency is an artifact such as a JAR, ZIP, container layer, or distribution archive. Integrity verification establishes that the bytes obtained during a build are the bytes that a trusted source intended to publish.

A cryptographic hash maps an artifact to a fixed-size digest. If the artifact changes, a secure hash such as SHA-256 should produce a different digest with overwhelming probability. Verification requires obtaining the expected digest from a trustworthy channel and comparing it with the digest calculated from the downloaded bytes.

Digital signatures provide a different assurance model. A publisher signs artifact data with a private key, and consumers verify the signature using a trusted public key. Signatures can provide publisher authentication in addition to integrity, whereas an unsigned checksum primarily proves that the artifact matches a particular expected digest.

In Java builds, dependency managers such as Maven and Gradle can perform repository and checksum-related verification, while build tooling can also enforce stronger dependency verification policies. A robust supply-chain process protects both the artifact and the source of the expected digest or trusted signing key; otherwise an attacker who can alter both the artifact and its checksum may defeat simple checksum comparison.

Key points

• SHA-256 verification detects changes to artifact bytes.
• The expected digest must come from a trusted source.
• Digital signatures can authenticate the signer as well as protect integrity.
• Dependency verification should happen before an artifact is trusted or used.
• Protecting the verification metadata is part of the security boundary.

Interview questions

Why should a Java project verify dependency artifacts?

Dependency artifacts become executable or otherwise trusted input to the build. Verification can detect corruption or unauthorized modification before the artifact is consumed. A cryptographic digest provides a compact representation of the expected bytes. The expected value itself must come from a trusted source.

What is the difference between a checksum and a digital signature?

A checksum or cryptographic digest lets a consumer compare an artifact against a known expected value. A digital signature is generated with a private key and verified with a corresponding public key. Therefore, signatures can provide evidence that the artifact was signed by the holder of the trusted private key. Both mechanisms can detect changes, but their trust and authentication properties differ.

What security problem exists if the artifact and its checksum are downloaded from the same compromised server?

An attacker controlling that server could replace the artifact and calculate a new checksum for the replacement. The consumer would then verify the malicious artifact successfully because the expected digest was compromised at the same time. The verification process therefore needs an independent root of trust, such as protected verification metadata or a trusted signing key. Integrity checks are only as strong as the mechanism used to obtain and trust their expected values.

How would you implement artifact hash verification in Java?

I would read the artifact as bytes or a stream and compute a SHA-256 digest with `MessageDigest`. I would encode the resulting digest consistently, for example as lowercase hexadecimal, and compare it with a trusted expected value. For large artifacts, I would process the file incrementally rather than loading the entire file into memory. A mismatch should fail the verification step rather than merely produce a warning.

How would you incorporate dependency verification into a Java CI/CD pipeline?

I would make dependency verification an enforced build step rather than a developer-only check. The build would resolve dependencies using trusted repositories and verify the resulting artifacts against approved checksums or signatures before compilation or packaging proceeds. Verification metadata would be reviewed and protected as part of the repository's security controls. I would also investigate unexpected changes instead of automatically accepting new artifact values.