Skip to main content

​
What a Policy Does

Setting Policies A policy turns a judgement you keep repeating into a rule that applies itself. Each policy shows what it does, and what it’s catching right now.

​
Three Possible Actions

Start with Warn. Introducing a new rule as Warn shows you the true blast radius without stopping anyone’s merge. Promote it to Block once the backlog it surfaces is dealt with.

​
Writing a Policy

Select + New Policy. Start from a template, or build from scratch. The built-in set covers the rules most teams want first, such as banned licences and known-exploited vulnerabilities. You then have two ways to express the rule, and they stay in sync:
  • Sentence — build the condition by picking fields, operators, and values. No syntax to learn.
  • Code — write the expression directly, with autocomplete and live validation, for conditions the builder can’t express.
Choose the action, save, and the policy is live on the next evaluation.

​
Rules About Cryptography

With Cryptography enabled, the same builder gains a Crypto field group, and six starter templates are available under Crypto: The Crypto group also exposes the finding’s Purpose (confidentiality, excluded, support, or unknown) and three evidence-only EAR signals, each met, not_met, or unknown:
These signals support your export review; they are not an ECCN or a classification decision. Use has() when a field may be absent, an absent field means the producer supplied no value, unknown means the producer supplied the field but couldn’t resolve its evidence.
Two of these read more precisely than they look. Reachability has three values, not two, a rule writes them reachable, unreachable, and unknown, which the finding itself shows as Reachable, Not Reached, and Unknown, so a rule that should only fire on proven usage must say reachable; asking for “not unreachable” also catches everything the analysis couldn’t decide. Key size exists only where Earnie resolved an actual key length; where it couldn’t, the field is absent and a key-size rule passes over the finding rather than guessing. The same holds for the algorithm family: a rule can only name a family Earnie assesses, and cryptography it has never assessed is treated as not quantum-safe rather than quietly waved through.
Without Cryptography enabled, none of this appears, no field group, no templates, nothing to discover. The policy page looks exactly as it does today.

​
Where a Policy Applies

A policy belongs to your organisation rather than to a single project, so the same rule can be attached to several projects at once. Open a policy and its Where This Applies panel names every project it’s currently attached to, and the repository connected to each one, so “which repositories does this cover?” has a direct answer.
A project with no repository connected yet is marked as covering nothing.
Because the rule is shared, editing it changes the gate for every project on that list. When a policy is attached to more than one, Earnie asks you to confirm before saving and shows you exactly which projects the change reaches. A policy attached to a single project saves without the extra step.

​
Cloning a Policy

To start a new rule from an existing one instead of a blank template, open a policy and choose Clone Policy from its More Actions menu. The copy is entirely independent, it starts with the same rule and settings, but from then on the two are edited separately, so changing one never affects the other, including their parameter values. The clone is named after the source with “(copy)” appended, gets its own identifier, and is attached to the project you cloned it from so you can find and tune it immediately.
A copy of a built-in template becomes a regular custom policy, so it’s yours to edit freely.

​
What’s Next

With a policy live, the next step is seeing what happens on the other side of it, when the gate actually blocks a merge.