Identity
What exact dependency, source, version, supplier, and owner are we talking about?
High School AdvancedA11.5Secure Software Architecture
Lesson A11.5
Dependency and Supply Chain Risk Concepts
Modern software depends on packages, libraries, SDKs, build tools, registries, managed services, suppliers, and many other components. Secure architecture must understand those dependencies as part of the product — not as invisible implementation details.
This lesson uses fictional inventories and metadata only. You will evaluate ownership, source, version, support, runtime role, reachability, privilege, update difficulty, evidence, exceptions, and retirement without scanning or exploiting any real component.
Lesson Progress
Dependency and Supply Chain Risk Concepts
High School Advanced • A11: Secure Software Architecture • Lesson 5 of 10
50% complete
Readiness Check
A11.5 Entry Readiness
0/4 ready
Professional Hook
Your Code Is Not the Whole Product
A fictional engineering team may write only part of an application. The final service could still depend on an identity SDK, database driver, messaging client, scheduling vendor, build service, artifact-signing service, test framework, container image, and many transitive components.
If one of those components becomes unsupported, changes supplier, drifts from the approved version, loses an owner, or becomes difficult to update, the software architecture inherits that risk.
Dependencies are architecture decisions with lifecycle responsibilities.
Learning Objectives
Five Capabilities for This Lesson
1
Explain why dependency and software supply-chain risk includes more than package version numbers.
2
Evaluate fictional dependencies using ownership, business importance, provenance, support status, maintenance health, exposure, privilege, update path, validation evidence, and replacement difficulty.
3
Distinguish dependency presence, runtime use, reachable functionality, known risk, observed activity, and confirmed impact.
4
Design a defensive dependency-governance workflow covering intake, approval, inventory, update, exception, validation, monitoring, replacement, and retirement.
5
Build a dependency risk register that becomes the fifth artifact in the A11 Secure Software Design Assessment.
Why It Matters
Dependency Risk Is Contextual
Two applications can use the same component but have different risk because they use different functionality, environments, privileges, data, exposure, controls, or versions.
That is why professional dependency review asks for context instead of reacting only to package age or severity labels.
Context
Where is it used, what does it do, what can it access, and which trust boundaries does it cross?
Evidence
What supports the current status, and what remains Unknown?
Core Framework
Eight Stages of Dependency Governance
01
Discover
What dependencies does the software actually rely on?
Identify direct packages, important transitive dependencies, external services, registries, build tools, images, plugins, SDKs, and other third-party components that materially affect the software.
Evidence: Dependency inventory, lock metadata, build records, supplier list, architecture diagram.
02
Classify
Why does this dependency matter?
Record business purpose, runtime role, privilege, exposure, data access, criticality, environment, and whether the dependency participates in build, release, or production behavior.
Evidence: Architecture mapping, runtime use notes, data-flow map, service-owner input.
03
Approve
Is the source and maintenance model acceptable?
Review source, provenance, licensing or policy constraints, support status, maintainer activity, supplier trust, approved registry, and update expectations.
Evidence: Approval record, source metadata, support note, supplier review, policy exception.
04
Pin and record
Can the team identify exactly what version or artifact is intended?
Record approved versions, integrity or provenance metadata where available, expected source, ownership, and build linkage so the team can distinguish intended artifacts from drift.
Evidence: Lock record, artifact metadata, version inventory, build manifest, ownership record.
05
Monitor
What changes could affect dependency risk?
Track support status, important advisories, ownership changes, supplier changes, version drift, new runtime use, environment exposure, and stale exceptions.
Evidence: Dependency dashboard, advisory review record, source-health metrics, exception register.
06
Update
How should the team change versions safely?
Review compatibility, release notes, business impact, test evidence, rollback, dependent services, configuration changes, and validation before moving to a new version.
Evidence: Change record, test results, release notes, rollback plan, approval evidence.
07
Exception
What happens when an immediate update is not practical?
Create a narrow, time-bounded, owned exception with rationale, compensating controls, monitoring, validation, target date, and closure criteria.
Evidence: Exception record, owner approval, mitigation plan, review date.
08
Replace or retire
When should the team stop depending on the component?
Replace unsupported, unmaintained, incompatible, unnecessary, or strategically risky dependencies when the residual risk or maintenance burden is no longer acceptable.
Evidence: Migration plan, replacement decision, validation evidence, retirement record.
Risk Dimensions
Ten Questions That Change Dependency Priority
Business importance
What happens to the product if the dependency fails, changes, or becomes unavailable?
Example: A date-formatting helper and the central identity SDK do not have the same business impact.
Runtime use
Is the dependency only present in development, used during build, or active in the released application?
Example: A test-only package should not automatically be treated as production runtime exposure.
Reachability
Does the software actually use the functionality connected to the concern?
Example: Installed code is not automatically the same as active, reachable functionality.
Privilege
What access or authority does the component have in the intended environment?
Example: A build tool with artifact-signing access deserves stronger governance than a local formatting utility.
Data sensitivity
Does the component process private, confidential, authentication, or security-relevant data?
Example: A logging integration handling audit events may require different review than a static icon package.
Exposure
Where is the dependency used and which trust boundaries does it cross?
Example: A package used only in an offline build step differs from an internet-facing application component.
Provenance
Can the team identify the approved source, artifact, supplier, and version?
Example: An ambiguous package source weakens confidence even when the version number looks current.
Maintenance health
Is the dependency supported, actively maintained, and receiving appropriate updates?
Example: An abandoned component can become a long-term architecture risk even without a current incident.
Update difficulty
How hard is it to validate, replace, or roll back the dependency?
Example: A deeply embedded framework may require a larger migration plan than a small isolated library.
Ownership
Who is accountable for version review, exceptions, updates, and retirement?
Example: Unowned dependencies often remain stale because everyone assumes someone else is reviewing them.
Vocabulary
Dependency and Supply-Chain Terms
Dependency
A library, package, SDK, service, build tool, plugin, image, supplier component, or other external element the software relies on.
Direct dependency
A component the project intentionally includes or references directly.
Transitive dependency
A component included because another dependency relies on it.
Provenance
Evidence describing where software or an artifact came from and how its identity can be related to an approved source or build process.
Dependency inventory
A maintained record of important components, versions, sources, owners, environments, roles, and lifecycle status.
Support status
Whether a component is currently maintained and supported by its project, supplier, or organization.
Reachability
Whether the software actually uses or can invoke the functionality relevant to a dependency concern.
Version drift
A difference between the approved or expected dependency version and what is recorded in another environment or artifact.
Supply chain
The people, projects, registries, tools, services, builds, artifacts, and suppliers that contribute to software delivery.
Exception
A governed, time-bounded decision to temporarily accept a dependency condition that does not meet the normal standard.
Compensating control
A safeguard used to reduce risk when the preferred control or update cannot be implemented immediately.
Retirement
The controlled removal of a dependency and its associated permissions, configuration, build references, ownership, and monitoring responsibilities.
Evidence Discipline
Presence, Reachability, Activity, and Impact Are Different Claims
Dependency findings become misleading when reviewers jump from “the component exists†directly to “the application was harmed.†Strong analysis keeps each claim separate.
The dependency is present.
Supporting evidence: Inventory, lock metadata, manifest, build record, or artifact record.
Limitation: Presence alone does not prove runtime use, reachability, harmful activity, or impact.
The dependency is used at runtime.
Supporting evidence: Architecture mapping, runtime package record, service-owner evidence, artifact composition.
Limitation: Runtime presence alone does not prove a specific risky function is reachable.
Relevant functionality is reachable.
Supporting evidence: Safe design review, code-path evidence, approved test evidence, feature mapping.
Limitation: Reachability does not prove harmful use or confirmed impact.
A known risk applies to this version.
Supporting evidence: Trusted advisory matched to exact component identity and version.
Limitation: An advisory does not by itself prove the affected function is used or that harm occurred.
Harmful activity occurred.
Supporting evidence: Specific incident or monitoring evidence within an authorized investigation.
Limitation: Dependency age or advisory severity alone cannot establish this claim.
Business impact is confirmed.
Supporting evidence: Application, data, identity, transaction, operational, or user evidence tied to the event.
Limitation: A dependency finding by itself does not prove business impact.
Fake Dashboard
Northbridge Dependency Governance Dashboard
Fictional inventory and lifecycle metadata
Tracked dependencies
126
Direct, material transitive, build, and external service records
Owned records
123 / 126
Three legacy records need ownership resolution
Supported baseline
94%
Four legacy components require migration or exception review
Open exceptions
5
All have owners; two expire within 30 days
Fake SOC Alert
Unsupported Component Migration Required
Source: Fictional Dependency Review • Time: 09:27
DEP-03, the Legacy Report Renderer, remains active in production but its limited support ends this quarter. A replacement project exists but validation is not complete.
Defensive recommendation: Treat support ending as a migration trigger, complete replacement validation, preserve rollback, and retire the old component through an owned plan.
Dependency Register
Seven Fictional Dependency Records
DEP-01Northbridge Identity SDKConfirmed
Role
Staff sign-in and identity claims
Environment
Production
Source
Approved supplier registry
Version
Approved baseline current
Runtime
Active
Privilege
Authentication context
Support
Supported
Owner
Identity Platform Team
Concern
No current exception
Next action
Continue scheduled version and support review.
DEP-02Messaging Client LibraryConditional
Role
Outbound notification queue client
Environment
Production
Source
Approved registry
Version
Two approved minor releases behind target
Runtime
Active
Privilege
Notification service only
Support
Supported
Owner
Notification Service Team
Concern
Update is pending compatibility validation with retry behavior.
Next action
Complete authorized compatibility testing and schedule bounded update.
DEP-03Legacy Report RendererBlocked
Role
Generates staff-only PDF reports
Environment
Production
Source
Approved internal mirror
Version
Legacy baseline
Runtime
Active
Privilege
Reads approved reporting data
Support
Limited support
Owner
Reporting Team
Concern
Replacement project is required because support ends this quarter.
Next action
Execute migration plan, validate replacement, and retire old component.
DEP-04Unit Test HelperConfirmed
Role
Test-only assertion helper
Environment
CI Test
Source
Approved registry
Version
Current
Runtime
Not shipped to production
Privilege
Test environment only
Support
Supported
Owner
Engineering Productivity
Concern
Must remain separated from production artifact.
Next action
Verify build manifest continues to exclude test-only dependency.
DEP-05Scheduling Vendor SDKConditional
Role
External scheduling integration
Environment
Production
Source
Supplier distribution
Version
Current approved
Runtime
Active
Privilege
Approved appointment fields only
Support
Supported
Owner
Integration Owner
Concern
Supplier migration next quarter may change provenance and API behavior.
Next action
Treat supplier migration as architecture and dependency change trigger.
DEP-06Historical CSV UtilityUnknown
Role
Old import workflow
Environment
Maintenance
Source
Unknown historical source
Version
Unknown
Runtime
Unclear
Privilege
Unknown
Support
Unknown
Owner
Unknown
Concern
Source, ownership, active use, version, and support are not established.
Next action
Determine whether the dependency is still needed before any release decision.
DEP-07Release Signing ServiceConfirmed
Role
Approved artifact-signing dependency
Environment
Build / Release
Source
Approved platform service
Version
Managed service
Runtime
Build pipeline only
Privilege
Release-signing authority
Support
Supported
Owner
Release Engineering
Concern
High privilege means ownership and access review must remain current.
Next action
Continue quarterly access and emergency-use review.
Fake Log Panel
Fictional Dependency Review Log
training-log-viewer.log
[08:35] DEP-01 identity-sdk source=APPROVED support=SUPPORTED status=CONFIRMED [08:58] DEP-02 messaging-client update=pending compatibility-validation [09:27] DEP-03 report-renderer support-ending -> migration BLOCKED [09:55] DEP-04 unit-test-helper production-artifact=NOT PRESENT [10:22] DEP-05 supplier-migration flagged as change-trigger [10:47] DEP-06 source=UNKNOWN owner=UNKNOWN runtime-use=UNKNOWN [11:15] DEP-07 signing-service privilege=HIGH owner=ReleaseEngineering status=CONFIRMED
Training note: this is fake data for defensive analysis practice only.
Review Questions
Eighteen Questions for Material Dependencies
1
What exact component or external service is this?
2
Why does the software depend on it?
3
Is it direct, transitive, build-time, test-only, runtime, or external service dependency?
4
Which environment uses it?
5
Who owns the dependency?
6
What source or supplier is approved?
7
Which version or artifact identity is expected?
8
Is the component supported and maintained?
9
What privilege or data access does it have?
10
Which trust boundaries does it cross?
11
Is the relevant functionality actually used or reachable?
12
What security controls reduce dependency risk?
13
What evidence supports the current status?
14
How difficult is update or replacement?
15
What rollback or recovery plan exists?
16
What monitoring detects drift, stale support, or exception expiry?
17
What change triggers require architecture or threat-model review?
18
What retirement criteria close the dependency lifecycle?
Analyze the Evidence
Evidence Analysis: Test-Only Dependency
DEP-04 is a unit-test helper.
The dependency is present in CI Test.
The production artifact record does not include it.
No evidence shows production runtime use.
What is the strongest conclusion about DEP-04?
Update Strategy
A Dependency Update Is a Controlled Change
Updating a dependency can reduce one risk while introducing compatibility, configuration, performance, or operational change. Strong teams use an evidence-based change process.
1
Confirm exact component identity and approved source.
2
Review support status and relevant release information.
3
Understand runtime role, privilege, data access, and dependencies.
4
Define expected behavior and compatibility criteria.
5
Validate in an authorized non-production environment.
6
Review configuration changes and migration notes.
7
Plan rollback and monitoring.
8
Deploy through approved change control.
9
Validate intended version and service behavior after deployment.
10
Update inventory, baseline, exception, and retirement records.
Exceptions
Temporary Risk Must Stay Temporary
Sometimes a dependency cannot be updated immediately because of compatibility, supplier timing, migration complexity, or business constraints. That does not mean the risk should disappear from view.
Scope
Which exact component, version, environment, and workflow are covered?
Rationale
Why is the normal requirement not currently achievable?
Owner
Who is accountable for the exception and closure?
Controls
Which compensating safeguards reduce the temporary risk?
Monitoring
How will the team watch for changes while the exception is active?
Expiration
When must the exception be reviewed or closed?
Target state
What update, migration, replacement, or retirement resolves the exception?
Closure evidence
What evidence proves the temporary condition is gone?
Common Mistakes
Eight Ways Dependency Reviews Go Wrong
1
Treating every outdated package as equal risk
Why it fails: Business importance, runtime use, privilege, exposure, controls, support, and reachability can differ greatly.
Better approach: Prioritize with a consistent risk model and explain the evidence.
2
Looking only at direct dependencies
Why it fails: Important transitive components and supplier services can affect the software too.
Better approach: Maintain an inventory that captures materially important transitive and service dependencies.
3
Assuming newest automatically means safest
Why it fails: A version change can create compatibility, configuration, or operational risk that still needs validation.
Better approach: Use approved update workflows with evidence, rollback, and post-change validation.
4
Ignoring provenance
Why it fails: A familiar package name does not by itself establish that the artifact came from the approved source or build path.
Better approach: Track approved source, artifact identity, version, and build linkage.
5
No owner
Why it fails: Unowned dependencies can remain stale, unsupported, or exception-bound indefinitely.
Better approach: Assign accountable owners for review, updates, exceptions, and retirement.
6
Permanent exceptions
Why it fails: Temporary risk can silently become the normal architecture.
Better approach: Make exceptions narrow, time-bounded, monitored, owned, and linked to closure criteria.
7
Updating without rollback
Why it fails: Compatibility failures can disrupt service or force rushed changes.
Better approach: Plan validation, staged rollout, monitoring, and rollback.
8
Confusing advisory with compromise
Why it fails: Known risk in a dependency does not prove the software was harmed.
Better approach: Separate component risk, reachability, observed activity, and business impact.
Scenario Decision Lab
Scenario Decision Lab 1 — Support Ending
The fictional Legacy Report Renderer remains active in production. Limited support ends this quarter. A replacement component has been selected, but compatibility and rollback validation are not complete.
Scenario Decision Lab
Scenario Decision Lab 2 — Unknown Historical Utility
A historical CSV utility appears in an old maintenance inventory. Its source, version, owner, support status, and current runtime use are all Unknown.
Safe Fictional Lab
Build a Dependency Risk Register
Use fictional components only. Do not scan, download, inspect, exploit, or test real software packages, registries, repositories, services, or systems.
1
Create at least ten fictional dependency records.
2
Give each dependency a stable ID.
3
Record business purpose and application role.
4
Classify direct, transitive, test, build, runtime, or external-service use.
5
Record environment and approved source.
6
Record version or artifact identity metadata.
7
Assign an owner.
8
Record support and maintenance status.
9
Describe privilege, data access, and trust boundaries.
10
Record evidence for runtime use or reachability when relevant.
11
Assign status: Confirmed, Conditional, Unknown, Blocked, or Retired.
12
Define update, exception, replacement, or retirement action.
13
Add change triggers.
14
Add validation and rollback expectations.
Analyze the Evidence
Evidence Analysis: Advisory vs. Impact
The component identity and version match the advisory.
The component is present in the production artifact.
The supplied evidence does not establish whether the affected functionality is reachable.
No incident or business-impact evidence is supplied.
A trusted advisory matches the exact version of a fictional dependency. What is the strongest conclusion?
Advanced Challenge
Design a Dependency Exception That Can Actually Close
Create a fictional exception for a business-critical dependency that cannot be updated for 45 days because the replacement requires a compatibility change.
1
Exact dependency ID and version
2
Business reason for temporary delay
3
Affected environment and workflow
4
Runtime role and privilege
5
Known concern and evidence
6
Compensating controls
7
Monitoring
8
Accountable owner
9
Target update or replacement date
10
Validation plan
11
Rollback plan
12
Expiration date
13
Closure criteria
14
Residual risk statement
Defender Habits
A11.5 Defender Checklist
Skill Check
Seven Questions
Check Your Understanding
A11.5 Mini Quiz: Dependency and Supply Chain Risk Concepts
Choose your answers first. Explanations appear only after submission.
1. Which statement best describes software supply-chain risk?
2. Why is dependency presence different from runtime exposure?
3. A trusted advisory matches a dependency version. What does that prove?
4. Why does dependency ownership matter?
5. What is the strongest response when a supported dependency update is available?
6. What is a strong exception?
7. A legacy dependency has unknown source, version, owner, and runtime use. What is the strongest status?
Portfolio Prompt
Portfolio Build — Dependency Risk Register
Create the fifth artifact for your A11 Secure Software Design Assessment: a fictional dependency risk register with at least ten records. Include ID, component or service name, purpose, dependency type, environment, source or supplier, version or artifact metadata, runtime role, privilege, data access, support status, owner, evidence, status, exception or update plan, validation, rollback, change triggers, and retirement criteria.
Use fictional packages, services, versions, suppliers, registries, and artifacts only.
Include at least one test-only dependency and show why it is not automatically production runtime exposure.
Include at least one Unknown legacy dependency.
Include at least one time-bounded exception.
Include one component approaching end of support with a replacement plan.
Separate advisory evidence, reachability, observed activity, and business impact.
Confidence / Readiness Reflection
Are You Ready for A11.6?
A11.6 moves to Secure Error Handling and Logging. Before continuing, check whether you can explain dependency risk without turning every component finding into a claim of compromise.
1
I can identify direct, transitive, build, test, runtime, and external-service dependencies.
2
I can evaluate ownership, source, support, runtime role, privilege, exposure, and replacement difficulty.
3
I can separate component presence, reachability, advisory match, observed activity, and confirmed impact.
4
I can design a governed update or exception process with validation and rollback.
5
I can define when a dependency should be replaced or retired.
Portfolio Build Guide
How to Make the Dependency Register Look Professional
Use stable IDs
Give each material dependency a unique identifier so architecture, review, testing, release, and maintenance evidence can reference it.
Show dependency role
Distinguish test-only, build-time, runtime, service, and privileged dependencies.
Show exact context
Record environment, business purpose, source, version, support status, data access, and privilege.
Show evidence limits
Do not claim compromise or impact from version data alone.
Show ownership
Every material dependency should have an accountable review and maintenance owner.
Show update readiness
Record validation, compatibility, rollback, monitoring, and deployment expectations.
Show exceptions
Keep exceptions narrow, time-bounded, owned, monitored, and connected to closure criteria.
Show retirement
Unsupported, unnecessary, or strategically risky dependencies should have a clear replacement or retirement path.
Key Takeaways
What You Should Remember
1.Dependency risk is contextual: identity, source, runtime use, reachability, privilege, exposure, support, ownership, and business impact all matter.
2.A package being present does not automatically mean the relevant functionality is used at runtime.
3.A known advisory does not prove compromise or business impact.
4.Provenance and approved source matter because software identity is more than a package name.
5.Ownership is essential for updates, exceptions, support review, migration, and retirement.
6.Updates should be validated changes with rollback, not automatic production actions.
7.Exceptions must be temporary, visible, owned, monitored, and tied to closure criteria.
8.Unsupported or strategically risky components require replacement or retirement planning.
9.The dependency risk register becomes a core input to code review, testing, release readiness, and maintenance.
Lesson Safety Boundary
Dependency review is defensive governance
This lesson does not authorize scanning, downloading, probing, exploiting, fuzzing, modifying, or testing real packages, registries, repositories, services, devices, applications, or networks. Use fictional inventories and supplied metadata only.
Lesson Complete
A11.5 Dependency and Supply Chain Risk Concepts Complete
You now have a dependency-governance framework covering identity, provenance, support, ownership, runtime role, reachability, updates, exceptions, replacement, and retirement. Next, A11.6 focuses on Secure Error Handling and Logging.