Supply chain risk detection · Issue #112 · git-pkgs/git-pkgs · GitHub
Skip to content

Supply chain risk detection #112

Description

@andrew

Extension candidate: git-pkgs-risk. All three checks are audit-style operations you'd run occasionally, not core workflow. The extension can consume git pkgs list --format json for the package list and make its own registry/API calls for the analysis. Keeps the core binary focused on history and metadata while this handles threat detection.

Three related checks that help catch malicious or risky packages before they cause problems.

Typosquatting detection

Check dependency names against known popular packages for suspicious similarity.

Patterns to detect: character substitution (djang0 vs django), character omission (loadsh vs lodash), delimiter variation (cross-env vs crossenv vs cross_env), scope confusion (@angular-devkit/core vs @angulardevkit/core), and combosquatting (lodash-js, axios-api).

git-pkgs already knows every package name in the repo. A check could compute edit distance and other similarity metrics against the top N packages per ecosystem (available via ecosyste.ms) and flag close matches. Most hits would be false positives on legitimate packages, so the output should show the similar name and let the user decide. Useful as a one-time audit on unfamiliar repos more than as a recurring check.

Dependency confusion detection

For repos using both public and private registries, check whether private package names also exist on public registries.

git-pkgs already detects private registries via PURL repository_url qualifiers. A check could take each package resolved from a private registry and query the corresponding public registry (npmjs.org, pypi.org, etc.) for a package with the same name. If one exists, that's a potential confusion vector worth flagging.

Scoped packages (@company/foo) are generally safe on npm since attackers can't register under your scope. The check should account for that.

Install script detection

Flag dependencies that execute code during installation.

npm packages can declare preinstall, postinstall, and other lifecycle scripts in package.json. Python packages with setup.py run arbitrary code on install. Ruby gems with extconf.rb compile native extensions.

The manifests module already parses package.json and setup.py. For npm, checking for lifecycle scripts in the parsed manifest is straightforward. For packages not yet installed, the registries module could fetch the manifest from the registry and check there.

Output: list of dependencies with install scripts, what kind of script, and which lifecycle hook. Lets you review before running npm install or pip install on an unfamiliar repo.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp wantedExtra attention is needed

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions