JFrog AppTrust allows you to define custom logic for your lifecycle policies using Rego, the declarative language utilized by Open Policy Agent (OPA). Once created, these templates serve as the foundation for policy rules that AppTrust evaluates against OneModel evidence at runtime.

This guide explains how to construct valid templates, follow the required execution contract, and navigate the OneModel schema.

When to use a Custom Template

Standard built-in templates cover many common scenarios, but you should create a custom template when your rule logic requires:

Cross-entity evidence checks involving application versions, builds, and artifacts.
Complex parameter combinations or specific predicate types not available in standard rules.

Rego Basics

While OPA expertise is not strictly required, you should be familiar with basic Rego syntax (see the OPA policy language reference). JFrog-specific implementation requirements are detailed below. To help you work more efficiently, AppTrust’s Rego Playground provides an AI agent that enables you to enter natural language specifications and generates the Rego code you need.

Template Structure

To ensure successful compilation and execution by the policy engine, every template must adhere to specific guidelines regarding its package structure and return values.

Package and Imports

Templates must reside within the curation.policies package and should import rego.v1 for modern syntax support:

package curation.policies

import rego.v1

Entry Rule: 'allow'

The evaluation engine specifically looks for the allow rule. This rule must return an object containing the results of the policy check.

Result Object

The result map returned by the allow rule must include the following fields:

Field	Type	Required	Description
'should_allow'	boolean	Yes	Set to true if the check passes, or false to trigger a deny action.
'explanation'	string	No	A human-readable string explaining why the policy failed.
'violated_findings'	array of strings	No	A list of identifiers for the specific entities that caused the violation.

Minimal Valid Example:

package curation.policies
import rego.v1

allow := {
    "should_allow": true,
}

Rego Size

Individual template files must contain between 1 and 65,536 characters. (This limit
is enforced when saving the template, not in the editor.)

OneModel Schema Shape

When using the onemodel_evidence source, your Rego runs against a federated graph structure. The platform automatically normalizes this data before evaluation.

Evaluation typically starts with the application version. Most templates begin by capturing this input:

app_version := input.data.applications.getApplicationVersion

Evidence predicates are collected from three layers, then merged:

Layer	Rego pattern (summary)
Application version	Predicates on 'app_version.evidenceSubject.evidenceConnection'
Sources	Predicates on each 'app_version.sources[_].evidenceSubject.evidenceConnection'
Releasable artifacts	Predicates on artifacts under 'app_version.releasables.releasablesConnection'

Template Parameters

Templates can declare up to 20 parameters. Each parameter has a name and type ('string', 'int', 'bool', 'float', or 'object'). When you create a rule from the template, you will be required to supply parameter values. Parameter names must be unique within a template. (These limits are enforced when the template is saved.)

Execution limits

To maintain platform performance, the following constrains apply:

Validation: Invalid Rego or restricted built-ins will cause the template to be rejected upon saving.
Timeouts: Policies must execute within a set time limit. Avoid unbounded iteration and filter data as early as possible.
No Recursion: Recursive rule definitions are generally prohibited. Use set comprehensions or bounded loops instead.

What’s Next?

Learn about the Rego Playground for creating and editing Rego code in AppTrust.

Custom Templates