Lesson Five

Threat Modeling, Supply-Chain Risk, and Third-Party Risk

SierraTec Secure CISSP Certification Preparation Course

Lesson Overview

Lesson Four established how organizations identify, analyze, evaluate, treat, monitor, and communicate cybersecurity risk.

Lesson Five extends that foundation in two important directions:

1. Threat modeling — systematically identifying how valuable systems, information, processes, and trust relationships could be attacked, abused, or fail.

2. Supply-chain and third-party risk management — understanding how organizational risk extends beyond systems directly controlled by the organization to suppliers, vendors, service providers, software components, hardware manufacturers, cloud providers, contractors, and other external dependencies.

Modern organizations rarely build every technology they use.

An organization may depend on:

• cloud infrastructure;

• operating systems;

• commercial software;

• open-source libraries;

• telecommunications providers;

• managed security services;

• hardware manufacturers;

• software-development tools;

• consultants;

• payment processors;

• identity providers;

• logistics companies;

• outsourced business processes.

This creates a fundamental security reality:

An organization can have strong internal security and still be compromised through a trusted external dependency.

The current CISSP examination outline separates Threat Modeling into Objective 1.10 and Supply Chain Risk Management into Objective 1.11. Objective 1.11 explicitly includes risks involving product tampering, counterfeits, implants, supplier/provider acquisition, third-party assessment and monitoring, minimum security requirements, service-level requirements, silicon roots of trust, physically unclonable functions, and software bills of materials.

This lesson develops those concepts into a practical CISSP decision-making framework.

CISSP Exam Objective Alignment

Learning Objectives

After completing this lesson, you should be able to:

1. Define threat modeling.

2. Explain why threat modeling should begin early in the system lifecycle.

3. Distinguish threat actor, threat source, threat event, attack vector, attack surface, and attack path.

4. Explain the purpose of trust boundaries.

5. Explain how data-flow diagrams assist threat modeling.

6. Identify assets requiring protection.

7. Identify assumptions and dependencies affecting a threat model.

8. Explain misuse and abuse cases.

9. Apply the STRIDE threat-modeling framework.

10. Explain attack trees.

11. Describe threat scenario development.

12. Explain how threat intelligence can support threat modeling.

13. Explain attack-surface reduction.

14. Distinguish threat modeling from vulnerability scanning.

15. Define cybersecurity supply-chain risk.

16. Explain why third-party dependency creates security exposure.

17. Identify product-tampering, counterfeit, and malicious-implant risks.

18. Distinguish hardware, software, service, and personnel supply-chain risks.

19. Explain supplier due diligence.

20. Explain third-party assessment and monitoring.

21. Describe minimum supplier-security requirements.

22. Explain the purpose of service-level requirements.

23. Explain software supply-chain risk.

24. Define a Software Bill of Materials.

25. Explain the benefits and limitations of SBOMs.

26. Explain software-component provenance.

27. Explain a silicon root of trust at a high level.

28. Explain a physically unclonable function at a high level.

29. Explain fourth-party and nth-party risk.

30. Describe supplier onboarding and offboarding.

31. Explain third-party incident-response requirements.

32. Explain why outsourcing does not eliminate accountability.

33. Apply threat modeling and supplier-risk concepts to CISSP scenarios.

34. Recognize common examination traps involving supplier trust and technical controls.

Part I — Understanding Threats

1. Threat Modeling Begins With Context

Threat modeling is not simply asking:

“What hackers might attack us?”

A useful threat model begins by understanding:

• the system;

• business purpose;

• assets;

• users;

• data;

• dependencies;

• architecture;

• trust relationships;

• external interfaces.

Only then can meaningful threat scenarios be developed.

2. What Is Threat Modeling?

Threat modeling is a structured process used to identify and analyze potential threats against a system, application, business process, architecture, or environment.

Threat modeling helps answer:

What are we building or protecting?

What could go wrong?

How could it happen?

What would the impact be?

What should we do about it?

Did we address the important threats?

3. SierraTec Secure Threat-Modeling Cycle

┌───────────────────────────────┐

│ 1. DEFINE THE SYSTEM          │

│ Purpose, scope, architecture  │

└───────────────┬───────────────┘

                ▼

┌───────────────────────────────┐

│ 2. IDENTIFY ASSETS            │

│ Data, services, identities    │

└───────────────┬───────────────┘

                ▼

┌───────────────────────────────┐

│ 3. MAP DATA & TRUST           │

│ Flows, interfaces, boundaries │

└───────────────┬───────────────┘

                ▼

┌───────────────────────────────┐

│ 4. IDENTIFY THREAT SCENARIOS  │

│ Actors, events, attack paths  │

└───────────────┬───────────────┘

                ▼

┌───────────────────────────────┐

│ 5. ANALYZE RISK               │

│ Likelihood, impact, exposure  │

└───────────────┬───────────────┘

                ▼

┌───────────────────────────────┐

│ 6. SELECT MITIGATIONS         │

│ Prevent, detect, contain      │

└───────────────┬───────────────┘

                ▼

┌───────────────────────────────┐

│ 7. VALIDATE & MAINTAIN        │

│ Test, monitor, update model   │

└───────────────────────────────┘

Threat modeling is iterative rather than a one-time activity.

4. Threat Actor

A threat actor is a person, group, organization, or other entity capable of intentionally causing harm.

Examples include:

• cybercriminal;

• malicious insider;

• nation-state group;

• hacktivist;

• competitor;

• organized criminal group.

5. Threat Source

A threat source is broader than a threat actor.

A source of harm may be:

Human and Intentional

• attacker;

• insider;

• criminal organization.

Human and Accidental

• administrator error;

• accidental disclosure;

• incorrect configuration.

Environmental

• fire;

• flooding;

• temperature failure.

Technical

• hardware failure;

• software defect;

• power failure.

Therefore:

Not every threat involves an attacker.

6. Threat Event

A threat event is the actual event capable of causing harm.

Examples:

• credential theft;

• database modification;

• malicious code execution;

• accidental deletion;

• electrical outage;

• unauthorized physical access.

7. Threat Actor, Source, and Event

8. Attack Vector

An attack vector is a method or avenue used to reach or exploit a target.

Examples:

• phishing;

• malicious attachment;

• exposed remote service;

• vulnerable web application;

• stolen credential;

• compromised vendor account;

• malicious software update;

• infected USB device.

9. Attack Surface

The attack surface is the set of points where an attacker could potentially interact with or attempt to compromise a system.

Examples include:

• internet-facing services;

• APIs;

• remote-access systems;

• user accounts;

• administrative interfaces;

• wireless access;

• physical ports;

• cloud storage;

• third-party integrations.

10. Attack Vector Versus Attack Surface

11. Attack Path

An attack path describes a sequence through which an attacker may progress toward an objective.

Example:

PHISHING EMAIL

      │

      ▼

USER CREDENTIAL STOLEN

      │

      ▼

REMOTE ACCESS

      │

      ▼

INTERNAL APPLICATION

      │

      ▼

PRIVILEGE ESCALATION

      │

      ▼

DATABASE ACCESS

      │

      ▼

CUSTOMER DATA EXFILTRATION

A successful attack may require several weaknesses rather than one.

12. Why Attack Paths Matter

Security teams sometimes evaluate vulnerabilities individually.

Threat modeling asks:

How could several weaknesses combine?

For example:

• weak MFA;

• excessive privilege;

• flat network;

• poor logging;

may together create a far more serious risk than any single issue suggests.

Part II — Assets, Data Flows, and Trust Boundaries

13. Identify the Assets

Threat modeling should identify what matters.

Assets may include:

• customer information;

• credentials;

• cryptographic keys;

• business transactions;

• intellectual property;

• system availability;

• administrative capability;

• safety-critical functions.

14. Asset Questions

Ask:

• What information is processed?

• What information is sensitive?

• What service must remain available?

• Which credentials provide high privilege?

• What business transaction requires integrity?

• Which functions affect safety?

• Which component is most critical?

15. Data Flow

Systems move information among:

• users;

• processes;

• applications;

• databases;

• external services.

Understanding these movements helps identify exposure.

16. Basic Data-Flow Diagram

 CUSTOMER

    │

    │ Login / Transaction

    ▼

┌─────────────┐

│ WEB PORTAL  │

└──────┬──────┘

       │

       ▼

┌─────────────┐

│ APPLICATION │

│   SERVER    │

└──────┬──────┘

       │

       ▼

┌─────────────┐

│  DATABASE   │

└─────────────┘

       │

       ▼

┌─────────────┐

│ PAYMENT API │

└─────────────┘

A threat model examines each:

• component;

• connection;

• data flow;

• interface;

• trust relationship.

17. Trust Boundary

A trust boundary exists where the level of trust or security assumptions change.

Examples:

• internet → enterprise network;

• user device → cloud service;

• application → database;

• enterprise → third-party API;

• employee environment → privileged administration environment.

18. Trust-Boundary Diagram

              INTERNET

                  │

                  ▼

══════════════════════════════

      TRUST BOUNDARY #1

══════════════════════════════

                  │

             WEB SERVICE

                  │

                  ▼

══════════════════════════════

      TRUST BOUNDARY #2

══════════════════════════════

                  │

          INTERNAL SERVICE

                  │

                  ▼

══════════════════════════════

      TRUST BOUNDARY #3

══════════════════════════════

                  │

           SENSITIVE DATA

Crossing a trust boundary should cause the analyst to ask:

• Is authentication required?

• Is authorization enforced?

• Is the traffic protected?

• Is input validated?

• Is activity logged?

19. External Trust Boundary

Consider:

INTERNAL PAYMENT SYSTEM

          │

          ▼

══════════════════════════

  THIRD-PARTY BOUNDARY

══════════════════════════

          │

          ▼

EXTERNAL PAYMENT PROVIDER

The organization does not control the provider's complete environment.

This introduces:

• technical risk;

• contractual risk;

• dependency risk;

• availability risk;

• third-party risk.

20. Assumptions

Threat models depend on assumptions.

Examples:

• administrators use MFA;

• network segmentation works;

• vendor authentication is trustworthy;

• backups are protected;

• software updates are signed.

These assumptions should be documented.

If an assumption fails, the risk model may change.

Part III — Threat-Modeling Methodologies

21. No Single Threat-Modeling Method Fits Everything

Threat-modeling approaches differ.

Common techniques include:

• STRIDE;

• attack trees;

• misuse cases;

• abuse cases;

• data-flow analysis;

• scenario analysis.

The CISSP objective focuses on understanding and applying threat-modeling concepts and methodologies rather than requiring candidates to treat one methodology as universally correct.

22. STRIDE

STRIDE is a useful threat-category framework.

The acronym represents:

23. Spoofing

Spoofing involves pretending to be another identity or entity.

Examples:

• stolen user credentials;

• forged identity;

• impersonated service.

Primary security concern:

Authenticity

24. Tampering

Tampering involves unauthorized modification.

Examples:

• changing database records;

• modifying executable code;

• altering configuration.

Primary concern:

Integrity

25. Repudiation

Repudiation involves denying an action when sufficient evidence does not exist to establish accountability.

Example:

A user performs a financial transaction and later denies it.

Primary concern:

Nonrepudiation

26. Information Disclosure

Information disclosure occurs when unauthorized parties gain access to protected information.

Primary concern:

Confidentiality

Examples:

• data leak;

• exposed cloud storage;

• intercepted sensitive traffic.

27. Denial of Service

Denial of service interferes with legitimate access to systems or resources.

Primary concern:

Availability

28. Elevation of Privilege

Elevation of privilege occurs when a subject gains greater permission than authorized.

Examples:

• normal user becomes administrator;

• application gains system privileges.

Relevant principles:

• least privilege;

• authorization;

• privilege management.

29. STRIDE Security Mapping

30. STRIDE Example

Consider an online banking portal.

Potential threats:

Spoofing

Attacker steals a customer credential.

Tampering

Attacker changes a payment amount.

Repudiation

Customer denies authorizing a transaction.

Information Disclosure

Attacker obtains account data.

Denial of Service

Portal becomes unavailable.

Elevation of Privilege

Normal user gains administrator permissions.

31. Attack Trees

An attack tree begins with an attacker's objective and decomposes the possible ways the objective may be achieved.

Example:

             STEAL CUSTOMER DATA

                      │

        ┌─────────────┼──────────────┐

        │             │              │

        ▼             ▼              ▼

COMPROMISE USER   EXPLOIT WEB     COMPROMISE

   ACCOUNT        APPLICATION       VENDOR

        │             │              │

   ┌────┴────┐        │          ┌───┴────┐

   ▼         ▼        ▼          ▼        ▼

PHISHING   PASSWORD   SQL      VENDOR   MALICIOUS

          REUSE     INJECTION   TOKEN     UPDATE

Attack trees help identify alternative attack paths.

32. Misuse Cases

Traditional use case:

What should the legitimate user do?

Misuse case:

How could an attacker misuse the system?

Example:

Legitimate use:

Customer resets password.

Misuse:

Attacker abuses account recovery to take over the customer's account.

33. Abuse Cases

Abuse cases identify harmful behavior even when functionality works as technically designed.

Example:

A messaging service allows sending thousands of messages.

An attacker uses the valid feature for:

• spam;

• harassment;

• phishing.

The application is functioning.

The functionality is being abused.

34. Threat Scenario

A useful threat scenario identifies:

• threat source;

• objective;

• target;

• attack method;

• vulnerability;

• resulting impact.

Example:

A cybercriminal uses stolen credentials obtained through phishing to access the organization's remote-access service and attempts to reach sensitive financial systems.

Part IV — Threat Intelligence and Threat Modeling

35. Threat Intelligence

Threat intelligence may provide information about:

• threat actors;

• current attack techniques;

• malware;

• vulnerabilities;

• targeted industries;

• attacker infrastructure.

Threat intelligence can help ensure that a threat model reflects credible threats.

36. Threat Intelligence Does Not Replace Threat Modeling

Threat intelligence may indicate:

ransomware groups are targeting healthcare.

Threat modeling asks:

How could ransomware reach this hospital's systems?

The two complement each other.

37. Threat Modeling Should Be Maintained

Threat models should be reconsidered when:

• architecture changes;

• new interfaces are added;

• cloud migration occurs;

• new vendors are integrated;

• serious vulnerabilities emerge;

• threat activity changes.

Part V — Attack-Surface Reduction

38. Reduce Unnecessary Exposure

A strong architecture does not merely add controls.

It also removes unnecessary attack opportunities.

Examples:

• disable unused services;

• close unnecessary ports;

• remove unused accounts;

• limit administrative interfaces;

• restrict remote access;

• reduce excessive API exposure;

• eliminate unnecessary data collection.

39. Attack-Surface Reduction Model

LARGE ATTACK SURFACE

        │

        ├── Unused services

        ├── Excess accounts

        ├── Public interfaces

        ├── Legacy protocols

        └── Unnecessary software

        │

        ▼

REMOVE / RESTRICT / HARDEN

        │

        ▼

SMALLER ATTACK SURFACE

40. Threat Modeling Versus Vulnerability Scanning

These are not the same activity.

Both are valuable.

Part VI — Enterprise Threat-Model Example

41. Example: Digital Payment Service

Architecture:

                      CUSTOMER

                         │

                         ▼

                     MOBILE APP

                         │

                         ▼

══════════════════════════════════════

       EXTERNAL TRUST BOUNDARY

══════════════════════════════════════

                         │

                         ▼

                     API GATEWAY

                         │

                 ┌───────┴───────┐

                 ▼               ▼

           IDENTITY SERVICE   PAYMENT SERVICE

                 │               │

                 │               ▼

                 │           TRANSACTION DB

                 │               │

                 └───────┬───────┘

                         ▼

══════════════════════════════════════

       THIRD-PARTY TRUST BOUNDARY

══════════════════════════════════════

                         │

                         ▼

                    BANK / PAYMENT

                       PROVIDER

42. Threat Questions

For the mobile app:

• Can credentials be stolen?

• Can application data be modified?

For the API:

• Can authentication be bypassed?

• Can requests be manipulated?

For the database:

• Can transaction records be altered?

• Can customer data be disclosed?

For the external provider:

• What happens if the provider is compromised?

• What happens if its API becomes unavailable?

43. Resulting Controls

Potential safeguards could include:

• strong authentication;

• transaction authorization;

• input validation;

• API security;

• encryption;

• logging;

• fraud monitoring;

• rate limiting;

• supplier monitoring;

• recovery planning.

Threat modeling identifies why controls are needed.

Part VII — Understanding Supply-Chain Risk

44. What Is the Cybersecurity Supply Chain?

The cybersecurity supply chain includes the organizations, technologies, processes, and components involved in developing, manufacturing, distributing, delivering, operating, and supporting products and services.

Example:

RAW COMPONENT

      │

      ▼

COMPONENT SUPPLIER

      │

      ▼

MANUFACTURER

      │

      ▼

SOFTWARE / FIRMWARE

      │

      ▼

DISTRIBUTOR

      │

      ▼

SERVICE PROVIDER

      │

      ▼

ORGANIZATION

      │

      ▼

CUSTOMER

45. Cybersecurity Supply-Chain Risk

Supply-chain risk exists because the organization may not fully control or see:

• how a product was developed;

• where components originated;

• who had access during manufacturing;

• how software dependencies were created;

• how updates are distributed;

• how suppliers secure their environment.

NIST's current SP 800-161 Rev. 1 guidance emphasizes that supply-chain risk can arise from malicious functionality, counterfeit products, and weaknesses introduced by poor development or manufacturing practices, and recommends integrating C-SCRM into broader organizational risk management.

46. Why Supply Chains Are Attractive Targets

A supplier may provide access to:

• hundreds;

• thousands;

• or millions

of downstream customers.

Compromising one supplier can therefore create a pathway into many organizations.

47. Direct Versus Indirect Risk

ORGANIZATION

     │

     ▼

PRIMARY SUPPLIER

     │

     ▼

SUBCONTRACTOR

     │

     ▼

COMPONENT PROVIDER

     │

     ▼

OPEN-SOURCE PROJECT

The organization may have a contract only with the primary supplier.

Risk may exist much deeper in the chain.

48. Third Party

A third party is an external organization with which the organization has a relationship.

Examples:

• vendor;

• contractor;

• cloud provider;

• consultant;

• software supplier.

49. Fourth Party

A fourth party is typically a supplier or service provider used by the organization's third party.

Example:

YOUR ORGANIZATION

       │

       ▼

PAYROLL PROVIDER

       │

       ▼

PAYROLL PROVIDER'S

CLOUD HOST

The cloud host is an indirect dependency.

50. Nth-Party Risk

Nth-party risk refers more broadly to dependencies deeper in the supply chain.

Visibility generally decreases as distance from the organization increases.

Part VIII — CISSP Supply-Chain Risks

51. Product Tampering

Product tampering involves unauthorized modification of a product or component.

Examples:

• altered firmware;

• modified hardware;

• compromised software package;

• altered update.

Product tampering is specifically identified as an SCRM example in the current CISSP exam outline.

52. Counterfeit Products

Counterfeit products are unauthorized imitations represented as legitimate products.

Possible concerns include:

• reduced quality;

• hidden vulnerabilities;

• unreliable operation;

• malicious modification;

• absence of vendor support.

Counterfeit risk is also explicitly identified in the current CISSP SCRM objective.

53. Malicious Implants

An implant may be malicious functionality inserted into:

• hardware;

• firmware;

• software;

• components.

The purpose may be to enable:

• unauthorized access;

• surveillance;

• disruption;

• data theft.

54. Manufacturing and Development Weaknesses

Not all supply-chain problems are intentional.

Risk can result from:

• poor development practices;

• insecure default configurations;

• inadequate quality control;

• weak patch processes;

• unsupported components;

• insecure dependencies.

55. Types of Supply-Chain Risk

Part IX — Supplier Risk Management Lifecycle

56. SierraTec Secure Supplier Lifecycle

BUSINESS NEED

     │

     ▼

SUPPLIER IDENTIFICATION

     │

     ▼

DUE DILIGENCE

     │

     ▼

RISK ASSESSMENT

     │

     ▼

SECURITY REQUIREMENTS

     │

     ▼

CONTRACT / SLA

     │

     ▼

ONBOARDING

     │

     ▼

CONTINUOUS MONITORING

     │

     ▼

INCIDENT / PERFORMANCE REVIEW

     │

     ▼

RENEWAL OR TERMINATION

     │

     ▼

ACCESS REVOCATION &

DATA DISPOSITION

57. Due Diligence

Supplier due diligence means researching and evaluating a supplier or product before or during acquisition so informed risk decisions can be made.

NIST released SP 1326 in July 2026 as a current quick-start guide for cybersecurity supply-chain due-diligence assessments. Its due-diligence components include supplier ownership/control considerations, provenance, resilience, foundational cyber practices, and supply-chain tiers.

58. Supplier Due-Diligence Questions

Ask:

• Who owns the supplier?

• Where does it operate?

• What does it provide?

• How critical is the service?

• What information will it access?

• What privileged access will it receive?

• What dependencies does it have?

• What security incidents has it experienced?

• What security program does it maintain?

• How does it develop software?

• How does it manage vulnerabilities?

• How resilient is the service?

59. Supplier Criticality

Not every supplier requires the same level of assessment.

Compare:

Office Furniture Provider

Limited access to information systems.

Managed Identity Provider

Potential control over authentication for the entire enterprise.

Risk-based governance should apply stronger oversight to more critical suppliers.

60. Third-Party Assessment

Assessment may examine:

• governance;

• access control;

• encryption;

• vulnerability management;

• incident response;

• resilience;

• privacy;

• software security;

• subcontractors.

The goal is not merely to collect paperwork.

The goal is to determine whether risk is acceptable.

61. Assessment Evidence

Possible evidence includes:

• independent audit reports;

• certifications;

• penetration-test summaries;

• vulnerability-management documentation;

• security policies;

• architecture documentation;

• business-continuity evidence;

• incident-response procedures.

Part X — Minimum Security Requirements

62. Minimum Requirements

Organizations should define security expectations before onboarding critical suppliers.

Requirements might include:

• MFA;

• encryption;

• logging;

• incident reporting;

• vulnerability remediation;

• access control;

• secure development;

• data handling;

• backup and recovery.

Minimum security requirements are expressly identified by ISC2 as a supply-chain risk mitigation example.

63. Requirements Should Be Risk Based

A supplier handling:

public marketing material

may need different requirements from one processing:

millions of confidential customer records.

Avoid universal requirements that ignore business context.

Part XI — Service-Level Requirements

64. Service-Level Agreement

A Service-Level Agreement, or SLA, describes measurable expectations for service delivery.

Examples:

• availability;

• incident-response time;

• recovery time;

• support response;

• remediation deadlines.

Service-level requirements are also specifically included in the current CISSP SCRM objective.

65. Security-Related SLA Examples

Exact requirements should follow organizational need.

66. SLA Does Not Guarantee Security

An SLA establishes expectations.

It does not automatically ensure:

• effective controls;

• perfect service;

• zero incidents.

Performance still requires monitoring.

Part XII — Contractual Security Requirements

67. Contract Topics

Supplier agreements may address:

• confidentiality;

• permitted data use;

• access requirements;

• encryption;

• incident notification;

• audit rights;

• vulnerability management;

• subcontractors;

• service levels;

• termination;

• data return or destruction.

Detailed legal interpretation will be covered in Lesson Six.

68. Right to Audit

A right-to-audit provision may allow the organization to obtain assurance regarding supplier controls.

This does not necessarily mean the organization will physically audit every vendor.

It creates contractual authority for appropriate verification.

69. Incident Notification

Supplier contracts should define appropriate incident-notification expectations.

The organization needs sufficient information to determine:

• impact;

• legal obligations;

• operational response;

• customer communication.

Part XIII — Continuous Third-Party Monitoring

70. Assessment Is Not One-Time

A supplier that was secure during onboarding may later:

• change ownership;

• suffer an incident;

• introduce new subcontractors;

• change infrastructure;

• become financially unstable;

• discontinue a product;

• develop new vulnerabilities.

Therefore, critical suppliers require ongoing monitoring.

71. Monitoring Model

INITIAL ASSESSMENT

       │

       ▼

SUPPLIER APPROVED

       │

       ▼

CONTINUOUS MONITORING

       │

 ┌─────┼──────────────┐

 ▼     ▼              ▼

RISK  INCIDENTS    PERFORMANCE

       │

       ▼

PERIODIC REVIEW

       │

       ▼

RENEW / REMEDIATE /

RESTRICT / TERMINATE

72. Monitoring Indicators

Organizations may track:

• security incidents;

• vulnerability disclosures;

• audit findings;

• service performance;

• unresolved security deficiencies;

• contract compliance;

• ownership changes.

Part XIV — Software Supply-Chain Risk

73. Modern Software Depends on Other Software

A modern application may include:

• internally developed code;

• open-source libraries;

• commercial components;

• frameworks;

• container images;

• APIs;

• third-party services.

Therefore:

You may not fully control every component running inside your application.

74. Software Dependency Chain

YOUR APPLICATION

      │

      ├── INTERNAL CODE

      │

      ├── OPEN-SOURCE LIBRARY A

      │        │

      │        └── DEPENDENCY B

      │                 │

      │                 └── DEPENDENCY C

      │

      ├── COMMERCIAL SDK

      │

      └── CLOUD API

A vulnerability deep in this dependency chain may affect the final application.

75. Software Bill of Materials — SBOM

A Software Bill of Materials provides a structured inventory of software components and their supply-chain relationships.

NIST defines an SBOM as a formal record containing details and supply-chain relationships of components used to build software.

Think of it conceptually as:

an ingredient list for software.

76. Simplified SBOM Example

77. Why SBOMs Matter

If a serious vulnerability is discovered in:

Crypto Library 2.9

an organization can ask:

Which applications contain it?

Without component visibility, this process may be slow or unreliable.

NIST notes that SBOMs can improve software-component transparency and help organizations more rapidly identify affected components when vulnerabilities emerge.

78. SBOM Does Not Automatically Make Software Secure

An SBOM tells you what components are present.

It does not automatically prove:

• the software is vulnerability free;

• components are correctly configured;

• code is malicious-code free;

• security controls are effective.

Exam trap:

Visibility is not the same as security.

79. SBOM Lifecycle

SOFTWARE DESIGN

      │

      ▼

COMPONENT SELECTION

      │

      ▼

BUILD

      │

      ▼

SBOM GENERATED

      │

      ▼

PRODUCT RELEASE

      │

      ▼

VULNERABILITY DISCOVERED

      │

      ▼

SBOM SEARCH

      │

      ▼

AFFECTED PRODUCTS IDENTIFIED

      │

      ▼

REMEDIATE

Part XV — Provenance

80. What Is Provenance?

Provenance concerns the origin and history of a product, component, or artifact.

Questions include:

• Who created it?

• Where did it originate?

• How was it produced?

• Has it changed?

• Can its history be trusted?

81. Software Provenance

Software provenance can help establish:

• source;

• build process;

• component origin;

• artifact history.

NIST software-supply-chain guidance emphasizes maintaining provenance information for internal and third-party components as an important secure-software practice.

82. Provenance Versus SBOM

They complement each other.

Part XVI — Hardware Trust Mechanisms

83. Silicon Root of Trust

The CISSP exam outline identifies a silicon root of trust as an example supply-chain mitigation.

At a high level, a hardware root of trust provides a hardware-based foundation from which trustworthy security operations can begin.

Possible functions may support:

• device identity;

• secure boot;

• cryptographic operations;

• integrity verification.

84. Root-of-Trust Concept

TRUSTED HARDWARE FOUNDATION

          │

          ▼

VERIFY EARLY BOOT COMPONENT

          │

          ▼

VERIFY NEXT COMPONENT

          │

          ▼

OPERATING ENVIRONMENT

          │

          ▼

APPLICATIONS

The principle is:

Trust begins from a protected foundation rather than assuming every component is trustworthy.

85. Physically Unclonable Function — PUF

The current CISSP outline also explicitly identifies physically unclonable functions as a supply-chain mitigation example.

A PUF uses unique physical characteristics arising from manufacturing variation to produce device-specific responses.

At exam level, associate PUFs with:

• device uniqueness;

• hardware identity;

• anti-counterfeit assurance;

• cryptographic support.

86. PUF Conceptual Diagram

PHYSICAL DEVICE

     │

     ▼

UNIQUE MANUFACTURING

CHARACTERISTICS

     │

     ▼

CHALLENGE

     │

     ▼

DEVICE-SPECIFIC RESPONSE

Do not confuse a PUF with ordinary software-generated identifiers.

Part XVII — Software Build and Update Security

87. Build Pipeline Risk

Software may pass through:

DEVELOPER

    │

    ▼

SOURCE REPOSITORY

    │

    ▼

BUILD SYSTEM

    │

    ▼

PACKAGE REPOSITORY

    │

    ▼

UPDATE SERVER

    │

    ▼

CUSTOMER

Compromise anywhere in the chain may affect downstream software.

88. Protect the Build Environment

Possible controls include:

• strong access control;

• MFA;

• signed commits or artifacts;

• protected repositories;

• build isolation;

• logging;

• dependency management;

• code review;

• secure CI/CD practices.

Detailed secure software development will be taught under Domain 8.

89. Software Updates

Updates are trusted pathways into systems.

Therefore, organizations should consider:

• update source;

• authenticity;

• integrity;

• digital signing;

• delivery protection.

A malicious update can transform a trusted mechanism into an attack vector.

Part XVIII — Open-Source Software Risk

90. Open Source Is Not Automatically Insecure

Open-source software can provide substantial value.

Risk depends on factors such as:

• maintenance;

• provenance;

• vulnerabilities;

• dependencies;

• community support;

• update practices.

91. Dependency Risk

An organization may rely on a library without realizing that the library depends on many other projects.

Therefore, the effective supply chain can be much larger than expected.

Part XIX — Cloud and Managed-Service Risk

92. Cloud Providers

Cloud providers may host:

• infrastructure;

• applications;

• databases;

• identity services.

This creates concentration and dependency risk.

93. Shared Responsibility

Outsourcing infrastructure does not eliminate customer responsibilities.

The exact division depends on:

• service model;

• contract;

• architecture.

Detailed cloud architecture will be covered later.

94. Managed Service Providers

Managed providers may hold privileged access to many customer systems.

Compromise of an MSP may therefore produce broad downstream consequences.

Part XX — Third-Party Access

95. Vendor Access Should Be Controlled

Third-party accounts should follow:

• identification;

• authentication;

• authorization;

• least privilege;

• monitoring;

• lifecycle management.

96. Temporary Access

Contractor access should not become permanent merely because the account was forgotten.

Access should have:

• owner;

• business justification;

• expiration;

• periodic review.

Part XXI — Supplier Incident Management

97. Supplier Incidents Are Organizational Incidents

If a critical provider experiences a breach, your organization may still face:

• data exposure;

• downtime;

• customer impact;

• legal obligations.

Therefore:

A vendor's breach can become your incident.

98. Third-Party Incident Flow

SUPPLIER INCIDENT

       │

       ▼

NOTIFICATION

       │

       ▼

VERIFY SCOPE

       │

       ▼

IDENTIFY YOUR ASSETS / DATA

       │

       ▼

ASSESS BUSINESS IMPACT

       │

       ▼

CONTAIN DEPENDENCY

       │

       ▼

COORDINATE RESPONSE

       │

       ▼

RECOVER / MONITOR

       │

       ▼

REASSESS SUPPLIER RISK

Part XXII — Supplier Resilience

99. Security Is Not Only Confidentiality

A supplier can create risk simply by becoming unavailable.

Organizations should consider:

• service outages;

• financial failure;

• disaster;

• staffing failures;

• geopolitical disruption.

100. Concentration Risk

If every critical application depends on one cloud region or identity provider, failure of that provider may affect the entire organization.

This is concentration risk.

101. Exit Strategy

Before depending heavily on a supplier, ask:

What happens if we need to leave?

Consider:

• data export;

• migration;

• alternate suppliers;

• credential revocation;

• contract termination.

Part XXIII — Supplier Termination and Offboarding

102. Offboarding

When a supplier relationship ends:

• disable access;

• revoke credentials;

• remove integrations;

• recover assets;

• return or destroy data;

• update inventories.

103. Offboarding Flow

CONTRACT ENDS

      │

      ▼

DISABLE ACCESS

      │

      ▼

REVOKE KEYS / TOKENS

      │

      ▼

REMOVE CONNECTIVITY

      │

      ▼

RETURN / DESTROY DATA

      │

      ▼

VERIFY COMPLETION

      │

      ▼

ARCHIVE EVIDENCE

Part XXIV — Current NIST C-SCRM Development

104. Current Guidance

NIST's primary C-SCRM publication, SP 800-161 Rev. 1, integrates cybersecurity supply-chain risk management with organizational risk-management processes. Its current version includes updates through November 2024.

NIST also released two significant C-SCRM publications in 2026:

• SP 800-18 Rev. 2, published June 2026, addressing security, privacy, and cybersecurity supply-chain risk-management plans for systems.

• SP 1326, finalized in July 2026, providing a due-diligence assessment quick-start guide for ICT suppliers.

These publications are useful contemporary references, but CISSP candidates should prioritize the concepts listed in the ISC2 examination outline.

Part XXV — SierraTec Secure Integrated Third-Party Risk Model

105. TRUST Model

Use the SierraTec Secure TRUST model for supplier scenarios.

T — Target and Business Need

What service or product is being acquired?

R — Risk and Criticality

What could happen if the supplier is compromised or unavailable?

U — Understand the Supplier

What does due diligence reveal?

S — Set Security Requirements

What controls, contracts, SLAs, and monitoring are required?

T — Track Throughout the Lifecycle

Monitor, reassess, respond, and terminate securely.

106. TRUST Model Diagram

T

TARGET

What are we acquiring?

    │

    ▼

R

RISK

How critical is it?

    │

    ▼

U

UNDERSTAND

Assess supplier and dependencies

    │

    ▼

S

SET REQUIREMENTS

Controls + contract + SLA

    │

    ▼

T

TRACK

Monitor → reassess → terminate

Part XXVI — Worked Threat-Model Scenarios

107. Scenario 1 — New Web Application

A development team has completed a new customer portal and asks security to conduct threat modeling immediately before production deployment.

What would have been a BETTER approach?

A. Wait until after an incident.

B. Begin threat modeling during architecture and design.

C. Perform only vulnerability scanning.

D. Eliminate threat modeling.

Correct Answer

B

Threat modeling can influence architecture more effectively when performed early.

108. Scenario 2 — Trust Boundary

A web application sends sensitive customer data to an external analytics provider.

Which should receive particular attention during threat modeling?

A. Office furniture.

B. The trust boundary between the enterprise and external provider.

C. Employee parking.

D. Printer color.

Correct Answer

B

109. Scenario 3 — STRIDE

An attacker modifies a transaction amount while it is being processed.

Which STRIDE category applies MOST directly?

A. Spoofing.

B. Tampering.

C. Repudiation.

D. Denial of service.

Correct Answer

B

110. Scenario 4 — Disclosure

A cloud database is accidentally configured for public access.

Which STRIDE category is MOST relevant?

A. Information Disclosure.

B. Tampering.

C. Repudiation.

D. Elevation of Privilege.

Correct Answer

A

111. Scenario 5 — Privilege

A regular user exploits an application defect to become an administrator.

Which category applies?

A. Elevation of Privilege.

B. Information Disclosure.

C. Denial of Service.

D. Repudiation.

Correct Answer

A

Part XXVII — Worked Supply-Chain Scenarios

112. Scenario 6 — New Supplier

A business unit wants to purchase a critical cloud service.

What should security do FIRST?

A. Approve it because the provider is popular.

B. Determine criticality and perform appropriate supplier due diligence.

C. Ignore supplier risk.

D. Wait for a breach.

Correct Answer

B

113. Scenario 7 — Provider Certification

A supplier presents a security certification.

What is the BEST conclusion?

A. No further risk analysis is necessary.

B. Certification may provide evidence, but the organization should evaluate whether the supplier satisfies its specific risk requirements.

C. The supplier can never be breached.

D. All third-party risk has been transferred.

Correct Answer

B

114. Scenario 8 — SBOM

A critical software vulnerability is disclosed.

What is an SBOM MOST useful for?

A. Automatically patching every system.

B. Identifying software products that contain affected components.

C. Replacing vulnerability management.

D. Encrypting application data.

Correct Answer

B

115. Scenario 9 — Cybersecurity SLA

A supplier contract specifies 99.99% availability.

What does this MOST directly establish?

A. A measurable service expectation.

B. Guaranteed perfect security.

C. Absence of cyber risk.

D. Elimination of business continuity requirements.

Correct Answer

A

116. Scenario 10 — Supplier Breach

A payroll provider experiences a breach involving employee information.

What should the organization do FIRST?

A. Ignore the incident because the data was hosted externally.

B. Activate established third-party incident-response and impact-assessment processes.

C. Delete all employee information.

D. Terminate every supplier.

Correct Answer

B

Part XXVIII — Common CISSP Exam Traps

117. Trap — Famous Vendor Means Low Risk

Brand recognition does not eliminate risk.

Perform risk-based assessment.

118. Trap — Outsourcing Transfers Accountability

A supplier may perform the service.

The organization still owns its business obligations.

119. Trap — Certification Equals Guaranteed Security

Certifications provide evidence.

They do not guarantee:

• zero vulnerabilities;

• zero incidents;

• suitability for every business requirement.

120. Trap — SLA Equals Security

An SLA defines expectations.

It does not replace controls or monitoring.

121. Trap — SBOM Equals Vulnerability Scanner

An SBOM inventories components.

A vulnerability-management process determines exposure and remediation.

122. Trap — Threat Modeling Equals Penetration Testing

Threat modeling is largely anticipatory and architectural.

Penetration testing evaluates security through active testing.

123. Trap — Vulnerability Scanning Finds Every Threat

A scanner may not identify:

• business-logic abuse;

• trust-boundary problems;

• supplier failure;

• architecture flaws.

124. Trap — Trust Internal Systems Automatically

Threat modeling should question assumptions.

Internal does not automatically mean safe.

125. Trap — Assess Vendor Once

Risk changes throughout the supplier lifecycle.

Continuous monitoring matters.

126. Trap — Direct Supplier Is the Entire Supply Chain

Your supplier may depend on many other suppliers.

Think about fourth-party and nth-party dependencies.

Part XXIX — Knowledge Check

127. Knowledge Check

Question 1

What is the primary purpose of threat modeling?

A. Purchase security tools.

B. Systematically identify potential threat scenarios and appropriate mitigations.

C. Replace risk management.

D. Eliminate every vulnerability.

Correct Answer

B

Question 2

Which term refers to the points where an attacker might interact with a system?

A. Attack surface.

B. Risk appetite.

C. SLA.

D. SBOM.

Correct Answer

A

Question 3

Which term refers to the method used to attack a target?

A. Attack vector.

B. Risk capacity.

C. Baseline.

D. Custodian.

Correct Answer

A

Question 4

What is an attack path?

A. The sequence an attacker may follow to reach an objective.

B. A risk policy.

C. A physical emergency exit.

D. A vendor contract.

Correct Answer

A

Question 5

Where should special controls be considered when trust assumptions change?

A. Trust boundary.

B. Parking lot.

C. Risk register.

D. Asset label.

Correct Answer

A

Question 6

What does the S in STRIDE represent?

A. Security.

B. Spoofing.

C. Scanning.

D. Supply chain.

Correct Answer

B

Question 7

Which STRIDE category corresponds to unauthorized modification?

A. Tampering.

B. Spoofing.

C. Repudiation.

D. Disclosure.

Correct Answer

A

Question 8

Which STRIDE category primarily threatens confidentiality?

A. Information Disclosure.

B. Denial of Service.

C. Tampering.

D. Repudiation.

Correct Answer

A

Question 9

Which threat corresponds most directly to availability?

A. Denial of Service.

B. Spoofing.

C. Tampering.

D. Repudiation.

Correct Answer

A

Question 10

What does elevation of privilege involve?

A. Obtaining permissions beyond authorization.

B. Lowering availability.

C. Encrypting information.

D. Creating an SLA.

Correct Answer

A

Question 11

What is a primary purpose of supplier due diligence?

A. Gather information needed for informed acquisition-risk decisions.

B. Eliminate contracts.

C. Transfer every risk.

D. Replace security monitoring.

Correct Answer

A

Question 12

Which is specifically listed by ISC2 as a supply-chain risk?

A. Counterfeit products.

B. Office lighting.

C. Keyboard layout.

D. Desktop color.

Correct Answer

A

Question 13

Which is another explicitly listed supply-chain risk?

A. Product tampering.

B. Employee vacation.

C. Printer paper.

D. Screen resolution.

Correct Answer

A

Question 14

What does SBOM stand for?

A. Secure Business Operations Model.

B. Software Bill of Materials.

C. Security Backup Operations Matrix.

D. Software Baseline Oversight Method.

Correct Answer

B

Question 15

What is the primary purpose of an SBOM?

A. Provide visibility into software components and dependencies.

B. Encrypt software.

C. Replace authentication.

D. Guarantee secure code.

Correct Answer

A

Question 16

What is software provenance concerned with?

A. Origin and history of software/components.

B. System uptime.

C. Firewall performance.

D. User training.

Correct Answer

A

Question 17

Which is a supply-chain risk mitigation explicitly listed by ISC2?

A. Third-party assessment and monitoring.

B. Eliminating all vendors.

C. Trusting popular providers automatically.

D. Removing contractual requirements.

Correct Answer

A

Question 18

Which control helps identify unique hardware characteristics?

A. Physically unclonable function.

B. SLA.

C. Risk register.

D. Hash table.

Correct Answer

A

Question 19

What is fourth-party risk?

A. Risk from a supplier used by your third-party provider.

B. Risk from your fourth employee.

C. A fourth firewall.

D. Risk eliminated by insurance.

Correct Answer

A

Question 20

When should critical third-party risk be assessed?

A. Only after a breach.

B. Throughout the relationship lifecycle.

C. Only when the contract ends.

D. Never if the supplier has a certification.

Correct Answer

B

Part XXX — Original CISSP-Style Scenario Practice

128. Practice Question 1

A security architect is designing an online payment application.

At which point would threat modeling generally provide the GREATEST value?

A. Only after production deployment.

B. During design while architectural changes remain practical.

C. Only after the first incident.

D. After system retirement.

Correct Answer

B

129. Practice Question 2

An application accepts unauthenticated requests from an external network and forwards them directly to a sensitive internal service.

What should the architect examine MOST closely?

A. Trust-boundary controls.

B. Employee dress code.

C. Vendor logo.

D. Desktop wallpaper.

Correct Answer

A

130. Practice Question 3

A security team identifies ten vulnerabilities individually but fails to consider that three can be chained together to obtain privileged database access.

What was MOST likely missing?

A. Attack-path analysis.

B. Asset labeling.

C. CPE tracking.

D. Insurance.

Correct Answer

A

131. Practice Question 4

A supplier has strong internal security but uses an unknown subcontractor to host sensitive customer information.

What should the organization consider?

A. Fourth-party risk.

B. Only physical security.

C. No additional risk.

D. Only internal employee risk.

Correct Answer

A

132. Practice Question 5

A company requires an SBOM from software vendors.

What is the MOST important benefit?

A. Greater visibility into software components and dependencies.

B. Automatic prevention of vulnerabilities.

C. Elimination of secure coding requirements.

D. Guaranteed vendor availability.

Correct Answer

A

133. Practice Question 6

A highly critical supplier passed an assessment three years ago, but the organization has not reviewed it since.

What should the security manager recommend?

A. Continue trusting the original assessment indefinitely.

B. Perform risk-based reassessment and continuous monitoring.

C. Eliminate the contract automatically.

D. Stop collecting supplier information.

Correct Answer

B

134. Practice Question 7

A software update distributed through an otherwise trusted vendor contains malicious code.

Which risk does this BEST illustrate?

A. Software supply-chain compromise.

B. Physical environmental risk.

C. Password complexity risk.

D. Employee training risk.

Correct Answer

A

135. Practice Question 8

A procurement manager wants to select a supplier solely because it offers the lowest price.

What should occur FIRST from a security perspective?

A. Evaluate supplier criticality and security risk.

B. Sign immediately.

C. Eliminate due diligence.

D. Grant administrative access.

Correct Answer

A

136. Practice Question 9

A vendor's service is critical to production but the contract contains no incident-notification requirement.

What is the GREATEST concern?

A. The organization may not receive information needed to assess and respond promptly to supplier incidents.

B. The vendor may use a different operating system.

C. The contract is too short.

D. The vendor has no company logo.

Correct Answer

A

137. Practice Question 10

A business unit terminates a cloud supplier but leaves API keys active.

Which process has MOST clearly failed?

A. Supplier offboarding.

B. Threat intelligence.

C. Data classification.

D. Quantitative risk analysis.

Correct Answer

A

Part XXXI — Key Terms

138. Key Terms

Threat Modeling

Structured analysis of potential threat scenarios against a system or process.

Threat Actor

Entity capable of intentionally causing harm.

Threat Source

Origin or circumstance capable of causing harm.

Threat Event

Event capable of producing adverse consequences.

Attack Vector

Method or avenue used to attack a target.

Attack Surface

Collection of potential points of interaction or attack.

Attack Path

Sequence through which an attacker may reach an objective.

Trust Boundary

Point where security assumptions or trust levels change.

Data-Flow Diagram

Visual representation of how data moves among entities, processes, and stores.

STRIDE

Threat-category framework: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.

Attack Tree

Hierarchical representation of alternative ways an attacker may achieve an objective.

Misuse Case

Scenario showing how functionality could be used maliciously.

Supply Chain

Organizations, components, processes, and services contributing to a product or service.

Third Party

External organization directly providing a product or service.

Fourth Party

Supplier used by one of the organization's third parties.

Nth Party

Dependency deeper in the extended supply chain.

Product Tampering

Unauthorized alteration of a product or component.

Counterfeit

Unauthorized imitation represented as legitimate.

Malicious Implant

Intentionally inserted functionality designed to enable harmful activity.

Due Diligence

Research and evaluation used to support informed supplier decisions.

SLA

Service-Level Agreement establishing measurable service expectations.

SBOM

Software Bill of Materials—a record of software components and dependency relationships.

Provenance

Origin and history of a product, component, or software artifact.

Silicon Root of Trust

Hardware-based foundation used to establish trustworthy security operations.

Physically Unclonable Function

Hardware mechanism using unique physical characteristics to generate device-specific responses.

Concentration Risk

Risk caused by excessive dependency on one provider, technology, location, or service.

Part XXXII — CISSP Exam Focus

139. Threat-Modeling Mindset

Remember:

WHAT ARE WE PROTECTING?

        ↓

HOW DOES IT WORK?

        ↓

WHERE ARE THE TRUST BOUNDARIES?

        ↓

WHAT COULD GO WRONG?

        ↓

HOW COULD IT HAPPEN?

        ↓

WHAT WOULD THE IMPACT BE?

        ↓

WHAT SHOULD MITIGATE IT?

        ↓

DID THE MITIGATION WORK?

For CISSP questions:

• Threat modeling should be integrated into design rather than delayed until an incident.

• Identify assets before selecting controls.

• Understand data flows.

• Pay particular attention to trust boundaries.

• Attack surfaces describe exposure points.

• Attack vectors describe attack methods.

• Attack paths describe sequences.

• STRIDE is one useful threat-category methodology.

• Threat modeling is not the same as vulnerability scanning.

• Threat intelligence can inform threat models but does not replace them.

• Reduce unnecessary attack surface.

• Threat models must evolve when systems and threats change.

140. Supply-Chain Mindset

Remember:

BUSINESS REQUIREMENT

        ↓

SUPPLIER CRITICALITY

        ↓

DUE DILIGENCE

        ↓

SUPPLY-CHAIN RISK

        ↓

SECURITY REQUIREMENTS

        ↓

CONTRACT / SLA

        ↓

ONBOARDING

        ↓

CONTINUOUS MONITORING

        ↓

INCIDENT MANAGEMENT

        ↓

OFFBOARDING

For CISSP questions:

• A trusted supplier can still create significant risk.

• Outsourcing does not eliminate organizational accountability.

• Third-party certifications provide evidence but do not eliminate the need for risk analysis.

• Supplier assessment should be proportional to criticality.

• Product tampering, counterfeits, and implants are explicit SCRM concerns.

• Minimum security requirements should be defined before onboarding.

• SLAs create measurable expectations but do not guarantee security.

• Supplier monitoring continues throughout the relationship.

• Fourth-party and nth-party dependencies matter.

• SBOMs improve component visibility but do not guarantee secure software.

• Provenance concerns origin and history.

• Hardware trust mechanisms can help protect component authenticity and device trust.

• Supplier incidents should be incorporated into organizational incident response.

• Access and data must be securely handled when the relationship ends.

141. Lesson Summary

Threat modeling allows security professionals to reason about attacks before they happen.

You learned to identify:

• assets;

• threat sources;

• threat events;

• attack vectors;

• attack surfaces;

• attack paths;

• trust boundaries.

You examined several threat-modeling techniques, including:

• data-flow analysis;

• STRIDE;

• attack trees;

• misuse cases;

• abuse cases.

You learned that threat modeling asks more than:

“Which vulnerabilities exist?”

It asks:

How could the architecture, identities, interfaces, business logic, dependencies, and trust relationships be abused?

The lesson then expanded the risk perspective beyond organizational boundaries.

Modern organizations rely on complex supply ecosystems containing:

• vendors;

• cloud providers;

• contractors;

• hardware manufacturers;

• software suppliers;

• open-source components;

• subcontractors.

The current CISSP outline specifically expects candidates to recognize risks such as product tampering, counterfeit products, malicious implants, and supply-chain acquisition risk, along with mitigations including third-party assessment and monitoring, minimum security requirements, service-level requirements, silicon roots of trust, physically unclonable functions, and SBOMs.

You learned that:

An organization may outsource a service, but it cannot simply outsource accountability for its mission, data, customers, or risk.

You also learned that an SBOM increases visibility into software components but is not itself proof that software is secure. NIST describes SBOMs as formal records of software components and their supply-chain relationships and highlights their value for improving transparency and identifying affected software when vulnerabilities emerge.

The central Lesson Five principle is therefore:

Trust should be understood, bounded, verified, monitored, and continuously reassessed—whether that trust applies to a user, system, software component, supplier, or entire supply chain.

Exam Readiness Check

Before proceeding to Lesson Six, make sure you can explain:

• What threat modeling is.

• Why threat modeling should start early.

• What a threat actor is.

• What a threat source is.

• What a threat event is.

• What an attack vector is.

• What an attack surface is.

• What an attack path is.

• Why trust boundaries matter.

• How data-flow diagrams support threat modeling.

• Why assumptions should be documented.

• What STRIDE stands for.

• How each STRIDE category maps to a security property.

• What an attack tree is.

• What misuse and abuse cases accomplish.

• How threat intelligence supports threat modeling.

• Why threat modeling differs from vulnerability scanning.

• What attack-surface reduction means.

• What cybersecurity supply-chain risk means.

• Why organizations often have limited visibility into extended supply chains.

• What product tampering is.

• What counterfeit-product risk is.

• What a malicious implant is.

• What third-party risk is.

• What fourth-party risk is.

• What nth-party risk is.

• Why supplier criticality affects assessment depth.

• What supplier due diligence means.

• Why third-party monitoring is continuous.

• What minimum security requirements accomplish.

• What an SLA accomplishes.

• Why an SLA does not guarantee security.

• What an SBOM is.

• What an SBOM does not provide.

• What provenance means.

• What a silicon root of trust represents.

• What a PUF represents at a high level.

• Why software updates are part of the supply chain.

• Why supplier incident response must connect to organizational incident response.

• Why offboarding includes access revocation and data disposition.

• Why outsourcing does not automatically transfer accountability.

If you can explain these concepts and apply them to practical scenarios, you are ready to continue.

Coming Next

Lesson Six: Legal, Regulatory, Privacy, Compliance, and Investigation Foundations

Lesson Six will address the legal and compliance subjects that should not be mixed too deeply into the earlier governance and supply-chain lessons.

Topics will include:

• legal systems affecting cybersecurity;

• laws versus regulations;

• contractual requirements;

• industry standards;

• jurisdiction;

• cybercrime;

• data breaches;

• privacy;

• personal information;

• data-protection principles;

• data minimization;

• purpose limitation;

• retention;

• transborder data flows;

• intellectual property;

• copyright;

• trademarks;

• patents;

• trade secrets;

• software licensing;

• import/export considerations;

• contractual security obligations;

• compliance;

• evidence;

• investigations;

• administrative investigations;

• criminal investigations;

• civil investigations;

• regulatory investigations;

• incident evidence;

• legal counsel;

• law enforcement;

• chain of custody;

• original CISSP-style legal and compliance scenarios.

Lesson Six will preserve the CISSP perspective:

Security professionals must recognize legal and regulatory issues, preserve appropriate evidence, and involve qualified legal authorities when interpretation or legal decisions are required.

Publication and Independence Notice

This lesson is independently developed educational material for the SierraTec Secure CISSP Certification Preparation Course.

CISSP is administered by ISC2. SierraTec Secure's program is independent exam-preparation material and should not be represented as official ISC2 courseware unless separately authorized.

The principal examination alignment for this lesson was verified against the current ISC2 CISSP examination outline. Objective 1.10 addresses threat-modeling concepts and methodologies, while Objective 1.11 addresses Supply Chain Risk Management and specifically identifies product tampering, counterfeits, implants, third-party assessment and monitoring, minimum security requirements, service-level requirements, silicon roots of trust, physically unclonable functions, and software bills of materials.

Current supplemental C-SCRM references include NIST SP 800-161 Rev. 1 with its November 2024 updates, NIST SP 800-18 Rev. 2 released in June 2026, and NIST SP 1326 finalized in July 2026.

The explanations, SierraTec Secure TRUST model, diagrams, scenarios, examples, tables, knowledge checks, and practice questions are original course material and are not actual, recalled, leaked, or official CISSP examination questions.