SSCP Systems and Application Security Practice Question
A financial services firm must prove that an e-commerce application's source code has not been tampered with between the build pipeline and production deployment. The pipeline already stores build artifacts in an internal repository. Which control BEST provides this assurance?
⚠ Common exam trap
The trap here is conflating provenance metadata such as an SBOM or a signed Git commit with cryptographic integrity of the deployed artifact.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Sign each build artifact with a key held by the CI/CD system and verify the signature before deployment.
Signing build artifacts in the pipeline and validating those signatures before deployment creates a cryptographic chain from the trusted build to production. If any byte changes in transit or at rest, verification fails. SBOMs, commit signing, and MFA improve visibility or access control but do not seal the artifact itself, so they cannot prove non-tampering.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Generate an SBOM in SPDX format and archive it alongside each release.
Why it's wrong here
An SBOM enumerates components and dependencies so consumers can track known vulnerabilities and license obligations. It describes what is inside the artifact but does not carry a cryptographic seal over the bytes, so an attacker who modifies the binary can regenerate a matching SBOM. Inventory transparency alone cannot prove that the deployed code matches what was built.
- ✗
Enable multi-factor authentication for all engineers who have access to the artifact repository.
Why it's wrong here
MFA strengthens authentication to the repository and reduces the chance of credential theft, which is valuable. It does not, however, detect modification of an artifact after it leaves the build system, nor does it verify that what is deployed equals what was built. Authentication controls identity, not content integrity, so the tampering requirement remains unmet.
- ✓
Sign each build artifact with a key held by the CI/CD system and verify the signature before deployment.
Why this is correct
Cryptographically signing the artifact in the pipeline and verifying that signature at deploy time binds the exact bytes to a trusted build process. Any tampering after signing invalidates the signature and blocks deployment. This is the mechanism behind sigstore/cosign and similar supply-chain integrity tools, and it directly satisfies the requirement for provable artifact integrity.
- ✗
Require developers to sign Git commits with their personal GPG keys.
Why it's wrong here
Commit signing authenticates who authored a change in the source repository and detects history rewriting. However, the deployed artifact is produced later by the build system, and nothing cryptographically binds that artifact to the signed commit. A malicious modification between build and deployment would leave the commit signature intact, so this does not meet the requirement.
Go deeper
Related to this question
About these practice questions
One of 971 original SSCP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISC2 exam blueprint
This SSCP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SSCP exam.