ISO 27001

Open Source

Software Supply Chain

Internal Audit

Third-Party Code, First-Party Risk: Internal Audit Questions for Open-Source Dependencies

Learn how ISO 27001 internal auditors can test open-source dependencies, vulnerabilities, ownership, provenance, maintenance, SBOM coverage, and software supply chain risk.

Third-Party Code Can Still Create First-Party Risk

Your developers did not write every line of your application.

That is normal.

Modern software depends on open-source libraries, frameworks, packages, SDKs, containers, and development tools.

However, problems begin when organizations assume:

“It is open source, so someone else is responsible for the security.”

Once a dependency enters your application, the risk becomes yours.

A vulnerable library can affect customers.

A malicious package can compromise a build.

An abandoned component can create technical debt.

A compromised maintainer can introduce unwanted code.

Even a transitive dependency can reach production.

Therefore, an open-source dependency audit should ask more than:

“Do you scan open-source packages?”

A stronger question is:

What evidence proves that the open-source software we rely on is known, trusted, monitored, and controlled?

Quick Answer

What Should an Open-Source Dependency Audit Test?

A strong open-source dependency audit should test:

  • Which open-source components are used.
  • Why significant dependencies were selected.
  • Where packages are obtained.
  • Whether projects are actively maintained.
  • Whether vulnerabilities are monitored.
  • Whether transitive dependencies are visible.
  • Whether versions are controlled.
  • Whether provenance can be checked.
  • Who owns dependency risk.
  • How abandoned packages are replaced.
  • Whether SBOMs match deployed software.
  • Whether dependency changes are reviewed and tested.

OWASP’s 2025 Top 10 places Software Supply Chain Failures at A03.

Bottom line: third-party code does not mean third-party accountability.

Open Source Is Not the Problem

Open-source software is essential to modern development.

The goal is not to ban it.

Instead, the goal is to manage it.

NIST recommends checking open-source components for known vulnerabilities.

It also recommends secure channels and trustworthy repositories.

Open-source use should be visible and intentional.

If unknown dependencies can enter production without review, the organization has a governance gap.

1. Ask: What Open-Source Software Do We Use?

Start with visibility.

Ask the development team for an inventory of open-source components.

Useful sources include:

  • SBOMs.
  • Package manifests.
  • Lockfiles.
  • Software composition analysis.
  • Container scans.
  • Build records.
  • Artifact repositories.

Do not review direct dependencies only.

One package may add many more packages.

OWASP highlights missing transitive dependency visibility as a supply chain weakness.

Audit question: Can we identify every important open-source component inside our critical applications?

If the answer depends on developer memory, visibility is weak.

2. Ask: Who Approved This Dependency?

Open-source packages can enter software very quickly.

A developer may run:

npm install
pip install

Minutes later, the package may become part of the application.

Therefore, important dependencies should leave a decision trail.

Useful Evidence

  • Pull request.
  • Dependency review.
  • Technical approval.
  • Security scan.
  • Architecture review.
  • Risk assessment.
  • Change record.

The key issue is accountability.

Someone should be able to explain why the package was introduced.

3. Ask: Where Did the Package Come From?

The package name is not enough.

Internal audit should also verify its source.

Was it obtained from:

  • An approved public registry?
  • An internal artifact repository?
  • A verified vendor repository?
  • A random download link?
  • A personal Git repository?

NIST recommends secure channels and trustworthy repositories.

Audit Evidence

  • Approved registry configuration.
  • Internal repository settings.
  • Package-manager configuration.
  • Repository access controls.
  • Dependency policies.

These controls can also reduce dependency confusion and typosquatting risk.

4. Ask: Is the Project Still Maintained?

A package may be secure today.

However, it may create long-term risk.

Review project health.

  • When was the last release?
  • Are security issues addressed?
  • Are maintainers active?
  • Are dependencies updated?
  • Is the repository archived?
  • Are critical issues unresolved?

A popular package can still become abandoned.

Red flag: a critical customer application depends on a library that has not received a meaningful update in years.

That does not always mean immediate removal.

However, the risk should be understood.

5. Ask: Have We Evaluated the Project’s Security Practices?

Popularity does not prove security.

Even widely used packages can have weak development controls.

OpenSSF Scorecard can provide automated security signals about open-source projects.

Useful signals may include:

Branch protection
Code review
Dependency updates
Security policies
Pinned dependencies
Automated testing
Signed releases

However, do not turn one score into an automatic pass or fail.

Use the score as evidence.

A weaker score may trigger a deeper review.

6. Ask: Do We Know the Transitive Dependencies?

Your developers may intentionally install Package A.

However, Package A may depend on Package B.

Package B may then depend on Package C.

Application → Package A → Package B → Package C

Package C may contain the vulnerability.

Audit Test

Select one important dependency.

Then ask the team to show its transitive dependencies.

Verify that they appear in:

  • The SBOM.
  • The dependency graph.
  • Software composition analysis.

Developers should not need to inspect hundreds of packages manually.

Instead, tooling should provide reliable visibility.

Can You Prove Which Open-Source Components Reach Production?

Canadian Cyber can help test open-source dependencies, SBOMs, vulnerability handling, package sources, ownership, CI/CD controls, and ISO 27001 evidence.

The goal is to turn third-party code into controlled and traceable risk.

7. Ask: How Do We Know When a Dependency Becomes Vulnerable?

A package may be safe when approved.

Later, a new vulnerability may appear.

Therefore, dependency approval is not a one-time activity.

Internal audit should test continuous monitoring.

  • Are dependencies scanned regularly?
  • Are new vulnerabilities detected automatically?
  • Who receives alerts?
  • Are critical findings assigned?
  • Are remediation deadlines defined?
  • Are exceptions documented?
  • Are fixes verified?

NIST recommends vulnerability-response practices for open-source components.

Audit Test

Choose one historical dependency vulnerability.

Then trace:

Alert → Application → Owner → Risk → Remediation → Closure

8. Ask: How Fast Can We Find an Affected Application?

Imagine a critical vulnerability is disclosed today.

Can the organization quickly answer:

Do we use this library?
Which version?
Where is it used?
Is it in production?
Who owns the application?

This is where dependency-management maturity becomes visible.

A Strong Process

New Vulnerability

↓

Component Identified

↓

Inventory Searched

↓

Affected Applications Identified

↓

Owners Notified

↓

Risk Assessed

↓

Remediation Tracked

If the first step is emailing every developer, visibility may be weak.

9. Ask: Are Dependency Versions Controlled?

An approved package can still change.

Therefore, builds should use predictable dependency versions.

Internal audit should review:

  • Version pinning.
  • Lockfiles.
  • Dependency update tools.
  • Pull-request reviews.
  • Automated testing.

OpenSSF includes dependency pinning and automated updates among useful security signals.

Audit question: Can the same source code produce a different dependency set tomorrow without approval?

10. Ask: Can We Verify Package Provenance?

A package may have the correct name.

It may also have the expected version.

However, you should still verify where it came from.

NIST guidance recommends examining provenance for external components.

Evidence May Include

  • Package signatures.
  • Provenance attestations.
  • Trusted publishing.
  • Repository metadata.
  • Cryptographic hashes.
  • Controlled artifact repositories.

Not every ecosystem supports the same controls.

Therefore, apply provenance checks based on risk.

11. Ask: Who Owns Open-Source Risk?

This is an important governance question.

Dependency security may involve:

Developers
DevSecOps
Application Owners
Product Security
IT Security

Shared responsibility is acceptable.

However, accountability should not disappear between teams.

Development: selects the package.

Security: provides scanning.

Application Owner: accepts residual risk.

DevSecOps: manages automated updates.

Internal Audit: verifies the process.

Responsibilities may differ, but ownership should stay clear.

12. Ask: What Happens When a Project Is Abandoned?

Not every dependency fails because of a vulnerability.

Some projects simply stop receiving updates.

Internal audit should identify:

  • Archived repositories.
  • Abandoned projects.
  • Unsupported versions.
  • Packages with no active maintainer.
  • Dependencies that cannot receive security patches.

Then ask:

What is the exit plan?

Possible actions include:

  • Upgrade.
  • Replace the package.
  • Fork and maintain it internally.
  • Use compensating controls.
  • Accept the risk for a defined period.

“No one has looked at it” is not a risk treatment.

13. Ask: Are Critical Dependencies Treated Differently?

Not every package needs the same level of review.

For example, an authentication framework may need more scrutiny than a formatting library.

Use a risk-based approach.

Consider:

  • Application criticality.
  • Data sensitivity.
  • Privilege.
  • Network exposure.
  • Dependency depth.
  • Maintainer health.
  • Vulnerability history.
  • Ease of replacement.

Useful Classification

Low Risk
Limited impact and easy replacement.
Medium Risk
Important functionality with moderate exposure.
High Risk
Sensitive, privileged, exposed, or difficult to replace.

14. Ask: Can Developers Introduce Any Package They Want?

Strong vulnerability scanning does not fix weak entry controls.

Ask:

Can anyone add any dependency to production?

Stronger controls may include:

  • Approved package lists.
  • Repository proxies.
  • Dependency review.
  • Pull-request approval.
  • Software composition analysis.
  • Security gates for high-risk packages.

The objective is not unnecessary bureaucracy.

Instead, it is to prevent silent supply chain changes.

15. Ask: Does the SBOM Match Production?

An SBOM can help internal audit.

However, it must describe the software that is actually running.

Compare:

Production Release ↔ SBOM Release

Then sample dependency versions.

If production runs 5.9 but the SBOM shows 5.2, its audit value drops.

Audit question: Which open-source dependencies are actually deployed today?

16. Ask: What Happens When a Maintainer Account Is Compromised?

Open-source risk is not limited to accidental vulnerabilities.

A legitimate project can also be compromised.

For example:

  • A maintainer account is hijacked.
  • A malicious contributor gains publishing rights.
  • A compromised release is distributed.
  • Package ownership changes.

Internal audit should test whether downstream controls reduce the impact.

Useful controls may include:

  • Version pinning.
  • Change review.
  • Package integrity checks.
  • Provenance.
  • Delayed updates.
  • Artifact repositories.
  • Dependency scanning.

Trust should not depend entirely on an upstream maintainer.

17. Ask: Are Open-Source Components Included in Incident Response?

Suppose a malicious package reaches production.

Can the organization:

  • Identify affected applications?
  • Stop new builds?
  • Block the package?
  • Remove compromised versions?
  • Rotate exposed credentials?
  • Rebuild trusted artifacts?
  • Notify customers where required?

Open-source dependency risk should connect to incident response.

A software supply chain incident is still an information security incident.

ISO 27001 Controls to Consider

Open-source dependency risk can affect several ISO/IEC 27001:2022 areas.

ISO 27001 Control Internal Audit Focus
A.5.21 ICT Supply Chain Are software supply chain risks controlled?
A.8.8 Technical Vulnerabilities Are dependency vulnerabilities identified and treated?
A.8.19 Installation of Software Is software introduction controlled?
A.8.25 Secure Development Life Cycle Are dependency controls built into development?
A.8.26 Application Security Requirements Are external-component requirements defined?
A.8.28 Secure Coding Are third-party components introduced securely?
A.8.29 Security Testing Are dependencies included in security testing?
A.8.32 Change Management Are dependency additions and updates controlled?

Other controls may apply based on suppliers, cloud services, outsourcing, and the Statement of Applicability.

Evidence Internal Auditors Should Request

A useful evidence pack may include:

  • Open-source policy.
  • Application inventory.
  • Dependency inventory.
  • SBOMs.
  • Package manifests.
  • Lockfiles.
  • Software composition analysis results.
  • Dependency review records.
  • OpenSSF Scorecard results where used.
  • Approved registries.
  • Package approval records.
  • Pull requests.
  • Vulnerability findings.
  • Remediation tickets.
  • Risk acceptances.
  • Build logs.
  • Package provenance evidence.
  • Incident records.
  • Change records.

Use sampling.

You do not need to inspect every package manually.

Instead, prove that the control process works.

Common Open-Source Dependency Audit Findings

Watch for these common patterns.

Open Source Is Invisible
Applications use many dependencies, but no complete inventory exists.
Approval Ends at Installation
The package is approved once but never monitored later.
Vulnerabilities Have No Owner
Scanning finds problems, but nobody owns remediation.
Abandoned Packages Stay in Production
Unsupported components have no replacement process.
Transitive Dependencies Are Ignored
Only direct packages are tracked.
Popularity Is Treated as Security
Teams assume high download numbers prove safety.
SBOM Does Not Match Production
Component evidence is stale.
Any Developer Can Add Dependencies
No package approval control exists.
Provenance Is Not Considered
Teams know the package name but not its origin.
Critical Dependencies Have No Exit Plan
High-risk components have no replacement strategy.

Quick Open-Source Dependency Audit Checklist

Before closing the audit, confirm:

  • Open-source dependencies are inventoried.
  • Direct and transitive dependencies are visible.
  • Approved package sources are defined.
  • Important new dependencies receive review.
  • Package provenance is considered where useful.
  • Critical project health is assessed.
  • Vulnerabilities are continuously monitored.
  • Findings have owners.
  • Remediation timelines are defined.
  • Dependency versions are controlled.
  • Lockfiles are used where appropriate.
  • SBOMs reflect production releases.
  • High-risk dependencies receive deeper review.
  • Abandoned components are identified.
  • Replacement or risk-treatment plans exist.
  • Dependency changes follow change control.
  • Significant supply chain risks reach the ISMS.
  • Incident response includes compromised dependencies.
  • Audit evidence is retained.

Connect Open-Source Risk to Your SharePoint ISMS

Technical teams may track dependencies in development platforms.

However, ISO 27001 risks and evidence may sit somewhere else.

That separation makes traceability harder.

Canadian Cyber’s ISMS SharePoint Solution can help centralize:

Application Registers
Software Supply Chain Risks
SBOM References
Vulnerability Findings
Control Ownership
Internal Audit Evidence
Corrective Actions
Risk Acceptances
Review Dates
Dependency → Risk → Control → Evidence → Finding → Corrective Action

Frequently Asked Questions

Is open-source software a third-party risk?

Yes.

The organization relies on code developed outside its direct control.

Does ISO 27001 prohibit open-source software?

No.

ISO 27001 uses a risk-based approach.

Open-source software can be used securely when it is properly governed.

Should every open-source dependency require security approval?

Not necessarily.

A risk-based process is usually more practical.

What evidence proves an open-source dependency is secure?

No single item proves absolute security.

Useful evidence includes vulnerability status, maintenance, provenance, scans, review, version controls, and monitoring.

What if a package has no known vulnerabilities?

Do not stop there.

Also check maintenance, provenance, ownership, package source, and support status.

No known CVEs does not automatically mean low risk.

Are transitive dependencies part of the audit?

Yes.

They can introduce risk even when developers did not select them directly.

What should happen when an open-source project becomes abandoned?

The organization should assess the risk.

It can replace, upgrade, maintain, isolate, or temporarily accept the dependency.

The Takeaway

Open-source code may be written by someone else.

However, the risk becomes yours once you ship it.

Therefore, internal audit should move beyond:

“Do we use open source?”

Instead, ask:

What do we use?
Why did we trust it?
Where did it come from?
Who maintains it?
What does it depend on?
Is it still supported?
How do we detect new vulnerabilities?
Who owns the response?
Can we replace it?

A strong model looks like:

Dependency → Source → Risk Review → Approved Version → Monitoring → Vulnerability → Remediation → Evidence

That is how third-party code becomes managed first-party risk.

Need Help Auditing Open-Source and Software Supply Chain Risk?

Canadian Cyber helps organizations review open-source dependencies, SBOMs, secure development, CI/CD controls, technical vulnerabilities, and software supply chain risk.

We also help organizations test audit evidence and corrective actions as part of ISO 27001 internal audits.

Our ISMS SharePoint Solution can centralize applications, risks, SBOM references, vulnerability evidence, findings, owners, risk acceptances, and review dates.

Stay Connected With Canadian Cyber

Follow Canadian Cyber for practical guidance on ISO 27001 internal audits, open-source security, software supply chains, secure development, vulnerability management, and SharePoint ISMS.