Secure Software Supply Chain practice questions

hash-algorithm

Why it fails: Hash algorithm is a metadata attribute, not the unique identifier.

author-email

Why it fails: Author email is non-standard and not unique for automated identification.

license-id

Why it fails: License ID is for legal compliance, not unique component identification.

Incompatible library versions.

Why it fails: Incompatibility is an operational issue, not a supply chain security risk.

Excessive bandwidth usage.

Why it fails: Bandwidth is irrelevant to the security of the supply chain.

Failure to meet license requirements.

Why it fails: Licensing is a legal concern, not a code integrity risk.

Disable all outbound network access from the build server.

Why it fails: Disabling outbound access blocks runtime exfiltration but leaves the image itself unverified, so a tampered base layer still ships. Network egress control suits hardened build farms where dependencies are pre-mirrored. The stem demands provenance: signing and digest verification of every layer, which Microsoft Entra ID workload identities alone cannot supply.

Automatically pull the latest 'alpine' image during build time.

Why it fails: Pulling the latest 'alpine' image at build time introduces mutable, unverified content, so a compromised or replaced tag silently enters the build environment — the opposite of supply chain protection. It is tempting because always-current base images reduce patch lag in development pipelines, but that suits rapid iteration, not tamper-resistant golden image builds.

Rotate the build server SSH keys daily.

Why it fails: Rotating SSH keys secures interactive access to the build server, but the golden image's integrity is compromised through its own layers and dependencies, not SSH credentials. Key rotation suits hardening long-lived hosts against credential theft. Here, the control must verify image provenance and content, which key rotation leaves untouched.

Disable all caching of external packages.

Why it fails: Caching is unrelated to namespace resolution; disabling it merely forces re-fetching and adds latency without preventing a public package from shadowing an internal name. Caching would be the right target when stale artefacts cause version drift, but dependency confusion is defeated by scoping and registry precedence instead.

Use the latest version of the CLI tool regardless of security patches.

Why it fails: Upgrading the CLI does not alter package resolution; dependency confusion exploits registry precedence, not tool version. It is tempting because patched tooling is generally sound practise, and staying current would be the right choice when remediating known CLI vulnerabilities, but it leaves the private-versus-public namespace lookup order untouched.

Set the global registry to the public URL.

Why it fails: Pointing the global registry at the public URL makes public packages the default resolution source, so an attacker's higher-versioned public package wins over the internal one. Public registries are legitimately the correct global default for projects consuming only open-source dependencies, but here the private registry must take precedence.

The vendor provides a static list of libraries once a year.

Why it fails: An annual static list cannot reflect newly disclosed CVEs or components added mid-year, so it demonstrates point-in-time reporting rather than continuous monitoring. It is tempting because an inventory is a genuine governance artefact, and would be correct if the question asked for basic licence or component documentation instead of a proactive posture.

The vendor does not use any open-source software.

Why it fails: Avoiding open source entirely removes the visibility and patching discipline the question is testing; it is a procurement stance, not evidence of proactive vulnerability management. It is tempting because no open-source components means no open-source CVEs, and would be correct if the requirement were eliminating third-party code rather than demonstrating proactive security.

The vendor uses only the newest versions of all libraries.

Why it fails: Running the newest versions says nothing about whether the vendor tracks CVEs, patches promptly or monitors advisories; a freshly released library can carry an unpatched flaw. It is tempting because staying current sounds diligent, and would be valid if the question asked about version currency rather than a proactive vulnerability-management posture.

Software License Agreement (SLA)

Why it fails: A Software License Agreement is a legal contract defining usage rights and liability, containing no cryptographic evidence about the binary's contents or signer. Licence agreements are correctly used to establish commercial and legal terms with a supplier, but they cannot demonstrate that the delivered code is unaltered or genuinely from the vendor.

SHA-256 checksum published on a text file

Why it fails: A published SHA-256 checksum verifies integrity only if the hash file itself is trusted; it provides no cryptographic proof of origin, since anyone can generate a hash of altered code. Checksums are correctly used to detect accidental corruption during download, but they cannot authenticate the supplier as the signer.

Vendor SOC 2 Type II report

Why it fails: A SOC 2 Type II report attests to the vendor's control environment over a period, not to the cryptographic signature on a specific binary. Such reports are correctly used to assess organisational security posture during vendor due diligence, but they provide no artefact proving this software's integrity or origin authenticity.

Rely on the developer's ability to check spelling.

Why it fails: Manual proofreading fails because typosquatted names are deliberately designed to look identical at a glance, and human attention varies under deadline pressure. Spelling checks are a general code-review practise, but they provide no deterministic matching against a curated allowlist of approved package names.

Increase the frequency of penetration tests.

Why it fails: Penetration tests probe deployed systems for exploitable weaknesses; they do not intercept package resolution, so a malicious similarly-named package still installs. It is tempting because testing is a recognised security control, and would be correct for uncovering vulnerabilities in an application after it has been built and deployed.

Enable two-factor authentication on developer accounts.

Why it fails: Two-factor authentication verifies developer identity at sign-in; it cannot detect that a package name differs by one character from a legitimate one during dependency resolution. MFA belongs in account-takeover defence, where stolen credentials are the threat, not in the build pipeline's package-name validation.

GitHub Projects.

Why it fails: GitHub Projects is a planning board for issues and pull requests; it exposes no dependency scanning engine or workflow gate. It is tempting because it integrates with Actions and repositories, and it would be the right choice for tracking remediation tasks arising from vulnerability findings.

Git LFS.

Why it fails: Git LFS stores large binary files outside the main repository; it scans no dependencies and returns no vulnerability verdict. It is tempting because it is a standard GitHub add-on that alters build behaviour, and it would be correct when repositories contain large assets such as models or media.

GitHub Pages.

Why it fails: GitHub Pages publishes static sites from a repository; it performs no dependency analysis and cannot fail a workflow. It is tempting because it is a native GitHub feature configured through repository settings, and it would be correct for hosting project documentation or a security policy site.

Run 'npm audit fix' before every build process.

Why it fails: npm audit fix remediates known vulnerabilities in already-installed packages; it never changes which registry a package resolves from, so a public package sharing your internal name still wins. It is tempting because audit fix is the routine hygiene step after adding dependencies, and would be correct for patching disclosed CVEs in the dependency tree.

Add the dependency to the 'bundledDependencies' array in package.json.

Why it fails: bundledDependencies controls which packages ship inside a published tarball; it does not scope resolution to your private registry, so the public package is still fetched. It is tempting because bundling guarantees dependencies travel with the artefact, which is correct when deploying to environments lacking registry access.

Enable 'strict-ssl' in the global npm configuration.

Why it fails: strict-ssl only enforces certificate validation on registry connections; it does not control resolution order, so npm still queries the public registry and can install the malicious same-named package. It is tempting because strict-ssl hardens transport against interception, which is the right control when the risk is tampered or spoofed registry traffic.

To encrypt the source code repository.

Why it fails: Layouts declare supply chain steps, authorised functionaries and artefact rules; they perform no cryptographic encryption of repositories. Encryption at rest is handled by repository or disk-level controls, not in-toto metadata. A layout would be the correct artefact when you need to define and verify the sequence of supply chain operations and their signatures.

To generate the final SBOM document.

Why it fails: A layout file defines the supply chain steps, functionaries and their expected artefacts, plus signing keys; it is not an SBOM generator. SBOMs are produced by separate tooling such as Syft or CycloneDX. The layout is the policy that in-toto verifies against, so it would be the right artefact when defining who may perform which step.

To list all CVEs found in the dependencies.

Why it fails: A layout defines the supply chain's expected steps, the functionaries authorised at each, and their public keys; it is not a vulnerability inventory. CVE listing belongs to dependency scanning or software composition analysis tooling, which reports known vulnerabilities rather than supply chain policy.

Automate the patching of production servers.

Why it fails: A VDP sets out how external researchers report vulnerabilities and how the vendor acknowledges, triages and discloses them; it does not deploy patches. Patching production servers is release and configuration management. A VDP would be the right artefact when establishing coordinated disclosure terms with security researchers.

Create a list of known hardware defects.

Why it fails: A VDP concerns software vulnerability reports from external parties, not hardware defect inventories. Known hardware defects belong in asset or maintenance records. A VDP is the right instrument when defining how researchers submit software flaws and how the vendor responds within agreed disclosure windows.

Legal protection against data breaches.

Why it fails: A VDP is a public process document describing how to report vulnerabilities and what the vendor commits to; it grants no legal immunity and does not address breach liability. Data-breach legal protection comes from contracts, insurance and regulatory compliance. A VDP is correct when formalising researcher reporting channels and disclosure timelines.

The tag prevents container layer caching.

Why it fails: Image tags do not govern layer caching; Docker caches by layer digest, so ':latest' still caches normally. It is tempting because mutable tags do affect reproducibility, but the actual supply chain flaw is that ':latest' resolves to whichever image the publisher last pushed, allowing silent substitution.

The registry will throttle downloads of the ':latest' tag.

Why it fails: Public registries do not throttle ':latest' specifically; rate limits apply per account or IP regardless of tag. It is tempting because download throttling is a real registry behaviour, but the security flaw is tag mutability: ':latest' can point to a different, potentially malicious image on each pull.

The tag is deprecated in favor of ':stable'.

Why it fails: Docker has not deprecated ':latest' in favour of ':stable'; both are ordinary tags with no special status. It is tempting because ':stable' sounds like a safer convention, but the real flaw is that ':latest' is mutable, so the build pulls whatever image was pushed most recently.

Requirement for 100% code coverage in unit tests.

Why it fails: Unit test coverage governs internal development quality, not supplier governance, so it addresses no supply chain risk such as third-party components or vendor practices. It is tempting because coverage metrics are familiar assurance artefacts, and would fit a policy governing internal CI pipelines rather than external supplier obligations.

Requirement to use proprietary code only.

Why it fails: Mandating proprietary code only restricts open-source components; it does not establish supplier governance, provenance or assurance over externally sourced elements. It is tempting because licence and origin controls feel security-relevant, and would fit a policy governing acceptable third-party software licensing rather than supply chain security.

Requirement for the supplier to perform a full system wipe.

Why it fails: A full system wipe addresses end-of-life data remanence, not the ongoing supplier relationship a supply chain security policy must govern. It is tempting because disposal controls are genuine security requirements, and would be correct within a media sanitisation or asset decommissioning policy instead.

The vendor provides a generic privacy policy.

Why it fails: A generic privacy policy addresses data handling at the provider level, not the fourth-party risk of its subprocessors and their controls. It tempts because privacy documentation is a legitimate due-diligence artefact, but it evidences nothing about downstream supplier assessment or monitoring.

The vendor only uses software developed internally.

Why it fails: Internal-only development does not evidence fourth-party oversight; mature VRM requires assessing and monitoring the vendor's own suppliers and subprocessors. It tempts because reducing external dependencies genuinely lowers supply chain exposure, but it answers a different question than fourth-party risk management.

The vendor uses a public cloud provider.

Why it fails: Using a public cloud provider says nothing about how the vendor identifies, assesses, or monitors its own subprocessors, which is what fourth-party risk demands. It tempts because cloud hosting is a real supply chain dependency, but the practice itself is not evidence of VRM maturity.

The code must be written in a memory-safe language.

Why it fails: SLSA Level 3 addresses build platform hardening and provenance, not the source language; memory-safe languages are a separate vulnerability-reduction practise. It is tempting because memory safety genuinely reduces exploitable defects, and it would be the answer if the requirement were about eliminating buffer-overflow classes in the codebase.

The project must have 100% open-source components.

Why it fails: SLSA Level 3 concerns build provenance and isolation, requiring a hardened, hosted build platform with non-falsifiable attestations; open-source composition is unrelated. It is tempting because supply-chain security often involves dependency scrutiny, and mandating open-source components would fit a licensing or transparency policy question instead.

All developers must use a Linux-based OS.

Why it fails: The OS of the developer is not a component of SLSA levels.

The vendor's employee handbook.

Why it fails: An employee handbook covers HR policy, not supply chain resilience artefacts like SOC 2 reports, subprocessor inventories or incident response plans. It is tempting because it evidences internal governance, but it does not demonstrate third-party risk management or breach readiness.

The vendor's annual financial report.

Why it fails: Financial reports address vendor solvency, not supply chain security controls such as subprocessor lists, breach history or audit reports. They are tempting because vendor viability affects continuity risk, but resilience assessment requires evidence of security posture, not accounting disclosures.

Enable verbose logging to standard output.

Why it fails: Verbose logging writes build output to standard output, which neither isolates the build from network access nor pins its inputs; hermetic builds require sealed, reproducible dependency resolution. It is tempting because logging aids pipeline forensics after a compromise, but it is a detective control, not the isolation hermeticity demands.

Automatically pull the latest compiler version.

Why it fails: Pulling the latest compiler version makes builds non-reproducible, since the toolchain changes between runs; hermetic builds pin exact compiler and dependency versions. It is tempting because automatic updates reduce patching effort and keep tooling current, but that currency directly breaks the deterministic, sealed environment hermeticity requires.

Allow developers to trigger manual builds via SSH.

Why it fails: SSH-triggered manual builds bypass the pipeline's controlled, auditable execution path, so inputs and environment cannot be guaranteed reproducible. It is tempting because manual triggering helps debug failed builds quickly, but hermetic builds require automated, isolated execution with declared inputs, not interactive developer access to build hosts.

Mitigation of SQL injection flaws in custom code.

Why it fails: An SBOM inventories components and dependencies, exposing vulnerable or malicious third-party libraries; it does not remediate injection flaws in an organisation's own code. Injection flaws are tempting because they are common vulnerabilities, but they originate in custom code, which SBOM component tracking does not cover.

Prevention of brute-force attacks on application login.

Why it fails: An SBOM lists software components and dependencies, helping identify compromised or vulnerable third-party packages; it does not prevent brute-force attacks against login endpoints. Brute-force prevention is tempting as an application-security control, but it relies on rate limiting, lockouts and MFA, not component inventory.

Auto-scaling of the registry's storage capacity.

Why it fails: Auto-scaling storage addresses capacity and availability, not supply chain attack prevention; the registry instead needs signature verification, immutable versioning and provenance attestation. It is tempting because scaling is a genuine registry concern, but only for performance scenarios, not for blocking tampered or malicious artifacts.

Automatic translation of code into multiple languages.

Why it fails: Translation of code into multiple languages has no bearing on supply chain integrity; registries must verify provenance, sign artifacts and scan dependencies. It is tempting because localisation pipelines are legitimate DevOps tasks, but they belong in build tooling, not in an artifact registry's security controls.

Physical inspection of the vendor's data center.

Why it fails: A physical data-centre inspection is one point-in-time control check and cannot scale across cloud-hosted or numerous vendors, nor cover their processes. It is tempting because seeing facilities feels conclusive, but an effective programme relies on questionnaires, independent audit reports and contractual security requirements.

Mandatory integration of your internal tools with the vendor.

Why it fails: Forcing your tooling into a vendor's environment grants your systems access to their infrastructure and creates liability without evidencing their security controls. It is tempting because integration implies monitoring, but assessment instead requires questionnaires, certifications, audit reports and contractual security obligations.

Requiring the vendor to use your internal developers.

Why it fails: Dictating the vendor's staffing model does not assess their security posture and is usually contractually unworkable for third parties. It is tempting because personnel vetting matters, but that is verified through background-check policies and attestations, not by requiring your own developers inside the vendor.