ISO 27001

Software Supply Chain

SBOM

Internal Audit

Your Dependency Tree Is Part of Your ISMS: ISO 27001 Internal Audit Tests for Software Supply Chain Risk

Learn how ISO 27001 internal auditors can test dependencies, SBOMs, open-source software, CI/CD controls, package integrity, suppliers, and software supply chain risk.

Your Application Is More Than the Code Your Team Writes

Your development team writes the application.

However, they probably do not write every piece of software inside it.

Modern applications may include:

Open-source libraries
Frameworks
Packages
Container images
SDKs
APIs
Build tools
SaaS services
Commercial components
Transitive dependencies

One package may depend on another package.

That second package may depend on five more.

As a result, even a small application can have a large dependency tree.

From an ISO 27001 perspective, that dependency tree matters.

Why?

A vulnerable or compromised package can still affect your information security.

The same is true for an abandoned library or malicious update.

Weak audit question: “Do developers scan their code?”

Better question: Can the organization prove what its software depends on, where those dependencies came from, and how supply chain risk is controlled?

Quick Answer

How Should Internal Audit Test Software Supply Chain Risk?

An ISO 27001 internal audit should treat software dependencies as part of the security risk environment.

Auditors should test whether the organization can:

  • Identify software dependencies.
  • Generate or obtain an SBOM.
  • Track direct and transitive dependencies.
  • Detect vulnerable components.
  • Verify trusted package sources.
  • Control dependency updates.
  • Review third-party software risk.
  • Protect the CI/CD pipeline.
  • Respond quickly to vulnerable components.
  • Retain evidence that the controls operate.

Bottom line: if your software cannot operate without a component, that component belongs in your security risk picture.

Why Your Dependency Tree Matters

A dependency tree shows the components an application relies on.

A simple example may look like this:

Customer Portal

↓

Web Framework

↓

Authentication Library

↓

Cryptographic Package

↓

Operating System Library

Your team may have selected the web framework.

However, it may never have selected the package several layers below it.

That does not remove the risk.

NIST defines an SBOM as a formal record of software components and their supply chain relationships.

NIST also notes that SBOMs can improve transparency and support faster vulnerability response.

You cannot manage a vulnerable dependency if you do not know you use it.

1. Start With the Software Dependency Inventory

The first audit test is visibility.

Ask the development team:

What third-party and open-source components are inside this application?

The answer should not depend on one developer’s memory.

Useful sources include:

  • Package manifests.
  • Lock files.
  • Build configuration.
  • Container manifests.
  • Software composition analysis tools.
  • SBOMs.
  • Repository scans.
  • Artifact repositories.

Evidence to Request

  • Dependency inventory.
  • SBOM.
  • Package manifests.
  • Package lock files.
  • Container component reports.
  • Software composition analysis results.
  • Approved technology lists.

Then compare that evidence with what is actually built and deployed.

Audit red flag: the development team says it uses 20 libraries, but automated analysis finds 430 components.

2. Ask for an SBOM

A Software Bill of Materials gives structured visibility into software components.

Think of it as an ingredient list for software.

NIST recommends SBOM capabilities that catalogue software components.

It also recommends linking SBOM information with vulnerability detection.

CISA updated its SBOM Minimum Elements guidance in 2025.

The updated guidance includes information such as:

  • Component name.
  • Component version.
  • Software identifiers.
  • Component hash.
  • License.
  • Dependency relationships.
  • Tool name.
  • Timestamp.
  • Generation context.

These details can make SBOMs useful audit evidence.

Internal Audit Should Ask

  • Do we generate SBOMs?
  • Which applications have them?
  • When are they generated?
  • Are transitive dependencies included?
  • Are SBOMs updated when software changes?
  • Are they linked to vulnerability monitoring?
  • Can we find production systems that use a vulnerable component?

An SBOM stored in a folder is not enough.

It should support real risk management.

3. Test Direct and Transitive Dependencies

Direct dependencies are packages your team intentionally adds.

Transitive dependencies are packages those packages rely on.

Transitive dependencies are easy to miss.

Your Application

uses

Package A

which requires

Package B

which requires

Package C

If Package C has a critical vulnerability, your organization may still be exposed.

Therefore, security scanning should go beyond first-level dependencies.

Ask Whether Your Tools Identify

  • Direct dependencies.
  • Transitive dependencies.
  • Operating system packages.
  • Container packages.
  • Development dependencies.
  • Runtime dependencies.

A complete dependency tree creates better visibility.

4. Check Where Packages Come From

Knowing the package name is not enough.

You also need to know its source.

Developers may retrieve software from:

Public package repositories
Internal artifact repositories
Vendor repositories
Git repositories
Container registries
Third-party websites

Internal audit should ask which sources are trusted.

Next, test whether technical controls enforce that decision.

Evidence to Review

  • Approved package sources.
  • Internal registry configuration.
  • Repository restrictions.
  • Package verification.
  • Digital signatures.
  • Hash verification.
  • Artifact approval processes.

The goal is to reduce downloads from unknown or manipulated sources.

5. Test Dependency Vulnerability Management

Finding dependencies is only the first step.

Next, ask:

What happens when a dependency becomes vulnerable?

A strong process should connect the vulnerability to ownership and remediation.

Dependency → Vulnerability → Application → Risk → Owner → Remediation

NIST’s Secure Software Development Framework recommends integrating secure development into the software lifecycle.

Internal Audit Should Check

  • Are dependencies scanned regularly?
  • Are new vulnerabilities monitored?
  • Are findings prioritized by risk?
  • Can affected applications be identified?
  • Are remediation owners assigned?
  • Are remediation deadlines tracked?
  • Is risk acceptance documented?
  • Are fixes verified?

Do not only ask whether a scanning tool exists.

Ask what happens after the tool finds something.

Can You Trace a Vulnerable Package Back to Business Risk?

Canadian Cyber can help test dependency inventories, SBOMs, vulnerability handling, CI/CD controls, supplier risk, and ISO 27001 evidence.

The goal is to connect technical software risk with your ISMS.

6. Test the Critical Library Scenario

A practical audit test is simple.

A critical vulnerability is announced today in a widely used library. Show me how you determine whether we use it.

Then observe the response.

Can the team quickly identify:

  • Which applications contain the component?
  • Which versions are deployed?
  • Which environments are affected?
  • Whether the vulnerable function is reachable?
  • Who owns the affected applications?
  • What compensating controls exist?
  • When remediation will occur?

If the answer requires emailing every developer, visibility may be weak.

A stronger process should move quickly from:

Vulnerability Announced → Exposure Understood

7. Review Dependency Update Controls

Keeping packages updated is important.

However, blindly updating packages creates another risk.

A malicious update can enter through the normal development process.

Therefore, internal audit should test how dependency changes are controlled.

Look For

  • Pull request reviews.
  • Automated dependency update tools.
  • Security checks.
  • Version pinning.
  • Build testing.
  • Change approval.
  • Staging before production.
  • Rollback capability.

OWASP’s Software Component Verification Standard focuses on software supply chain controls.

The objective is balance.

Do not leave vulnerable packages unchanged forever.

However, do not treat every new version as automatically trustworthy.

8. Review the CI/CD Pipeline

The software supply chain includes more than libraries.

The pipeline that builds and deploys software also creates risk.

Internal audit should review:

Source repositories
Build systems
CI/CD platforms
Artifact repositories
Container registries
Deployment tooling
Signing systems
Pipeline secrets

Ask

  • Who can modify the pipeline?
  • Who can approve production deployments?
  • Which service accounts does the pipeline use?
  • Can developers bypass security scans?
  • Are build artifacts protected?
  • Are pipeline credentials privileged?

A secure application built through an insecure pipeline is still a supply chain risk.

9. Review Open-Source Governance

Open-source software is not automatically insecure.

However, it still needs governance.

Internal audit should review how teams introduce new components.

Useful Checks

Ask whether teams consider:

  • Security history.
  • Maintenance status.
  • Release activity.
  • Known vulnerabilities.
  • Licensing.
  • Package reputation.
  • Community support.
  • Business criticality.

A popular package can still become abandoned.

Therefore, the organization needs a plan for unmaintained critical dependencies.

Audit question: Do we know which critical applications depend on abandoned software?

10. Review Supplier-Provided Software

Your dependency tree does not stop with software you build.

Third-party software may contain its own components.

Therefore, vendor risk and software supply chain risk overlap.

NIST’s software supply chain guidance connects SBOMs, vendor risk, open-source controls, and vulnerability management.

Internal Audit Should Ask

For critical suppliers, check:

  • Do contracts include security requirements?
  • Does the supplier follow secure development practices?
  • Can the supplier provide an SBOM?
  • How are vulnerabilities disclosed?
  • How quickly are critical issues fixed?
  • Are security updates provided?
  • What happens when a vendor dependency becomes vulnerable?

This turns supplier security into a real risk-management process.

11. Test Package and Artifact Integrity

Internal audit should also test software integrity.

A component may change between development and production.

For example, a developer approves version 4.2.

How does the organization prove that production received the same package?

Useful controls may include:

  • Cryptographic hashes.
  • Digital signatures.
  • Controlled artifact repositories.
  • Protected build environments.
  • Restricted deployment permissions.

CISA’s updated 2025 SBOM guidance added component hash as a minimum data field.

This can improve both integrity and traceability.

12. Connect Supply Chain Risk to the ISMS

This is where many organizations struggle.

Development teams may manage technical issues in GitHub, Azure DevOps, Jira, or another platform.

That is fine.

However, material security risk should still connect to the ISMS.

Critical Dependency

↓

Known Vulnerability

↓

Business Application

↓

Information Security Risk

↓

Applicable Control

↓

Remediation Owner

↓

Evidence

↓

Residual Risk

This creates traceability.

The ISMS does not need to copy every technical ticket.

Instead, it should show that significant risk is identified, assessed, owned, treated, and monitored.

ISO 27001 Controls to Consider

Software supply chain risk can affect several ISO/IEC 27001:2022 controls.

ISO 27001 Control Internal Audit Focus
A.5.19 Information Security in Supplier Relationships Are software supplier risks managed?
A.5.20 Security Within Supplier Agreements Do agreements include security requirements?
A.5.21 Managing Information Security in the ICT Supply Chain Are ICT supply chain risks identified and controlled?
A.5.22 Monitoring and Change Management of Supplier Services Are supplier security changes monitored?
A.8.8 Management of Technical Vulnerabilities Are vulnerable components identified and fixed?
A.8.25 Secure Development Life Cycle Is supply chain security included in development?
A.8.28 Secure Coding Are secure development practices applied?
A.8.29 Security Testing in Development and Acceptance Are applications and components tested?
A.8.30 Outsourced Development Is external development governed?
A.8.32 Change Management Are dependency and software changes controlled?

The exact controls should reflect your ISMS scope, risks, development model, and Statement of Applicability.

What Evidence Should Internal Audit Request?

A useful software supply chain audit pack may include:

  • Application inventory.
  • Dependency inventories.
  • SBOMs.
  • Package manifests.
  • Lock files.
  • Software composition analysis reports.
  • Vulnerability scan results.
  • Dependency remediation tickets.
  • Risk acceptance records.
  • Approved package sources.
  • Artifact repository configuration.
  • CI/CD security configuration.
  • Build logs.
  • Code review evidence.
  • Supplier security assessments.
  • Software security requirements.
  • Penetration test results.
  • Change records.
  • Incident records.

You do not need every item for every application.

Evidence should be proportional to risk.

Common ISO 27001 Internal Audit Findings

Watch for these patterns.

No Complete Dependency Inventory
The team knows direct packages but not transitive dependencies.
Outdated SBOM
The SBOM was created once and never updated.
No Remediation Owner
Scanning finds issues, but nobody owns the fixes.
No Approved Package Sources
Developers can download software from anywhere.
Abandoned Critical Dependencies
The business relies on unmaintained software.
Vulnerable Components Stay in Production
There is no clear remediation process.
CI/CD Bypass
Critical scan failures do not stop deployment.
Vendor Software Blind Spot
Supplier reviews ignore development and dependency risk.
Risk Never Reaches the ISMS
Technical teams know the issue, but the risk register does not.

Quick Software Supply Chain Audit Checklist

Before closing the audit, confirm:

  • Critical applications are inventoried.
  • Dependencies can be identified.
  • Direct and transitive dependencies are considered.
  • SBOMs are generated where appropriate.
  • SBOMs are updated when software changes.
  • Approved package sources are defined.
  • Dependency vulnerabilities are scanned.
  • Critical findings have owners.
  • Remediation timelines are risk-based.
  • Risk acceptance is documented.
  • Dependency updates follow change controls.
  • CI/CD pipelines are secured.
  • Build identities follow least privilege.
  • Artifacts are protected from unauthorized changes.
  • Critical software suppliers are assessed.
  • Supplier security requirements are defined.
  • Significant supply chain risks enter the ISMS.
  • Audit evidence is retained.

Connect Software Supply Chain Risk to Your SharePoint ISMS

Technical teams may manage dependency issues in development tools.

However, ISO 27001 evidence often sits somewhere else.

That separation can make audit traceability difficult.

Canadian Cyber’s ISMS SharePoint Solution can help centralize:

ICT Supplier Registers
Risk Assessments
Control Ownership
SBOM References
Vulnerability Evidence
Internal Audit Findings
Corrective Actions
Supplier Reviews
Review Dates
Management Reporting

This creates a clearer trail between the technical issue and the ISMS.

Frequently Asked Questions

What is software supply chain risk?

Software supply chain risk comes from the components, suppliers, tools, and services used to build software.

It can include open-source libraries, commercial packages, CI/CD systems, vendors, and cloud services.

What is a software dependency tree?

A dependency tree shows the components an application relies on.

It can include both direct and transitive dependencies.

What is an SBOM?

A Software Bill of Materials is a structured record of software components and their supply chain relationships.

Does ISO 27001 require an SBOM?

ISO 27001 does not prescribe an SBOM for every organization.

However, an SBOM can provide useful security evidence.

Its use should be risk-based.

Is vulnerability scanning enough?

No.

Scanning identifies potential weaknesses.

The organization must still assess risk, assign owners, fix issues, document exceptions, and verify closure.

Should internal audit review open-source software?

Yes, when open-source components create information security risk.

The audit should focus on selection, tracking, updates, scanning, and retirement.

Should third-party SaaS be included?

Yes, where SaaS creates material information security risk.

The depth of review should depend on business criticality and risk.

The Takeaway

Your developers may write only part of your application.

The rest may come from many upstream components.

Those components form a dependency tree.

That tree can introduce vulnerabilities, abandoned software, compromised packages, licensing issues, and supplier risk.

Therefore, it belongs in your information security risk landscape.

Internal audit should be able to answer:

What software do we depend on?
Where did it come from?
Which version are we running?
What depends on it?
Is it vulnerable?
Who owns remediation?
Can an unauthorized package enter the build?
Can we identify affected applications quickly?
Does significant risk reach the ISMS?

If these answers depend on developer memory, the control environment needs work.

A stronger model is:

Dependency → SBOM → Vulnerability → Risk → Owner → Remediation → Evidence

That is how the software supply chain becomes auditable.

Make Software Supply Chain Risk Part of Your ISO 27001 Internal Audit

Canadian Cyber helps organizations test secure development, software supply chain risk, supplier controls, vulnerability management, cloud environments, and audit evidence.

We also help organizations connect technical findings with corrective actions and ISO 27001 risk management.

Our ISMS SharePoint Solution can centralize supplier registers, risk assessments, control ownership, SBOM references, vulnerability evidence, findings, review dates, and management reporting.

Stay Connected With Canadian Cyber

Follow Canadian Cyber for practical guidance on ISO 27001 internal audits, software supply chain risk, secure development, SharePoint ISMS, supplier risk, and cybersecurity governance.