Trick 1: “If a software update has a valid digital signature from the vendor, it is safe to install.” True or False?
FALSE. A valid digital signature proves that the package was signed by the vendor's signing infrastructure and has not been modified since signing. It does not prove the package was free of malicious code when it was signed.
The SolarWinds SUNBURST backdoor was distributed with a valid SolarWinds code-signing certificate — because the attacker compromised the build system before the signing step. The malicious code was compiled and signed alongside legitimate code. Signature verification passed on all approximately 18,000 affected installations.
Code signing protects post-signing integrity only. It says nothing about what was inserted in the build pipeline before signing. A validly signed package can be — and in SUNBURST was — a compromised package.
The SolarWinds SUNBURST backdoor was distributed with a valid SolarWinds code-signing certificate — because the attacker compromised the build system before the signing step. The malicious code was compiled and signed alongside legitimate code. Signature verification passed on all approximately 18,000 affected installations.
Code signing protects post-signing integrity only. It says nothing about what was inserted in the build pipeline before signing. A validly signed package can be — and in SUNBURST was — a compromised package.
Trick 2: “Hash verification catches all malicious update attacks.” True or False?
FALSE. Hash verification detects modifications that occur after the vendor computes and publishes the reference hash: distribution server compromise, in-transit substitution. If the attacker inserts malicious code in the build pipeline — before compilation, signing, and hashing — the vendor hashes the malicious package and publishes that hash as the reference. The downloaded package matches the reference hash perfectly. Verification passes.
Hash verification and code signing both protect the same window: post-publication integrity. Neither protects against upstream build pipeline compromise, which is the higher-severity supply chain attack vector. An organization that passes hash verification has confirmed the package has not been tampered with since publication — not that the package was clean when published.
Hash verification and code signing both protect the same window: post-publication integrity. Neither protects against upstream build pipeline compromise, which is the higher-severity supply chain attack vector. An organization that passes hash verification has confirmed the package has not been tampered with since publication — not that the package was clean when published.
Trick 3: “An organization that applies software updates promptly is at lower risk from malicious update attacks.” True or False?
Nuanced — TRUE that prompt patching reduces exposure to known vulnerabilities, but FALSE that it reduces exposure to malicious update attacks.
In the SolarWinds case, organizations that applied the update most promptly were among the first compromised — they were following security best practice, and that practice was the attack vector. Prompt updates reduce unpatched-vulnerability risk; they do not reduce — and in some cases accelerate — malicious update exposure.
The correct response is to address both risks through supply chain verification (code signing + hash + SBOM + behavioral monitoring) rather than delaying updates. Delaying updates to reduce malicious update risk is not a sound strategy — it trades one risk for another. The goal is to install updates promptly while applying behavioral monitoring after installation to detect any malicious payload activity.
In the SolarWinds case, organizations that applied the update most promptly were among the first compromised — they were following security best practice, and that practice was the attack vector. Prompt updates reduce unpatched-vulnerability risk; they do not reduce — and in some cases accelerate — malicious update exposure.
The correct response is to address both risks through supply chain verification (code signing + hash + SBOM + behavioral monitoring) rather than delaying updates. Delaying updates to reduce malicious update risk is not a sound strategy — it trades one risk for another. The goal is to install updates promptly while applying behavioral monitoring after installation to detect any malicious payload activity.
Trick 4: “Dependency confusion only affects organizations that use open-source libraries.” True or False?
FALSE. Dependency confusion affects any organization using a package manager with access to both a private internal registry and a public registry — regardless of whether the internal packages are open source or proprietary.
The attack exploits the package manager's version-preference resolution logic, not the nature of the packages. An organization using entirely proprietary internal packages is still vulnerable if their package manager checks public registries and prefers higher version numbers from public sources.
The fix is a configuration change — scoping the package manager to use the private registry exclusively for internal package names. The open-source or proprietary nature of the packages is irrelevant to the vulnerability; what matters is whether the package manager can be tricked into preferring a public package over an internal one by version number alone.
The attack exploits the package manager's version-preference resolution logic, not the nature of the packages. An organization using entirely proprietary internal packages is still vulnerable if their package manager checks public registries and prefers higher version numbers from public sources.
The fix is a configuration change — scoping the package manager to use the private registry exclusively for internal package names. The open-source or proprietary nature of the packages is irrelevant to the vulnerability; what matters is whether the package manager can be tricked into preferring a public package over an internal one by version number alone.
Performance Task: A financial services organization uses a third-party accounting platform for all payment processing. The vendor releases a critical security update. The security team: (1) downloads from the vendor's official site, (2) verifies the digital signature, (3) verifies the SHA-256 hash against the vendor's website, (4) installs via the standard update mechanism. The security team lead says: “We've followed every step of our policy — this update is verified and safe.” Is this assessment correct? Identify what the policy verifies, what it does not verify, and what additional controls would provide more complete assurance.
Model Answer:
What the policy verifies: (1) Official download channel — reduces in-transit substitution risk. (2) Valid digital signature — confirms the package was signed by the vendor and not modified after signing. (3) SHA-256 hash matches published value — confirms no modification after the vendor published the hash. Together: post-publication integrity is verified. The package has not been tampered with between publication and installation.
What the policy does NOT verify: Whether the package was clean before signing and hashing. If the vendor's build system was compromised — as in SolarWinds — the malicious code was inserted before compilation, signing, and hashing. The signature is valid. The hash matches. Every policy check passes. The organization has installed a legitimately signed, hash-verified, build-pipeline-compromised package.
Additional controls: (1) Behavioral monitoring — watch the accounting platform's process after the update for unexpected outbound connections, unusual file access, credential access, or lateral movement. This is how SUNBURST was eventually detected. (2) SBOM review — request a Software Bill of Materials from the vendor and cross-reference every component against known-compromised library databases. (3) Staged rollout with observation — install on a small set of isolated systems first, monitor behaviour for longer than typical dormancy periods (30 days) before organization-wide deployment. (4) Vendor security assessment — evaluate the vendor's build pipeline security: code review processes, build environment isolation, signing key management, internal threat detection.
Conclusion: The policy is necessary but not sufficient. It provides assurance against post-publication tampering. It provides no assurance against build pipeline compromise — the higher-severity attack vector demonstrated by SolarWinds. Complete assurance requires behavioral monitoring and staged deployment in addition to integrity verification.
What the policy verifies: (1) Official download channel — reduces in-transit substitution risk. (2) Valid digital signature — confirms the package was signed by the vendor and not modified after signing. (3) SHA-256 hash matches published value — confirms no modification after the vendor published the hash. Together: post-publication integrity is verified. The package has not been tampered with between publication and installation.
What the policy does NOT verify: Whether the package was clean before signing and hashing. If the vendor's build system was compromised — as in SolarWinds — the malicious code was inserted before compilation, signing, and hashing. The signature is valid. The hash matches. Every policy check passes. The organization has installed a legitimately signed, hash-verified, build-pipeline-compromised package.
Additional controls: (1) Behavioral monitoring — watch the accounting platform's process after the update for unexpected outbound connections, unusual file access, credential access, or lateral movement. This is how SUNBURST was eventually detected. (2) SBOM review — request a Software Bill of Materials from the vendor and cross-reference every component against known-compromised library databases. (3) Staged rollout with observation — install on a small set of isolated systems first, monitor behaviour for longer than typical dormancy periods (30 days) before organization-wide deployment. (4) Vendor security assessment — evaluate the vendor's build pipeline security: code review processes, build environment isolation, signing key management, internal threat detection.
Conclusion: The policy is necessary but not sufficient. It provides assurance against post-publication tampering. It provides no assurance against build pipeline compromise — the higher-severity attack vector demonstrated by SolarWinds. Complete assurance requires behavioral monitoring and staged deployment in addition to integrity verification.