Dependency Confusion and Typosquatting: Audit Your Package Controls Before Attackers Do

One Package Mistake Can Change the Entire Build

A developer wants to install a trusted package.

They type the name incorrectly.

A package still installs.

The build succeeds.

Nobody notices.

However, the package came from an attacker.

Another attack can be even quieter.

Your company may use a private package called:

An attacker discovers that name.

Next, they publish the same name to a public registry.

Their package has a higher version number.

As a result, the build may select the wrong package.

These are software supply chain risks.

Therefore, internal audit should ask:

What Is Dependency Confusion?

Dependency confusion happens when a build selects a public package instead of the intended private package.

A typical scenario looks like this:

OWASP describes this attack as a public package using the same name as a private package.

A higher public version may then win during resolution.

The package may execute during:

• Development.
• Testing.
• CI/CD.
• Build.
• Deployment.

By then, malicious code may already have reached credentials, source code, or build systems.

What Is Typosquatting?

Typosquatting uses a different trick.

The attacker creates a package name that looks like a trusted one.

A developer makes a small typing mistake.

The package manager follows the request.

Then the wrong package installs.

Therefore, package security should not depend only on human attention.

Technical controls should help prevent the mistake.

Why This Belongs in ISO 27001 Internal Audit

Dependency confusion and typosquatting affect more than development.

A malicious package may compromise:

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

Therefore, package controls can affect secure development, change management, vulnerability management, and ICT supply chain risk.

That makes them relevant to ISO 27001 internal audit.

1. Audit Where Packages Can Come From

Start with package sources.

Ask:

Examples include:

• npm.
• PyPI.
• Maven Central.
• NuGet.
• GitHub Packages.
• Internal artifact repositories.
• Private container registries.

Next, inspect the actual configuration.

Internal Audit Should Check

• Approved registries are documented.
• Private packages use controlled repositories.
• Public sources are restricted where needed.
• Developers cannot silently add arbitrary registries.
• CI/CD uses approved settings.
• Repository changes require approval.

OWASP recommends using controlled repositories and trusted sources.

2. Test Internal Package Naming

Internal package names can create dependency confusion risk.

Ask:

Private names may leak through manifests, public repositories, or error messages.

Therefore, internal audit should review:

• Naming conventions.
• Namespace controls.
• Scoped packages.
• Public registry conflicts.
• Private package exposure.

For example, instead of:

A supported ecosystem may use:

The exact method depends on the package manager.

The goal is simple: prevent public packages from being mistaken for internal packages.

3. Test Registry Resolution Rules

This is one of the most important technical checks.

Ask:

Do not accept “It should use the internal one.”

Test the configuration.

Review settings for:

• npm.
• pip.
• NuGet.
• Maven.

Useful Audit Evidence

• .npmrc
• pip.conf
• nuget.config
• Maven settings.
• Repository manager configuration.
• CI/CD configuration.
• Private registry policy.

The goal is deterministic and intentional package resolution.

4. Review Version Pinning

Flexible versions can make development easier.

However, they can also allow unexpected changes.

For example:

OWASP recommends version pinning and fixed dependency references as useful controls.

Internal Audit Should Ask

• Are production dependencies pinned?
• Are version ranges permitted?
• If yes, why?
• Are lockfiles used?
• Are dependency updates reviewed?

Version pinning is not enough by itself.

However, it can reduce unexpected package changes.

5. Audit Lockfiles

Lockfiles record the exact dependency versions used in a build.

Common examples include:

• package-lock.json
• yarn.lock
• poetry.lock
• Pipfile.lock

Internal audit should test whether lockfiles are:

• Generated.
• Stored in source control.
• Reviewed.
• Updated through change management.
• Used during CI/CD builds.

6. Test Package Integrity

The correct package name and version are not enough.

Ask:

Integrity controls may include:

• Cryptographic hashes.
• Checksums.
• Digital signatures.
• Package provenance.
• Trusted publishing.
• Controlled artifact repositories.

OWASP recommends checking downloaded package integrity against trusted values.

Modern package systems may also provide provenance information.

7. Review Every New Dependency

A package should not enter production only because a developer typed a command.

For example:

Instead, new dependencies should receive suitable review.

Useful questions include:

• Why is this package needed?
• Is there already an approved alternative?
• Who maintains it?
• How old is it?
• Does it have known vulnerabilities?
• Does it use suspicious install scripts?
• Is the source repository legitimate?
• Is the package name correct?
• What could it access during installation?

Dependency review tools can also show package additions and updates during pull requests.

A Stronger Process

8. Test Typosquatting Defences

Typosquatting often works because package installation feels routine.

Therefore, controls should go beyond:

Possible controls include:

• Internal allowlists.
• Approved package catalogs.
• Repository proxies.
• Dependency review.
• Package-age checks.
• Publisher verification.
• Automated malware detection.

OWASP also warns against blindly installing packages suggested by AI coding tools.

Practical Audit Test

Select several recently introduced packages.

Verify:

• The package name.
• The publisher.
• The expected repository.
• The package history.
• The security review.
• The approval evidence.

The goal is to test whether suspicious packages are likely to be caught.

9. Add AI-Generated Dependencies to the Audit

AI coding assistants create a newer supply chain issue.

An AI assistant may suggest a package that:

• Exists.
• Is outdated.
• Is the wrong package.
• Does not exist at all.

OWASP warns that AI tools may suggest nonexistent dependencies.

An attacker may later register that name as a malicious package.

Therefore, internal audit should ask:

AI can suggest a dependency. It should not establish trust in that dependency.

10. Review CI/CD Enforcement

Package controls are weak if developers can bypass them.

Therefore, internal audit should test whether CI/CD enforces:

Ask

• Can a developer disable package security checks?
• Can a failing scan still deploy?
• Who can change the pipeline?
• Do pipeline changes require review?

The pipeline should enforce policy, not simply show warnings.

11. Audit Private Registry Security

Private package registries can reduce some supply chain risks.

However, a private registry is not automatically secure.

Audit:

• Who can publish packages?
• Who can modify packages?
• Can packages be overwritten?
• Are deleted packages recoverable?
• Are malware scans enabled?
• Are access logs retained?
• Are tokens protected?
• Are upstream public packages controlled?

OWASP notes that private repositories still need strong provenance and entry controls.

12. Test the Malicious Package Scenario

A practical test can reveal more than a policy review.

Ask the team:

The team should be able to identify:

• Which repositories contain it.
• Which applications depend on it.
• Which versions were used.
• Which builds included it.
• Which environments received it.
• Which credentials may have been exposed.
• Who owns remediation.

Dependency graphs and related security tools can support this investigation.

If the team must ask developers one by one, package visibility may be weak.

ISO 27001 Controls to Consider

Dependency confusion and typosquatting do not have dedicated ISO 27001 control names.

However, the risks connect to several ISO/IEC 27001:2022 controls.

The exact mapping should reflect your development process, risk assessment, scope, and Statement of Applicability.

Evidence Internal Audit Should Request

A useful audit evidence pack may include:

You do not need every item for every application.

Use risk-based sampling.

Common Internal Audit Findings

Watch for these common patterns.

Quick Package Security Audit Checklist

Before closing the audit, confirm:

Connect Package Security Evidence to Your ISMS

Development teams may keep technical evidence in repositories and CI/CD tools.

However, ISO 27001 findings and risk records may sit elsewhere.

That separation can make audit traceability harder.

Canadian Cyber’s ISMS SharePoint Solution can help centralize:

Frequently Asked Questions

The Takeaway

Developers should not have to win a spelling contest to keep software secure.

Build systems should not decide trust only because one version number is higher.

A stronger control environment can answer:

That is what an ISO 27001 internal audit should test.

A strong model looks like:

Package managers are powerful automation tools.

Attackers know that too.

Audit the package controls before they do.

Stay Connected With Canadian Cyber

Follow Canadian Cyber for practical guidance on ISO 27001 internal audits, secure development, package security, software supply chains, SharePoint ISMS, and cybersecurity governance.