Hashed and Signed Components

1. Why This Topic Matters

Modern software is assembled, not written from scratch. A typical application pulls in hundreds of third-party libraries, container base images, build tools, compilers, firmware blobs and vendor binaries. Every one of those components is an opportunity for an attacker to slip malicious code into your product without ever touching your source repository. High-profile incidents such as SolarWinds Orion (a trojanised build), Codecov (a tampered bash uploader script), event-stream and ua-parser-js (hijacked npm packages) and XcodeGhost (a poisoned compiler) all share a root cause: consumers trusted a component without being able to prove what it was and who it came from.

Hashing and digital signing are the two foundational cryptographic controls that let an organisation answer those questions. In the CSSLP Common Body of Knowledge, this material sits in the Secure Software Supply Chain domain, but it is also tested through the lenses of Secure Software Concepts (integrity, authenticity, non-repudiation), Secure Software Implementation (cryptographic failures), Secure Software Deployment (release integrity), and Operations (patch and update verification). Expect the exam to probe whether you can distinguish what a hash proves from what a signature proves, and whether you know how to apply each at the right point in the acquisition, build and release lifecycle.

2. What Hashed and Signed Components Are

2.1 Cryptographic Hashing
A cryptographic hash function takes an input of any size (a file, a package, a container layer, a commit) and produces a fixed-length output called a digest, fingerprint or message digest. A secure hash function has three essential properties:
• Pre-image resistance - given a digest, it is computationally infeasible to find an input that produces it.
• Second pre-image resistance - given an input, it is infeasible to find a different input with the same digest.
• Collision resistance - it is infeasible to find any two different inputs with the same digest.
Combined with the avalanche effect (a one-bit change in the input changes roughly half of the output bits), these properties make a hash an excellent integrity check: if the digest you compute matches the published digest, the artifact has not changed.

Current acceptable algorithms are the SHA-2 family (SHA-256, SHA-384, SHA-512) and SHA-3. MD5 and SHA-1 are cryptographically broken for collision resistance and must not be used for security assurance, even though you will still see them used for simple corruption detection. Note also that a checksum or CRC is not a cryptographic hash; it detects accidental corruption but is trivially forged.

Key limitation: a hash by itself proves only that this bit string equals that bit string. It does not tell you who produced the artifact. If an attacker can replace the file, they can usually replace the published hash too, especially when the hash is hosted on the same server as the download. Integrity without authenticity is a half-measure.

2.2 Digital Signatures
A digital signature binds an artifact to an identity using asymmetric (public-key) cryptography. The publisher computes a hash of the artifact and then encrypts that hash with their private key. The result is the signature. Anyone holding the publisher's public key can decrypt the signature, recover the original digest, independently hash the artifact, and compare. A match proves two things at once:
• Integrity - the artifact has not been altered since signing.
• Authenticity - it was signed by whoever controls the private key.
If the private key is properly protected and uniquely held, the signature also supports non-repudiation: the signer cannot plausibly deny having produced the artifact.

Common signing algorithms are RSA (2048-bit minimum, 3072 or more preferred), ECDSA and EdDSA (Ed25519). Signatures are usually anchored in a Public Key Infrastructure (PKI), where a Certificate Authority vouches that a given public key belongs to a given publisher by issuing a code-signing certificate. Extended Validation (EV) code-signing certificates require hardware-backed key storage and stricter identity vetting, and many platforms give them a higher trust level.

2.3 The Relationship Between the Two
Hashing is a building block of signing. You never sign a multi-gigabyte installer directly; you sign its hash. This is why a weak hash algorithm undermines a signature even when the asymmetric key is strong: if an attacker can craft a malicious file that collides with the legitimate file's hash, the legitimate signature validates the malicious file. Exam questions sometimes test exactly this dependency.

3. How It Works Across the Supply Chain

3.1 On the Producer Side (Signing)
• Build the artifact in a controlled, ideally reproducible build environment so that independent parties can regenerate the same hash from the same source.
• Generate the digest with an approved hash algorithm.
• Sign the digest with a private key held in an HSM or a cloud key-management service; the key should never sit on a developer workstation or in a build script.
• Apply a trusted timestamp from a Time Stamping Authority. This proves the signature was made while the certificate was valid, so the signature remains verifiable after the certificate expires and allows clean revocation of a key without invalidating every historical release.
• Publish the artifact, the signature and the hash through separate or well-protected channels, and publish the public key or certificate through a channel the attacker is unlikely to control simultaneously.
• Record the signing event in an audit log and, increasingly, in a transparency log.

3.2 On the Consumer Side (Verification)
• Obtain the artifact.
• Obtain the publisher's public key or certificate from a trusted source and validate the certificate chain up to a trusted root.
• Check certificate revocation status via CRL or OCSP.
• Verify the signature over the artifact, which implicitly verifies the hash.
• Reject, quarantine and alert on any failure. A verification failure is a security event, not a nuisance to be clicked through.
• Perform this verification automatically in the dependency resolver, CI/CD pipeline, container registry and deployment tooling, not just by hand on a laptop.

3.3 Where You Encounter It
• Operating system and platform signing: Microsoft Authenticode, Apple notarisation and Gatekeeper, Android APK signing, Linux package signing with GPG (RPM, APT), UEFI Secure Boot, kernel module and driver signing.
• Package ecosystems: npm, PyPI, Maven Central, NuGet and RubyGems publish digests and increasingly signatures; lock files such as package-lock.json pin dependency versions to specific integrity hashes so that a later tampered upload cannot silently replace what was tested.
• Container images: content-addressable image digests (sha256:...), Docker Content Trust and Notary, and Sigstore/cosign for keyless signing tied to an identity with signatures recorded in the Rekor transparency log.
• Source control: Git commit and tag signing (GPG or SSH) to prove who authored a change and that history has not been rewritten.
• Build provenance frameworks: SLSA (Supply-chain Levels for Software Artifacts) and in-toto require signed attestations about how, where and from what an artifact was built, extending signing from the final binary back through every step.
• Update frameworks: TUF (The Update Framework) uses multiple signed metadata roles, thresholds and expiry to resist key compromise, rollback and freeze attacks on update channels.
• SBOMs: a Software Bill of Materials (SPDX, CycloneDX) lists components and their hashes; signing the SBOM itself ensures the inventory you are relying on is genuine.

3.4 Related Mechanisms You Should Not Confuse
• HMAC (Hash-based Message Authentication Code) uses a hash plus a shared symmetric secret. It gives integrity and authenticity between two parties who both hold the key, but not non-repudiation, since either party could have generated it. It is not suitable for publicly distributed software.
• Encryption provides confidentiality, not integrity. An encrypted but unsigned artifact can still be tampered with (bit-flipping) in ways that may go unnoticed.
• Salted hashes are for password storage, where the goal is to defeat precomputed attacks. Salting is irrelevant to artifact integrity.

3.5 Threats These Controls Address, and Residual Risks
Hashing and signing defend against man-in-the-middle substitution during download, mirror and CDN compromise, tampered backups and archives, repository account takeover (when combined with strong key custody), and silent version replacement. They do not defend against a legitimately signed artifact that is itself malicious (the SolarWinds case: the build was compromised before signing), a stolen or leaked signing key, a publisher that signs whatever the build produces without review, or a consumer that fails to verify. This is why the CSSLP treats signing as one layer in a defence-in-depth supply-chain programme alongside vendor assessment, build-environment hardening, provenance attestation, SBOM review, vulnerability scanning and least-privilege access to publishing credentials.

4. How to Answer Exam Questions on This Topic

CSSLP questions are scenario-based and often ask for the best, most appropriate or first action. Use the following reasoning framework.

Step 1 - Identify which security property the question is really asking about.
• Only need to know a file is unchanged? Hash.
• Need to know it is unchanged and who published it? Digital signature.
• Need the publisher to be unable to deny it? Digital signature with a protected private key, ideally timestamped.
• Need secrecy? Encryption, not hashing or signing.
• Two systems sharing a secret need tamper detection? HMAC.

Step 2 - Check the key direction. Signing uses the sender's private key; verification uses the sender's public key. Any answer that says the publisher signs with a public key, or that the recipient verifies with their own private key, is wrong. Encryption for confidentiality is the reverse: encrypt with the recipient's public key.

Step 3 - Evaluate the trust anchor. A hash posted on the same web page as the download, with no signature, provides only accidental-corruption detection against a capable adversary. A signature is only as strong as the trust in the public key, so look for answers mentioning certificate chain validation, revocation checking, obtaining keys out-of-band, or trusted roots.

Step 4 - Apply algorithm hygiene. Prefer SHA-256 or stronger and RSA 2048+/ECDSA/EdDSA. Treat MD5 and SHA-1 as unacceptable for security decisions. If a question describes a strong signature over an MD5 digest, the weak hash is the vulnerability.

Step 5 - Favour automated, lifecycle-integrated controls. The CSSLP consistently rewards answers that build verification into the pipeline (dependency resolvers, CI/CD gates, admission controllers, update agents) over manual checks, and that address the process (key custody, timestamping, reproducible builds, provenance) over a single technical fix.

Step 6 - Remember the limits. If a scenario describes malware that was signed by a legitimate vendor key, the lesson is that signing does not validate content; the correct response involves securing the build environment, protecting keys, provenance attestation and detection, not simply adding another signature.

5. Exam Tips: Answering Questions on Hashed and Signed Components

• Tip 1: Memorise the mapping: Hash = Integrity; Digital Signature = Integrity + Authenticity + Non-repudiation; HMAC = Integrity + Authenticity (no non-repudiation); Encryption = Confidentiality. Many questions are solved by this alone.
• Tip 2: When a question says a hash was published alongside the download and asks what is missing, the answer is authenticity or a digital signature from the publisher.
• Tip 3: If a scenario shows a signed component failing verification after an upgrade or redeploy, think tampering or corruption first, then expired or revoked certificate without timestamp. Never pick the answer that disables verification to make the deployment succeed.
• Tip 4: Private key compromise questions: the correct responses are revoke the certificate, rotate keys, re-sign releases, investigate what was signed during the exposure window and move keys to an HSM. Timestamped signatures made before the compromise can remain valid; those after must be treated as suspect.
• Tip 5: Lock files and pinned digests exist to guarantee that the exact component that was tested is the one that gets built and deployed. If asked how to prevent a dependency from being silently swapped between test and production, choose integrity pinning plus verification in the build.
• Tip 6: Know the vocabulary that signals modern supply-chain assurance: SBOM, SLSA, in-toto, Sigstore/cosign, TUF, Notary, reproducible builds, provenance, attestation, transparency log. Questions may describe these without naming them.
• Tip 7: Verification should happen at every trust boundary, including acquisition, ingestion into the internal artifact repository, build, release and runtime update. If offered a choice of a single verification point versus verification throughout the pipeline, choose the latter.
• Tip 8: Watch for distractors that conflate checksums (CRC32) with cryptographic hashes, or encoding (Base64) with hashing or encryption. Neither provides security assurance.
• Tip 9: In questions about responsibility, the supplier signs and publishes verification material; the acquirer is responsible for actually verifying before trusting. A contract clause requiring signed deliverables is an acquisition control; a pipeline gate that checks them is an implementation control. Read for which perspective the question takes.
• Tip 10: When two answers both seem technically correct, prefer the one that is more preventive, more automated, and more aligned with established frameworks and governance, since that reflects the CSSLP's practitioner-manager perspective.

6. Quick Review Summary
• Hashing produces a fixed-length fingerprint; any change to the input changes the digest. Use SHA-2 or SHA-3; avoid MD5 and SHA-1.
• A hash alone proves integrity, not origin. Attackers who replace a file can replace a co-located hash.
• A digital signature is an encrypted hash made with the publisher's private key and verified with the public key, providing integrity, authenticity and non-repudiation.
• Signatures depend on PKI trust, certificate validation, revocation checking, protected key storage (HSM) and timestamping.
• Verification must be automated and enforced at every stage of acquisition, build, release and update.
• Signing proves provenance of the bits, not safety of the code; pair it with secure build environments, provenance attestations, SBOMs and scanning for true supply-chain assurance.