Skip to main content
A policy is a rule that tells Earnie what to do when a scan finds something. For example, a policy can block any change that introduces a banned licence, or warn when a component is out of date. Earnie uses policies to decide whether a change can merge. Each time Earnie scans a project, it checks the findings against the policies attached to that project. The result is the verdict, and the verdict decides the merge gate. This page explains how to create a policy, choose its action, and control which projects it applies to. Before you start:
  • The project needs at least one completed scan, so the policy has findings to evaluate. See Your first scan.
  • You need the Operator or Admin role to create and edit policies. See Team & roles.

​
What a policy does

Setting Policies A policy records a decision you would otherwise make by hand on every scan. For example, if you always reject components under a particular licence, a policy rejects them for you each time a scan finds one. Each policy shows its rule and the findings it matches right now. You manage policies from Policies in a project’s sidebar. Policies belong to your organisation, and the page lists the ones attached to the current project. See Where a policy applies.

​
Three possible actions

Every policy has one action. The action decides what happens when a finding matches the rule:
Start with Warn. A new rule set to Warn shows you how many findings it affects without stopping anyone’s merge. Change it to Block once you’ve dealt with the backlog of findings it reports.
A policy gates a run only when the run used the scanner the policy reads. If a policy reads only a scanner the run didn’t select, Earnie marks it not applicable for that run. For example, an OSS-only scan doesn’t answer an AI vendor policy, so that policy neither passes nor fails the run. When every policy in force is not applicable, the gate reads No policy applied. If a scanner the run did select fails or isn’t available, the gate reads Gate could not be evaluated. Missing evidence never counts as a pass.

​
Writing a policy

You can start from Earnie’s built-in templates, or write your own rule from scratch.

​
Starting from templates

Templates are ready-made policies for the rules most teams set up first.
  1. On the project’s Policies page, select New policy. If the project has no policies yet, select Pick templates instead.
  2. The picker lists every built-in template in a sortable table, with its category and action. Select Details on a template to read more about it.
  3. Tick the templates you want, then select Use n templates (for example Use 3 templates) to create them all at once.
Policies created from templates start as drafts and affect no merge until you turn them on. Open each policy and switch it to Enabled when you want Earnie to enforce it. The exception is templates you turned on in the setup wizard. Those are enabled straight away. The built-in templates are:

​
Starting from scratch

Select Start from scratch to write a rule yourself. You then give the policy a name and choose what it evaluates. See What a policy evaluates.

​
Building the rule

Under The rule, you can write the condition in two ways. Earnie keeps them in sync, so a change in one shows up in the other.
  • In Sentence, you build the condition by picking fields, operators, and values, with no syntax to learn. If you wrote a condition in CEL with an operator or value the builder doesn’t offer for that field, the builder still shows it as written, listed beside the options it offers.
  • In CEL, you write the condition as an expression in CEL (Common Expression Language), with autocomplete and live validation. Use it for conditions the Sentence builder can’t express.
Choose the action from the then dropdown, then select Save policy. A policy you write in the editor starts enabled, and the Enable on save switch beside Save policy shows this. The policy applies from the next evaluation. Switch it off to save the policy as a draft, which changes no verdict until you enable it. When you edit an existing policy, the same switch reads Enabled or Disabled to show its current state.

​
Parameter checks on save

When you save, Earnie checks every parameter value against the parameter it belongs to:
  • a number parameter must hold a number, and a whole-number parameter must hold a whole number
  • a choice must be one of its listed options
  • a list must hold only text
  • Earnie refuses a value for a parameter the policy doesn’t declare
Every parameter needs a value or a default. A parameter you leave empty takes its default. If it has no default either, Earnie refuses the save and asks you to add a value. When Earnie refuses a save, the editor names the parameter and the kind of value it needs. Policies saved before this check existed keep their values until you next change their values or parameters. Earnie checks a copy made with Clone policy when it creates the copy.

​
What a policy evaluates

Every policy evaluates one kind of finding. When you create a policy, you choose this under Evaluates, next to Category:
  • OSS findings are findings from open-source scanning.
  • Crypto findings are findings from cryptography scanning. Earnie offers this option only if your organisation has Cryptography enabled.
  • AI findings are findings from AI provenance scanning, covering both identified models and AI usage. Earnie offers this option only if your workspace has AI governance enabled. See AI provenance for the field group and the seven starter templates.
A policy created from a template already has the template’s choice set. You can’t change the Evaluates choice after you save the policy. It decides which fields the rule can read, so changing it would break the rule. The policy’s Where this applies panel repeats the choice, for example “Evaluates Crypto findings”.
Some fields must be checked before they’re read. Not every finding has every field. For example, a key size exists only where Earnie resolved an actual key length. A rule that asks whether a key is under 2048 bits has to limit itself to findings where the key length is known.The Sentence builder writes that check for you. In CEL, you write it with has(). The editor refuses to save a rule that reads such a field without the check, and names the field and the check to add, for example: field "finding.crypto.key_size" is optional — guard with has(finding.crypto.key_size).

​
Rules about cryptography

With Cryptography enabled, the rule builder gains a Crypto field group, and seven cryptography templates become available: EAR, the US Export Administration Regulations, is the set of export-control rules these export fields and templates refer to.

​
Crypto fields for export control

The Crypto group includes the finding’s purpose and three export-control signals. These fields are evidence only. Each export signal has one of four values: met, not_met, unknown, or not_evaluated.
When a Sentence rule uses one of these fields, the builder shows a fixed disclaimer: “Export-control evidence supports your self-classification. It is not legal advice and does not determine or imply an ECCN.”The values mean different things, so write rules with care:
  • An absent field means the producer supplied no value. Use has() when a field may be absent.
  • unknown means the producer supplied an applicable test but couldn’t resolve it.
  • not_evaluated means the test had no applicable occurrence evidence.

​
Fields that read more precisely than they look

  • Route Evidence (finding.crypto.route_evidence) is the weakest call on the strongest path to the finding. The value is direct when Earnie resolved every call statically, dispatch when the path needs an interface or runtime dispatch call (the finding stays reachable), and name_only when every path needs a call matched by method name alone, so reachability is unknown.
  • No Known Callers (finding.crypto.no_callers_only) is true when every path starts in application code that nothing in the application calls, instead of at a main or a recognised framework entry point. To match “reachable from a known caller”, write has(finding.crypto.no_callers_only) && !finding.crypto.no_callers_only.
  • Dependency Relationship (finding.crypto.dependency_relationship) is direct when your project declares the library a dependency finding sits in, and transitive when the library arrives through another dependency. To match “cryptography in a transitive dependency”, write has(finding.crypto.dependency_relationship) && finding.crypto.dependency_relationship == "transitive". These three fields are absent when the scan traced no path to the finding, and on scans from crypto-finder releases that don’t report them. Dependency Relationship is also absent on findings in your own code. Guard all three with has().
  • Reachability has three values, not two. A rule writes them as reachable, unreachable, and unknown, and the finding shows them as Reachable, Not reached, and Unknown. A rule that should fire only on proven usage must say reachable. A rule that asks for “not unreachable” also matches every finding the analysis couldn’t decide.
  • Key Size (bits) exists only where Earnie resolved an actual key length. Where it couldn’t, the field is absent, and a key-size rule skips the finding instead of guessing.
  • Elliptic Curve (crypto.elliptic_curve) names the curve an algorithm or a piece of key material uses, for example secg/secp256k1, when Earnie resolved one. It’s free text, not a fixed list, because CycloneDX’s own curve vocabulary has hundreds of entries.
  • Risk Assessed records whether Earnie’s curated tables decided this finding’s severity. When it’s false, the severity is a placeholder, not a judgement, and reachability doesn’t raise it. This is why an unassessed finding never escalates to a blocking severity.
Post-Quantum Status has four values, and you need to tell them apart:
Use Post-Quantum Status, not Quantum Safe. The older Quantum Safe yes/no field still works but is deprecated, because a yes/no value can’t separate “we checked, it’s fine” from “we haven’t looked”. On an unassessed asset the yes/no field is absent, not false. A rule on it must therefore say “Quantum Safe is set and is false”. A rule that only says “Quantum Safe is false” errors on the findings it can’t answer for. Write new rules against the four-value field instead.
The field picker’s Crypto group links to Settings → Crypto Assessment, which lists every algorithm family and verdict a cryptography rule can match on. Check it when you decide which family to name in a rule. The link opens in a new tab, so you don’t lose an unsaved policy draft.
Without Cryptography enabled, Earnie hides the Crypto field group, the cryptography templates, and the regulatory template sets.

​
Regulatory template sets

Some regulations and standards require specific cryptography controls. A regulatory template set selects every template mapped to one clause of a standard in a single action, so you don’t have to find them one by one. The sets appear as Quick start cards on a project with no policies yet, and under Start from a framework in the template picker. Each card shows the clause it maps to.
Neither template set blocks reachable TLS 1.3. Earnie doesn’t verify FIPS 140-3 module validation.

​
Where a policy applies

A policy belongs to your organisation, not to a single project, so you can attach the same rule to several projects. Open a policy to see its Where this applies panel. It names every project the policy is attached to and the repository connected to each one, so you can see which repositories the policy covers.
A policy governs a project’s applicable findings whether or not the project has a repository connected. Earnie covers an upload-only project the same way as one backed by a repository. The panel shows the two facts separately: what the policy governs, and whether the project has a repository connected.

​
Editing a shared policy

Because the rule is shared, editing it changes the gate for every project it’s attached to.
  • If the policy is attached to more than one project, Earnie asks you to confirm before saving and lists the projects the change affects.
  • If the policy is attached to one project, it saves without the confirmation.

​
Cloning a policy

Cloning starts a new rule from an existing one, so you don’t begin from a blank template.
  1. Open the policy you want to copy.
  2. Open the More actions menu and choose Clone policy.
  3. Confirm in the dialog.
The copy:
  • has the original’s name with “(copy)” added to the end
  • has its own identifier
  • is attached to the project you cloned it from, so you can find and adjust it straight away
  • is enabled or a draft, matching the original
The copy starts with the same rule and settings as the original, including parameter values. After that, you edit the two separately, and a change to one never affects the other.
A copy of a built-in template becomes a regular custom policy that you can edit.

​
What’s next

Once a policy is live, you can apply it to more projects. All projects shows every project’s standing on one page and can apply a policy to several projects in one action. Then read Merge gate to see what happens on a pull request when the gate blocks a merge.