Skip to content

DependencyPolicy

Defined in: policy.ts:62

Team dependency policy — schema from the workshop proposal (§9 phase 6).

Property Type Description Defined in
allowKnownPackages? string[] Pre-approved packages that clear heuristic soft blocks. Entries are either a bare name (react — any version) or version-qualified (react@18.2.0 — only that exact version), so a team can pin a reviewed version instead of blanket-trusting every future release of a name. Hard blocks are never cleared. See allowListMatch. policy.ts:75
blockMissingRepositoryForRuntimeDeps? boolean - policy.ts:67
blockPackages? string[] - policy.ts:76
blockRecentlyPublishedPackages? boolean - policy.ts:63
codeAudit? CodeAuditScope AI source-code audit scope (the opt-in --audit-code pass): “off” (default), “flagged” (only packages the deterministic pass flagged), “direct” (the project’s direct dependencies), or “all”. The --audit-code flag turns the audit on ad-hoc; this field lets a team enable/scope it centrally. policy.ts:108
internalScopes? string[] npm scopes (e.g. “@acme”) whose packages are internal: external lookups that would leak the package NAME to third parties (OSV, npm downloads, maintainer search) are skipped, and typosquat similarity is not applied. The report shows the skips — an internal package is never silently “clean”, it is visibly “not externally checked”. policy.ts:101
minPackageAgeDays? number - policy.ts:64
requireApprovalForLifecycleScripts? boolean - policy.ts:66
requireApprovalForNativeCode? boolean - policy.ts:65
requirePublicMirrorVerification? boolean Fail closed when an npm mirror cannot be compared with its upstream registry. policy.ts:84
requireSignedApprovals? boolean Only honor approvals whose SSH signature verifies against the committed .targate/allowed-signers file (see docs/team-workflow.md). Unsigned or unverifiable entries are ignored — the affected packages ask again. policy.ts:82
trustBehaviorFingerprint? boolean Reuse a prior approval of a DIFFERENT version of the same package when the new version’s behavior fingerprint matches the approved one (see the trust-friction design). Off by default — with it off, approvals stay strictly version-exact. A match can only clear a soft verdict; a hard block, an install-script change, a dangerous-capability escalation, a provenance downgrade, or an incomplete fingerprint all still re-prompt. policy.ts:93