Supply Chain and Insider Threat Scenarios
Key Takeaways
- Supply chain attacks abuse a trusted relationship: vendor, managed service provider, software dependency, build pipeline, update channel, or hardware/firmware source.
- Vendor risk controls include due diligence, contractual security requirements, least privilege, time-bound access, monitoring, and timely offboarding.
- Insider threats are malicious, negligent, or compromised; the common thread is trusted access, not necessarily intent.
- Software supply chain defense uses code signing, dependency review, a software bill of materials (SBOM), secure CI/CD with least privilege, and build provenance.
- Scenario questions usually want the best preventive process control, not just a detection tool.
Trusted Relationships Are the Risk
Supply chain risk comes from relationships an organization already trusts. Rather than attacking a hardened target directly, an actor compromises a vendor, managed service provider (MSP), software dependency, build system, update channel, contractor, or hardware source because that path is softer and the malicious payload arrives wrapped in trust. SY0-701 objective 2.2 lists supply chain explicitly as a vector, and 2.3 connects it to the techniques attackers use.
| Supply chain path | Scenario clue | Useful control |
|---|---|---|
| Software dependency | New library version behaves unexpectedly | Dependency review, lock files, vulnerability scanning |
| CI/CD pipeline | Build job injects code or leaks secrets | Least privilege, secret vaulting, signed builds |
| Vendor remote access | Support account connects at an unusual time | MFA, PAM, time-bound access, monitoring |
| Managed service provider | One MSP account reaches many customers | Tenant isolation, segmentation, contractual controls |
| Hardware / firmware | A device arrives with altered firmware | Trusted sourcing, validation, secure boot |
| Update mechanism | A trusted updater delivers a malicious package | Code signing, update integrity checks |
A software bill of materials (SBOM) is the SY0-701 answer when a question asks how to know exactly which components and versions ship inside a product, which is essential for responding fast to a dependency disclosure.
The Three Insider Types
| Type | Behavior | Example |
|---|---|---|
| Malicious insider | Intentionally misuses access | Copies source code before resigning |
| Negligent insider | Creates risk through carelessness | Uploads restricted data to personal cloud |
| Compromised insider | Account controlled by an attacker | Valid VPN login from an impossible-travel location |
| Privileged insider | Elevated access, broad blast radius | Admin disables logs before exfiltrating data |
The deciding clue is trusted access, not motive. A negligent insider intends no harm yet can cause a breach, while a compromised insider is technically an outsider operating through a legitimate account.
Scenario Walkthrough 1: Vendor Access
A facilities vendor needs temporary access to building-management systems for a repair. The weak approach is a shared, always-on VPN account. The strong approach uses named vendor accounts, MFA, least privilege, access scoped to the repair window, network segmentation, full logging, and removal after completion. If the vendor needs recurring access, review it periodically and bake security obligations into the contract. Privileged access management (PAM) with just-in-time elevation is the textbook control here.
Scenario Walkthrough 2: Build Pipeline
A developer notices that a released artifact differs from the reviewed source. This is a software supply chain integrity problem. Useful controls include signed commits, protected branches, mandatory peer review, build provenance, artifact signing, secret management (no plaintext keys in the pipeline), restricted CI/CD permissions, and separation between build and deployment approval. The 2020 SolarWinds incident is the canonical real-world example of a build-system compromise that pushed a malicious signed update to thousands of customers.
Trap Callout: Trusted Does Not Mean Unlimited
Vendors, administrators, contractors, and service accounts are trusted for a specific purpose. That trust is not a grant of permanent, broad access. Apply least privilege, continuous monitoring, segmentation, and disciplined offboarding to every trusted relationship. On the exam, prefer the answer that prevents abuse (named time-bound accounts, signing, review) over the one that only detects it after the fact.
Quick Drill
| Clue | Most likely issue |
|---|---|
| Contractor account still active after the project ends | Vendor offboarding failure |
| Personal cloud drive used for restricted files | Negligent insider / shadow IT |
| Admin downloads unusual volume right before resigning | Malicious insider |
| New package dependency begins beaconing | Software supply chain compromise |
| Vendor support account logs in from an unusual country | Compromised vendor credential |
| Build system stores plaintext deployment keys | CI/CD secret-management weakness |
| Need a precise inventory of shipped components | Maintain an SBOM |
Why Supply Chain Attacks Scale
The reason adversaries invest in supply chain compromise is leverage. A single poisoned software update or a single compromised MSP can reach hundreds or thousands of downstream organizations at once, all of which trust the source and apply its updates automatically. This is the multiplier effect that makes the technique so attractive and so dangerous.
Defending against it means refusing to treat any external input as inherently safe: dependencies are reviewed and pinned to known-good versions, updates are validated through code signing and integrity checks, hardware is sourced from vetted suppliers and validated at receipt, and every vendor connection is treated as a potential breach path that must be segmented away from sensitive systems.
Building a Vendor Risk Program
Vendor risk management is a lifecycle, not a one-time check. It begins with due diligence before onboarding, including security questionnaires, evidence of certifications, and review of the vendor's own breach history. Contracts then codify security requirements, breach-notification timelines, right-to-audit clauses, and data-handling obligations. During the relationship, the organization enforces least privilege and time-bound access, monitors vendor activity, and reviews entitlements periodically so access does not quietly accumulate.
The lifecycle ends with disciplined offboarding: disabling accounts, revoking keys and certificates, and confirming the vendor has destroyed or returned any retained data. A contractor account that remains active months after a project closes is the single most common offboarding failure the exam tests.
Distinguishing Insider Categories Under Pressure
Exam stems rarely use the words malicious, negligent, or compromised, so you must infer the category from behavior. Deliberate harm, especially data theft tied to a resignation or a grievance, signals a malicious insider. A well-meaning mistake such as emailing a spreadsheet of customer records to a personal address or storing files on an unsanctioned cloud drive points to a negligent insider. A legitimate account behaving impossibly, for instance two logins from different continents within minutes, indicates a compromised insider whose credentials an outsider now controls.
User and entity behavior analytics (UEBA), least privilege, separation of duties, and mandatory vacations are the preventive and detective controls the exam pairs with each of these categories.
A vendor support account is shared by several technicians and stays active between maintenance windows. Which control best reduces the risk?
A reviewed application source tree is clean, but the released package contains an extra credential-stealing script added during the build process. What type of issue is this?
Which controls help reduce insider and supply chain risk? Choose three.
Select all that apply