Recommended Guardrails

Overview

Recommended guardrails serve as a baseline for strengthening software hygiene and reducing risk across development teams. They represent a curated set of high-impact checks informed by common security patterns observed across modern software supply chains. By adopting these recommendations, organizations can establish foundational safeguards that prevent recurring issues such as dependency drift, outdated libraries, or the introduction of vulnerable components.

Each recommended guardrail is designed to guide developers toward secure, maintainable, and compliant dependency choices—without introducing unnecessary friction. These recommendations can be customized or expanded upon to fit your organization's environments.

We recommend creating any new guardrail with the Observe action so you can evaluate how well the guardrail is followed before converting the guardrail to a Warn or Block action.

Compromised Dependencies

The Compromised Dependency rule helps ensure that known compromised dependencies do not enter the codebase. This rule leverages the OSSF Malicious Packages feed to identify known open source packages that have been compromised.

Recommended Usage: Set a global rule to block the introduction of compromised or malicious packages.

Minimum Dependency Age

The Dependency Version Minimum Age rule enforces dependencies to meet a minimum age threshold. Most supply chain attacks are detected within the first 24 hours of a malicious package release, and the projects that get compromised are often the ones that rushed to adopt the version immediately. By enforcing a minimum age, you can prevent newly compromised dependencies (zero day compromises) that may not have been detected. Together with Heeler's compromised dependency guardrail you have coverage against both known and unknown compromised dependencies.

Recommended Usage: Set a global rule with a minimum age of 2 days to prevent introduction of zero day like compromised dependencies.

Dependency with Known Active Exploit

The Active Exploit rule can be used to prevent introduction of dependencies with vulnerabilities that have confirmed active exploits in the wild. You many choose to incorporate additional scoping logic that includes Vulnerabilitie - Fix Versions Available rule to only trigger when a remediated version is available.

Recommended Usage: Create a guardrail to block introduction of any dependency with vulnerabilities that have confirmed exploitation.

Risky & Unmaintained Dependency

Identifying EOL dependencies isn’t always straightforward. Maintainers don’t always clearly declare EOL status, and many open source projects fade into inactivity without a formal announcement. With Heeler you can use the OSSF Unmaintained Dependency check along with having vulnerabilities with no fix available to determine unmaintained dependencies with unfixed risk.

Breakdown of the OSSF Unmaintained Dependency Values:

Score

Meaning

0

No activity at all (no commits, PRs, or issues in 90+ days)

3

Some activity, but only from external users

5

Issue/PR activity from collaborators, members, or owners

10

Frequent commits, active issue responses, and recent releases

Recommended Usage: Create a guardrail to warn when unmaintained dependencies with unfixed vulnerabilities are introduced.

Unapproved License

As AI-generated code becomes more common, managing open source licenses has grown both more complex and more critical. Heeler guardrails can used to automatically block or warn risky license usage.

Administrators can customize the License Policy to align with your organization’s legal or compliance requirements. This policy powers Heeler’s detection and enforcement capabilities, including the Unapproved License guardrail.

Recommended Usage: Create a guardrail to warn when a dependency is introduced that violates the organization's license policy.

Last updated

Was this helpful?