Cyber Security Quiz: Image Provenance And Dependencies
10 questions · exam conditions
0:00
Image Provenance And DependenciesQuestion 1 of 10

An organization verifies that every production image has a valid signature from its CI signing identity. An attacker compromises the CI job, modifies a source dependency before the build, and causes the job to build and sign a malicious image using its normal identity.

What is the most accurate conclusion about the assurance provided by the valid signature?

It proves the image is benign because only the approved CI identity could have signed it.
It proves who signed the image, but not that the signer or build inputs were uncompromised.
It proves the source dependency was unchanged because image signatures cover all upstream repositories.
It proves the image is reproducible because another builder can regenerate the signed digest.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Image Provenance And Dependencies

Practice Image Provenance And Dependencies in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Image Provenance And Dependencies, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An organization verifies that every production image has a valid signature from its CI signing identity. An attacker compromises the CI job, modifies a source dependency before the build, and causes the job to build and sign a malicious image using its normal identity.

What is the most accurate conclusion about the assurance provided by the valid signature?

  1. It proves the image is benign because only the approved CI identity could have signed it.
  2. It proves who signed the image, but not that the signer or build inputs were uncompromised. (correct answer)
  3. It proves the source dependency was unchanged because image signatures cover all upstream repositories.
  4. It proves the image is reproducible because another builder can regenerate the signed digest.
Explanation: When evaluating what a cryptographic signature actually guarantees, you need to separate two distinct questions: "Who signed this?" and "Was everything behind the signing trustworthy?" This distinction is at the heart of supply chain security. A digital signature on a container image is fundamentally an attestation of identity and integrity at signing time — it confirms that a specific key (here, the CI identity) produced a particular artifact. It says nothing about the security of the process that created what was signed. In the scenario, the attacker didn't steal the signing key or forge a signature; they poisoned the build inputs before the legitimate CI job ran. The CI system then faithfully signed the malicious result using its valid identity. The signature is cryptographically genuine — and completely misleading about trustworthiness. This makes B correct: the signature proves who signed, but not that the signer's environment or upstream dependencies were clean. A commits the classic conflation error — equating "authentic identity" with "benign content." A legitimate signer can unknowingly sign malicious code, exactly as this scenario demonstrates. C is factually wrong. Image signatures cover the final image digest, not the upstream source repositories or dependency trees. Supply chain integrity tools like SLSA provenance or SBOMs are separate mechanisms designed for that purpose. D confuses signing with reproducibility. Reproducible builds are an independent property; a signed image has no inherent reproducibility guarantee, and reproducibility wouldn't imply security of inputs anyway. Your study tip: whenever you see "signature proves the image is safe," pause — signatures prove authenticity, not correctness. Always ask what layer of the pipeline the control actually covers.

Question 2

Two isolated build services receive the same source commit, lockfile, base-image digest, build instructions, and declared toolchain versions. Both claim to perform deterministic builds. Their resulting image manifest digests differ.

What is the strongest inference that can be made from this result?

  1. At least one build used an undeclared difference or introduced nondeterminism that requires investigation. (correct answer)
  2. The image with the earlier creation timestamp necessarily has the more trustworthy dependency set.
  3. The differing digests prove that one registry altered the application files after they were signed.
  4. The source commit cannot be authentic because authentic source always produces identical container layers.
Explanation: When evaluating reproducible/deterministic builds, the core idea is that identical inputs should always produce bit-for-bit identical outputs. If they don't, something in the build environment deviated — whether intentionally or accidentally. This question tests whether you can reason carefully about what a digest mismatch actually proves versus what it merely suggests. If two builds claim to be deterministic but produce different image manifests, the strongest and most defensible inference is A: at least one build introduced something undeclared or nondeterministic. This could be an embedded timestamp, a floating dependency, an untracked environment variable, or a subtle toolchain difference. The key word is "strongest inference" — you don't need to know which build failed, only that something deviated from true determinism somewhere, and that warrants investigation. B is wrong because creation timestamps have no relationship to dependency trustworthiness. An earlier timestamp doesn't mean the dependencies are safer or more legitimate — this conflates metadata with security posture. C is wrong because a digest mismatch between two build outputs doesn't implicate registry tampering. The images were never identical to begin with, so there's no post-signing alteration to infer. Registry tampering would be detected by comparing a stored signed digest to a retrieved image — not by comparing two separate builds. D is wrong because it reverses the logic. Authentic source code does not guarantee identical container layers — determinism depends on the entire build environment, not just source authenticity. Blaming the commit is an unsupported leap. Your study tip: when a question uses "strongest inference," eliminate answers that make specific or unsupported claims. The correct answer will be the most logically conservative conclusion the evidence actually supports.

Question 3

A cluster currently admits any image carrying a cryptographically valid signature from the organization's broad CI identity. Both experimental and production workflows use that identity. Security wants to ensure that admitted images came from the reviewed repository, approved workflow, and protected branch.

Which policy improvement most directly provides the desired assurance?

  1. Accept the signature only when the image also has no vulnerabilities reported by the current scanner.
  2. Verify signed provenance predicates for source repository, workflow identity, branch, and output digest. (correct answer)
  3. Allow only image tags containing prod, because the CI service controls repository naming conventions.
  4. Verify that the registry uses TLS and retains access logs for all image downloads.
Explanation: When a question asks about supply chain integrity — ensuring an artifact came from a specific, trusted source — you should think about provenance: cryptographic proof of where something was built, how, and from what. A broad, shared signing identity tells you only that someone with the organization's CI key signed the image; it says nothing about which repository, workflow, or branch produced it. Option B directly solves this by verifying signed provenance predicates — structured, signed metadata (think SLSA provenance attestations) that cryptographically bind the image digest to a specific source repository, workflow identity, and branch. Because these predicates are signed, an attacker cannot forge them without the signing key, and each field is individually verifiable. This gives the policy the three-way check security wants: right repo, right workflow, right branch. Option A confuses vulnerability scanning with provenance. A clean scan tells you the image has no known flaws, not that it came from an approved source — a malicious image from an unapproved workflow could still pass a scanner. Option C relies on a naming convention, which is a weak, easily spoofed control. Any CI job can produce a tag containing "prod"; this is convention-based, not cryptographically enforced. Option D addresses transport security and audit logging — important for confidentiality and forensics, but these controls say nothing about where the image originated at build time. The study tip here: when the scenario involves trusting build origin, the answer almost always involves signed attestations or provenance, not scanning, naming rules, or network controls. Those are separate security layers.

Question 4

A Dockerfile uses FROM trusted/base:latest. Build 1 records the resulting application image digest but not the resolved base-image digest. Before Build 2, the publisher moves latest to a newer base. The application source and Dockerfile remain unchanged, but Build 2 produces a different image.

Which missing evidence most limits the team's ability to explain the changed output?

  1. A record of the tag spelling, because tag text uniquely identifies the publisher's original content.
  2. A scan of Build 2, because equal vulnerability results would prove the two bases were identical.
  3. A record of the resolved base digest for each build, linking each output to its exact dependency. (correct answer)
  4. A TLS certificate from the registry, because it identifies every layer previously served under the tag.
Explanation: When reasoning about software supply chain integrity, the central question is always: can you reconstruct exactly what went into each build? A container image tag like latest is a mutable pointer — it can silently redirect to a different underlying image at any moment. The only stable identifier for a specific image is its content-addressed digest (e.g., a SHA-256 hash), which is permanently tied to the exact bytes of that image. This is why C is correct. If the team had recorded the resolved base-image digest for both builds, they could immediately compare the two values. Matching digests would confirm identical bases; differing digests would pinpoint that the base changed — and when. Without that record, the team cannot distinguish between "the base changed" and "something else changed," making the root cause opaque. A is wrong because the tag spelling (latest) is already known and clearly documented in the Dockerfile. Tags are mutable references, so recording the text of a tag tells you nothing about what content that tag resolved to at build time — it provides zero additional forensic value. B is wrong because running a vulnerability scan on Build 2 alone cannot reconstruct what Build 1's base contained. Even if the scans matched, that would be circumstantial, not definitive — two different base images can share identical vulnerability profiles while still differing in other ways. D is wrong because a TLS certificate authenticates the channel (i.e., that you're talking to the real registry), not the content served. It carries no record of which layer blobs were previously associated with a tag. The study tip: whenever a question involves mutable references (tags, branch names, URLs), ask yourself whether a content-addressed identifier was recorded. If not, reproducibility and auditability are compromised — that gap is almost always the answer.

Question 5

A multi-stage container build compiles an application in a large builder image and copies only the resulting binary into a minimal final image. The final image scan finds no compiler or package manager. The builder image was later discovered to contain a malicious compiler that modified generated binaries.

Which statement best characterizes the remaining risk?

  1. There is no remaining risk because components absent from the final filesystem cannot influence it.
  2. The final image is safe if its runtime base has no vulnerabilities rated high or critical.
  3. The compiler is irrelevant unless the builder image and final image share the same operating system.
  4. The final binary may be compromised, so provenance must include build-stage images and tools. (correct answer)
Explanation: When you see a question about supply chain security and container builds, think carefully about where compromise can occur versus where it can be detected. A multi-stage build is not a security boundary — it's a build optimization. If a malicious tool operates during compilation, its damage is baked into the artifact it produces, not stored alongside it. This is exactly why D is correct. A tampered compiler can silently modify the binary it generates — injecting backdoors, removing security checks, or altering logic — before that binary ever lands in the final image. The final image scanner sees a clean filesystem with no compiler present, but the binary itself is already poisoned. True security assurance requires provenance: a verifiable chain of custody that includes not just the final image, but every build-stage image, tool, and compiler used to produce it. Without that, your scanner gives you a false sense of safety. Choice A is dangerously wrong because it assumes risk only lives in files present in the final image. The threat already executed during the build; its artifact remains. Choice B compounds the same mistake — runtime base vulnerabilities are irrelevant if the application binary itself is the compromised component. Patching the base doesn't un-poison the binary. Choice C introduces a red herring: the operating system shared between stages has nothing to do with whether a malicious compiler can corrupt output. The compiler's damage happens at build time regardless of OS lineage. Your study takeaway: on supply chain questions, always trace the full artifact lifecycle. "Not present in the final image" does not mean "had no effect." Provenance must cover every stage.

Question 6

An approved image and its signature are copied from a private registry to a disconnected registry. The copy process preserves every image manifest and layer byte, so the destination manifest digest is identical. The signature format identifies its subject by manifest digest, while admission trusts the original builder's identity rather than a registry hostname.

What should admission control conclude about the copied image?

  1. Reject it because moving an image to any new registry necessarily changes its cryptographic identity and invalidates prior signatures.
  2. Accept it solely because the destination repository name matches the original repository name, indicating the same publisher.
  3. Reject it unless the disconnected registry replaces the original builder's signature with its own, registry-issued signature.
  4. Accept it if the original signature verifies for the preserved digest and all policy predicates still hold. (correct answer)
Explanation: When you see questions about image signing and admission control, focus on what the signature actually binds to — a cryptographic digest, not a location. Modern container signing schemes (like Sigstore/cosign or Notary v2) attach signatures to a manifest digest, which is a content-addressable hash of the image's layers and metadata. If every byte is preserved during the copy, the digest is identical — and so is the signature's validity. That logic confirms D is correct. Because the passage explicitly states the copy preserves every manifest and layer byte (so the digest is unchanged), and because the signature identifies its subject by manifest digest rather than registry hostname, the original builder's signature remains cryptographically valid. Admission control should verify the signature against the digest and evaluate whatever policy predicates apply (e.g., permitted signers, vulnerability scan results). If both checks pass, the image should be accepted. A is wrong because it assumes moving an image changes its cryptographic identity — it does not, as long as the content is faithfully copied. The digest is content-addressed, not location-addressed. B is wrong because repository name alone proves nothing cryptographically; a name can be spoofed or reused, and admission control anchors trust to verified signatures, not naming conventions. C is wrong because requiring the registry to re-sign with its own credentials would replace the builder's identity rather than verify it — this contradicts the stated policy of trusting the original builder's identity. Your study tip: always ask "what does the signature actually bind to?" If it binds to a digest and the digest is preserved, the signature travels with the image regardless of where it's stored.

Question 7

A team changes its Dockerfile from FROM vendor/runtime:3 to FROM vendor/runtime@sha256:approvedDigest. Months later, the vendor publishes a patched release under the runtime:3 tag, but the team's automated builds continue using the pinned digest.

Which statement best describes the security tradeoff introduced by this change?

  1. Digest pinning improves build input integrity but requires an explicit process to adopt patched base images. (correct answer)
  2. Digest pinning automatically follows trusted patches while rejecting only untrusted changes to the tag.
  3. Digest pinning removes dependency risk because every package in the base image becomes independently verified.
  4. Digest pinning protects only network transport and has no effect on build reproducibility or provenance.
Explanation: When you see a question about container image pinning, think about the classic security tradeoff between integrity and updatability. Pinning a build input to a specific cryptographic digest guarantees you get exactly what you approved — nothing more, nothing less. The question is asking you to recognize both sides of that coin. Digest pinning works by replacing a mutable tag (like runtime:3, which the vendor can silently update) with an immutable SHA-256 hash tied to one specific image layer set. This eliminates supply-chain attacks where a tag is hijacked or quietly modified. However, immutability cuts both ways: when the vendor ships a legitimate security patch under the same tag, your pinned builds are blind to it. You must explicitly update the digest in your Dockerfile to adopt the fix. Answer A captures this precisely — integrity is gained, but patch adoption becomes a deliberate, manual process rather than an automatic one. Answer B is wrong because digest pinning makes no distinction between "trusted" and "untrusted" changes — it rejects all changes, including legitimate patches. There is no mechanism that selectively follows vendor security fixes. Answer C is wrong because pinning the base image digest does not independently verify individual packages inside that image. Packages can still have vulnerabilities; the digest only proves the image layer hasn't changed. Answer D is wrong in both directions — digest pinning strongly affects build reproducibility and provenance, and its protection extends well beyond transport security to the entire supply chain. Study tip: On security exams, whenever a control offers strong integrity guarantees, ask yourself what operational burden it introduces. Security tradeoffs almost always involve a cost — find it.

Question 8

A deployment manifest references registry.example/app:stable. The approved build system signed the manifest digest currently associated with that tag. After approval, an administrator moves the stable tag to a different, unsigned image manifest.

Which admission-control behavior most directly prevents the substituted image from being deployed?

  1. Resolve the tag, then require a trusted signature whose subject is the resolved manifest digest. (correct answer)
  2. Require the tag name to match an approved naming pattern before resolving the manifest.
  3. Scan the resolved image and admit it when no known critical vulnerabilities are detected.
  4. Require transport encryption when the node retrieves the image associated with the tag.
Explanation: When you see questions about supply-chain integrity and image signing, focus on what is actually being verified and when. The core threat here is tag mutability: a tag like stable is just a pointer that can be silently redirected to any image, making it an unreliable security anchor on its own. The only admission-control behavior that directly neutralizes this attack is A. By first resolving the tag to its current manifest digest, then requiring a trusted cryptographic signature whose subject is that specific digest, the system catches the substitution immediately. The administrator moved the tag to an unsigned image, so when the admission controller checks for a valid signature over the new digest, none exists — deployment is denied. The signed approval is bound to a content-addressed digest, not a mutable tag name. B is wrong because pattern-matching on tag names (e.g., requiring "stable" or "v*") says nothing about which image that tag currently points to. An attacker or errant admin can redirect any validly named tag to malicious content. C is wrong because vulnerability scanning addresses known CVEs, not provenance or integrity. A clean-but-unsigned image passes a CVE scan while still being an unauthorized substitution — the threat here is about trust, not patch level. D is wrong because transport encryption (TLS) protects the image in transit from eavesdropping, but it does nothing to verify that the image served by the registry is the one that was approved. A useful pattern to remember: signatures bind to digests, not tags. Any admission policy that stops at the tag name without checking a digest-bound signature is vulnerable to tag-redirect attacks.

Question 9

A container image's software bill of materials lists application package web-framework and its transitive library parser-lib version 2.4. The application team did not declare parser-lib directly. A critical vulnerability is later reported in version 2.4, but the top-level dependency file still lists only web-framework.

Which response best addresses the dependency risk while preserving useful provenance evidence?

  1. Ignore the finding because only dependencies directly declared by the application affect image risk.
  2. Remove parser-lib from the SBOM because the framework, rather than the application, selected it.
  3. Trace which build input introduced parser-lib, update or constrain the dependency chain, and rebuild the image. (correct answer)
  4. Retag the existing image after updating the top-level dependency file without rebuilding its layers.
Explanation: When a question involves software supply chain security and SBOMs (Software Bills of Materials), focus on two principles: full dependency visibility and provenance traceability. An SBOM's value comes precisely from exposing transitive dependencies — libraries your code uses indirectly through other libraries — which means vulnerabilities in those components are real risks regardless of who "chose" them. Option C is correct because it follows the right remediation workflow. You trace the dependency chain to identify that web-framework introduced parser-lib 2.4, then either update web-framework to a version that pulls in a patched parser-lib, or explicitly constrain the transitive dependency to a safe version. Critically, you rebuild the image so the fixed library is actually baked into the new layers — and the SBOM now reflects accurate, updated provenance. Option A is dangerously wrong. Transitive dependencies run in your container just as much as direct ones. A vulnerability in parser-lib can be exploited regardless of whether your team explicitly requested it. Attackers don't care who declared the library. Option B destroys the very evidence you need. Removing parser-lib from the SBOM doesn't remove it from the image — it just makes you blind to a real risk. Provenance records exist so you can find and fix issues like this. Option D is a classic "security theater" trap. Retagging an image changes its label, not its contents. The vulnerable parser-lib 2.4 remains in the unchanged layers, so the risk is entirely unaddressed. Study tip: On supply chain security questions, always ask "does this action actually change what runs in the container, or does it just change what we call it?" Real remediation requires rebuilding.

Question 10

During a container build, a package manager is instructed to install dependency acme-utils without a version lock or source restriction. The internal package repository is temporarily unavailable, and the package manager retrieves a newer package with the same name from a public repository. The build completes and produces a signed image.

Which control would most directly reduce this dependency-substitution risk while improving provenance?

  1. Use a lockfile with expected versions and hashes, and restrict resolution to approved repositories. (correct answer)
  2. Sign the completed image again with a second key after the build has successfully finished.
  3. Assign the image a unique tag so later deployments do not confuse it with earlier releases.
  4. Scan the image only for operating-system vulnerabilities before allowing it into the registry.
Explanation: When a build system fetches dependencies without constraints, you're trusting the package ecosystem to be safe — and that's exactly the attack surface this scenario exploits. This is a dependency confusion (or substitution) attack, where an attacker publishes a malicious package under the same name on a public registry. The key concept being tested is supply chain provenance: ensuring you know what was built and from where. A is correct because it addresses the root cause directly. A lockfile pins exact versions and cryptographic hashes, so any tampered or substituted package will fail hash verification before it's ever installed. Restricting resolution to approved repositories means the build never even queries the public registry as a fallback. Together, these controls prevent substitution and provide a verifiable record of what went into the image — that's provenance. B is a distractor that sounds security-minded. Re-signing an image only asserts who signed it, not what's inside it. You'd just be cryptographically vouching for a potentially compromised artifact. C addresses deployment confusion, not supply chain integrity. Unique tags help operations teams track releases but do nothing to verify the contents of the image or prevent malicious packages from being included during the build. D is too narrow. OS-level vulnerability scans won't catch a malicious application-layer dependency that doesn't match a known CVE — especially a newly injected package that may not yet appear in any vulnerability database. A useful mental shortcut: when a question involves where a component came from or whether it's been tampered with, think lockfiles, hashes, and repository allowlists — not signing, tagging, or post-build scanning.