DependencyPolicy
Defined in: policy.ts:67
Team dependency policy — schema from the workshop proposal (§9 phase 6).
Properties
Section titled “Properties”| 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:80 |
blockForAdvisorySeverity? |
AdvisorySeverity |
- | policy.ts:123 |
blockMissingRepositoryForRuntimeDeps? |
boolean |
- | policy.ts:72 |
blockPackages? |
string[] |
- | policy.ts:81 |
blockRecentlyPublishedPackages? |
boolean |
- | policy.ts:68 |
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:113 |
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:106 |
minPackageAgeDays? |
number |
- | policy.ts:69 |
requireApprovalForAdvisorySeverity? |
AdvisorySeverity |
Gate a package that carries a known-vulnerability advisory (OSV) by severity. A package whose worst advisory is at or above the level requires approval / is blocked. unknown-severity advisories never trigger a threshold (no gradable level), but are still scored and surfaced. Off by default — advisories otherwise stay allow_with_warnings (see the vulnerability-scoring design). If both are set and both match, block wins. |
policy.ts:122 |
requireApprovalForLifecycleScripts? |
boolean |
- | policy.ts:71 |
requireApprovalForNativeCode? |
boolean |
- | policy.ts:70 |
requirePublicMirrorVerification? |
boolean |
Fail closed when an npm mirror cannot be compared with its upstream registry. | policy.ts:89 |
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:87 |
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:98 |