Third-party package dependencies · Sources & registries

Declare dependencies only from a registry

When it fails: Dependencies are pulled from direct URLs, source repositories or local paths. Code fetched from a URL or a repository branch bypasses registry controls and can change at any time without a new version.

CB-DEP-SRC-004mediumdraftpartialprofile baseline

Status draft: not part of any release yet, may still change.

Description

Production dependencies are declared as named, versioned packages from an approved registry. Direct archive URLs, source repository references and local paths are not used, except under a documented and reviewed exception.

If an exception is needed, reference an immutable identifier (a full commit hash, a checksum) and record the reason.

Rationale

Non-registry sources skip release-age rules, malicious package blocking and vulnerability matching. A branch or unversioned URL can point to different content between two builds.

Impact

Forks or unreleased fixes must be published to the private registry instead of referenced directly.

Audit

  1. Search manifests and lockfiles for dependencies whose source is a URL, a source repository or a path.
  2. Check that each one has a documented exception and an immutable reference.

Automated: every check must pass. Scanners report each check by its id.

postmortem

git / URL / out-of-repo path dependencies in manifests and lockfiles

command: postmortem harden --json
control: CB-DEP-SRC-004
coverage: auto

Remediation

  1. Publish the needed package to the private registry under a proper version.
  2. Replace the direct reference with the registry package.

References

Mappings

FrameworkIDRelationNote
NIST SP 800-53 Rev. 55.1.1SR-3related

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Threats mitigated

People and lifecycle

AuthorsAlice
Introduced inv1.0.0
Created, updated2026-10-16, 2026-10-16