Study guide

Supply Chain and Insider Threat Scenarios

CompTIA Security+ SY0-701

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook

2 Domain 1: General Security Concepts (12%)

CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact

3 Domain 1: Identity, Trust, and Cryptography Basics

AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules

4 Domain 2: Threat Actors, Vectors, and Social Engineering

Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios

5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks

Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping

6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities

Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions

7 Domain 3: Security Architecture - Secure Architecture Models

Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios

8 Domain 3: Security Architecture - Network Security Architecture

Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design

9 Domain 3 Part C: Data Protection and Resilience

Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience

10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT

Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security

11 IAM Operations and Access Control

Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring

12 Logging, Monitoring, and Detection

Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling

13 Incident Response

IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics

14 Digital Forensics and Investigation

Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps

15 Vulnerability, Patch, Asset, and Automation Operations

Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling

16 Governance, Policies, and Risk Management

Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting

17 Third-Party Risk, Compliance, and Privacy

Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences

18 Audits, Penetration Testing, and Awareness

Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls

19 Final Review and PBQ Labs

PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation

Supply Chain and Insider Threat Scenarios

Key Takeaways Explain This Topic AI

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.

Last updated: June 2026

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.