Built-in policy templates
Reference for all five built-in Dependency Firewall policy templates, including detection methodology, configuration, and recommended usage.
Harness provides five built-in policy templates in the Policy Library for Dependency Firewall. Each template targets a specific supply-chain risk category and is ready to use out of the box. You can also customize any template or write your own policies from scratch using Rego.
All templates use the Upstream Proxy entity type and are evaluated automatically every time an artifact is fetched through an upstream proxy registry with Dependency Firewall enabled.
CVSS Threshold
Evaluates artifacts against Common Vulnerability Scoring System (CVSS) scores from known CVE databases.
What it detects: Packages with vulnerabilities that exceed your configured severity threshold. CVSS scores range from 0.0 (no risk) to 10.0 (critical), and you set the threshold at which the policy fails.
When to use: Block or warn on packages with known vulnerabilities above your organization's risk tolerance. Most teams set this between 7.0 (high severity) and 9.0 (critical only).
How it works:
At pull time, Dependency Firewall checks the artifact against CVE databases for known vulnerabilities.
Each vulnerability has a CVSS base score. If any vulnerability on the artifact exceeds your configured threshold, the policy fails.
The Vulnerabilities tab in the Evaluation Details sidebar shows the full breakdown by severity (Critical, High, Medium, Low).
Recommended configuration:
Strict security posture
7.0
Error and exit
Balanced — block critical (9.0)
9.0
Error and exit
Balanced — warn on high (7.0)
7.0
Warn & continue
Visibility only
4.0
Warn & continue
License Policy
Checks artifact licenses against your organization's approved or blocked license list.
What it detects: Packages whose detected license is not in your allowed list, or is explicitly in your blocked list. This prevents non-compliant open-source licenses from entering your supply chain.
When to use: Enforce license compliance requirements. Common scenarios include blocking copyleft licenses (GPL, AGPL) in proprietary software projects, or restricting to a pre-approved set of permissive licenses (MIT, Apache-2.0, BSD).
How it works:
At pull time, Dependency Firewall reads the license metadata from the package.
The policy compares the detected license against your configured allowed or blocked list.
If the license is blocked or not in the allowed list (when an allowed list is provided), the policy fails.
Recommended configuration:
Strict compliance
Allowed list only (MIT, Apache-2.0, BSD)
Error and exit
Block known problematic licenses
Blocked list (GPL-3.0, AGPL-3.0)
Error and exit
Audit mode
Blocked list
Warn & continue
Package Age
Evaluates artifacts based on their release date to enforce a cooldown period on newly published versions.
What it detects: Package versions whose release date is more recent than your configured age threshold (in days). This helps prevent the use of untested versions that may contain undiscovered security issues.
When to use: Enforce a "quarantine window" for new releases. Newly published packages are more likely to contain undiscovered bugs or supply-chain attacks. A cooldown period gives the community time to identify issues before the package enters your supply chain.
How it works:
At pull time, Dependency Firewall checks the version's release date against the current date.
If the version was released fewer days ago than your configured threshold, the policy fails.
This is especially useful for transitive dependencies that update frequently.
Recommended configuration:
High-security environments
30 days
Error and exit
Moderate cooldown
7 days
Warn & continue
Audit newly released packages
3 days
Warn & continue
OSS Risk Level
Evaluates artifacts based on their open-source risk score, which aggregates multiple supply-chain health signals into a single composite value.
What it detects: Packages that exceed a configured risk threshold based on overall project health. The risk score (0 to 100, where higher scores indicate greater risk) is derived from four weighted dimensions:
Risk
30%
Supply-chain risk signals (malicious flags, end-of-life, unmaintained)
Vulnerability
40%
Known CVE count and severity distribution
License
20%
License compliance and restrictiveness
Quality
10%
Maintenance activity, release cadence, community health
When to use: Catch packages that may not have critical CVEs today but show signs of being risky dependencies: unmaintained projects, end-of-life packages, or projects with poor security hygiene. The composite score surfaces risk that individual policy templates (CVSS, License) might miss in isolation.
How it works:
At pull time, Dependency Firewall evaluates the artifact's risk score from the threat intelligence database.
The OSS Risks section in the Evaluation Details sidebar shows the score breakdown and key findings, including:
End of Life: The project has been officially deprecated or archived.
Unmaintained: No commits or releases in an extended period.
Outdated: The version being used is significantly behind the latest release.
Malicious: The package has been flagged in threat intelligence (also caught by the Malicious Package template).
Unpatched critical CVE: A critical vulnerability exists with no available fix.
If the risk score exceeds your configured threshold, the policy fails.
Cap rules: When critical signals are detected (malicious component, unpatched critical CVE, or end-of-life status), the score is automatically clamped to the maximum (100) regardless of the weighted calculation. This ensures that packages with severe risk indicators always exceed standard thresholds.
Recommended configuration:
Block high-risk dependencies
70
Error and exit
Warn on moderate risk
50
Warn & continue
Strict supply-chain hygiene
40
Error and exit
Malicious Package
Detects packages that have been intentionally designed to attack your software supply chain, powered by a proprietary threat intelligence database that is automatically refreshed every 4 hours.
What it detects: Packages flagged as intentionally harmful. This is fundamentally different from vulnerability detection (CVSS Threshold), which targets accidental flaws. Malicious packages are purpose-built attacks.
When to use: Always. This template should be active on every upstream proxy with Dependency Firewall enabled. There is no valid use case for allowing a known malicious package into your supply chain.
How it works:
At pull time, Dependency Firewall evaluates the artifact against the threat intelligence database.
If the package version is flagged as malicious, the policy fails immediately.
Once classified as malicious, that classification is permanent. Unlike CVEs that can be patched in a newer version, a malicious package version was intentionally harmful and remains flagged indefinitely.
Detection coverage
The threat intelligence database covers the following supply-chain attack categories:
History: Packages with a prior malicious advisory, security yanks, or repeat offenders (recidivism).
Integrity: Artifact source mismatches, obfuscated source code, install-time network calls, and suspicious install scripts.
Takeover: Account takeover signals such as expired maintainer domains, new maintainer publishing immediately after ownership change, release anomalies, and disabled two-factor authentication.
Confusion: Dependency confusion attacks (private package name collision with a public namespace) and scope collisions.
Typosquatting: Packages mimicking popular dependency names to trick developers into installing malicious code.
Malicious packages vs vulnerabilities
Nature of threat
Accidental flaw in legitimate code
Intentionally harmful package
Detection basis
CVE databases and CVSS scores
Threat intelligence feeds and behavioral signals
Resolution
Patch available in a newer version
No fix; the package itself is the attack
Classification
Can change as patches are released
Permanent once flagged
Example
A library with a known buffer overflow (CVE assigned)
A typosquatted package publishing a backdoor
Recommended configuration:
All environments
Error and exit
Combine templates in a policy set
You can add multiple templates to a single policy set and assign a different fail action to each. This lets you layer enforcement levels within one evaluation pass.
A common pattern for production environments:
Malicious Package
Error and exit
Zero tolerance for known attacks
CVSS Threshold (9.0)
Error and exit
Block critical vulnerabilities
CVSS Threshold (7.0)
Warn & continue
Visibility into high-severity issues
License Policy
Error and exit
Compliance requirement
OSS Risk Level (70)
Warn & continue
Awareness of risky dependencies
Package Age (7 days)
Warn & continue
Flag very new releases
Go to Configure Policies and Policy Sets to create a policy set using these templates.
Custom policies
If the built-in templates do not cover your use case, you can write custom Rego policies. Ensure custom policies use the Upstream Proxy entity type and maintain the expected output structure so Dependency Firewall can properly evaluate and categorize violations.
Go to Configure Policies and Policy Sets for the full policy creation workflow. For Rego language fundamentals, go to the OPA Policy Authoring course.
Troubleshooting
Last updated
Was this helpful?