Script Guard is an EximeeBPMS feature that inspects scripts before execution and blocks — or audits — patterns that could lead to remote code execution, data exfiltration, or other security incidents. It works at the engine level, independently of the scripting language in use.

Script Guard applies to all scripts executed by the process engine: Script Tasks, Execution Listeners, Task Listeners, Condition Expressions, and Input/Output Mappings, as well as scripts submitted dynamically via the REST API or Java API.

Enforcement Modes

Script Guard operates in three modes:

The mode is only ever read from static configuration once — the first time the engine starts against a database with no Script Guard configuration stored yet. From then on the database is authoritative, and the mode can only be changed at runtime via the REST API, without restarting the engine — see Configuration for exactly how that works. All engine nodes pick up a REST-driven change within 30 seconds.

Blocked Patterns

The built-in policy checks the script source (case-insensitively) against the following patterns:

Configuration

Script Guard’s enforcement mode and allowlist have two representations — keeping them straight matters:

• Static configuration — a Spring Boot property, or a bpm-platform.xml property on a plain-XML deployment — supplies only the initial value. It is read exactly once: the first time the engine starts against a database that has no Script Guard configuration stored yet (a fresh install, or an upgrade from a version that predates Script Guard).
• The database (ACT_GE_PROPERTY) holds the current, authoritative value from that point on. Every later engine start reads whatever is already stored there and ignores static configuration entirely. The only way to change the mode or allowlist afterward is the REST API — PUT /script-security/config — or a direct write to ACT_GE_PROPERTY.

This is deliberate: a production deployment is usually a fleet of engine nodes (multiple Tomcat/Spring Boot instances) sharing one database, and each node’s own application.yml/bpm-platform.xml is local to that node — nothing keeps those files identical or in sync across the fleet. Making the database authoritative after the first boot gives the whole fleet a single, consistent source of truth: a PUT updates one shared row, and every node picks it up on its own cache refresh within 30 seconds — no per-node file edits, no rolling restart, no risk of nodes disagreeing on the mode.

An unrecognized mode/scriptSecurityMode value (a typo, e.g. ENFORCEE) is not silently treated as ENFORCE — the engine fails to start, on either deployment model, with an error naming the invalid value and the three valid ones (ENFORCE, AUDIT, DISABLED; matching is case-insensitive). Fix the value and restart.

Spring Boot

Configured via Spring Boot application properties under the eximeebpms.bpm.script-security prefix:

eximeebpms:
  bpm:
    script-security:
      mode: ENFORCE
      allowlisted-process-definition-keys:
        - my-trusted-process
        - legacy-migration-process
      violation-store-size: 1000
      retention-days: 30

Tomcat / plain XML (bpm-platform.xml)

A deployment that doesn’t use the Spring Boot starter — the Tomcat distribution, or any other container driven by bpm-platform.xml — configures the same initial mode and allowlist as plain process-engine properties, no custom ProcessEnginePlugin required:

<property name="scriptSecurityMode">AUDIT</property>
<property name="scriptSecurityAllowlistedProcessDefinitionKeys">my-trusted-process,legacy-migration-process</property>
<property name="scriptViolationRetentionDays">30</property>

A Tomcat/plain-XML deployment persists violations to ACT_RU_SCRIPT_VIOLATION, forwards them to the business-event/SIEM outbox, and answers PUT /script-security/config exactly like a Spring Boot deployment — no custom ProcessEnginePlugin needed for any of it. violation-store-size remains a Spring Boot–only YAML property with no equivalent here.

Allowlisting Process Definitions

Processes that intentionally use constructs blocked by the policy can be placed on an allowlist. Scripts belonging to allowlisted processes skip all security checks.

The allowlist’s initial value can be set statically — in application.yml (Spring Boot) or bpm-platform.xml (Tomcat/plain XML) — see Configuration. From the first engine start onward it lives in the ACT_GE_PROPERTY table and can only be changed via the REST API; static configuration is not consulted again. Updates propagate to all engine nodes within 30 seconds.

Violation Monitoring

Whenever a script triggers a rule — in either ENFORCE or AUDIT mode — Script Guard records a violation event containing:

• Timestamp of the violation
• Process definition key and activity ID of the offending script
• Scripting language (e.g., groovy, javascript)
• Source type: INLINE_SOURCE, DYNAMIC_SOURCE, RESOURCE, DYNAMIC_RESOURCE, EXPRESSION, or UNKNOWN
• Script origin: USER, PROCESS_APPLICATION, or PLATFORM
• Rule code (e.g., SCRIPT_SECURITY_RUNTIME_EXEC) and a human-readable reason

Violations are persisted in the ACT_RU_SCRIPT_VIOLATION table and can be queried via the REST API. The in-memory ring buffer holds up to violation-store-size recent entries; the total count is always available independently.

REST API

The Script Guard REST API is available at:

• /engine-rest/script-security — for the default engine
• /engine-rest/engine/{name}/script-security — for a named engine

All endpoints require the ALL permission on the SYSTEM resource (i.e., the eximeebpms-admin role). Requests without this permission receive an HTTP 403 response.

Get Configuration

Returns the current Script Guard configuration — the database-backed value described in Configuration, not the static configuration file.

GET /script-security/config

Response (200 OK):

{
  "mode": "ENFORCE",
  "allowlistedKeys": ["my-trusted-process"]
}

Update Configuration

Updates the Script Guard configuration at runtime. Changes take effect on all engine nodes within 30 seconds without a restart.

PUT /script-security/config

Request body:

{
  "mode": "AUDIT",
  "allowlistedKeys": ["my-trusted-process", "legacy-migration-process"]
}

Response (200 OK): the updated configuration (same structure as Get Configuration).

List Violations

Returns recent Script Guard violations in descending timestamp order.

GET /script-security/violations

Query parameters:

Response (200 OK):

[
  {
    "timestamp": "2026-01-15T10:30:00.000Z",
    "processDefinitionKey": "payment-process",
    "activityId": "scriptTask_1",
    "language": "groovy",
    "sourceType": "INLINE_SOURCE",
    "origin": "PROCESS_APPLICATION",
    "ruleCode": "SCRIPT_SECURITY_RUNTIME_EXEC",
    "reason": "Access to Runtime.getRuntime() is forbidden"
  }
]

Get Violation Count

Returns the total number of violations recorded since the engine started.

GET /script-security/violations/count

Response (200 OK):

{
  "count": 42
}

External Validation Module

The same rule set Script Guard enforces inside the engine is also available as a standalone library, with no dependency on the process engine. Add it to a process-design tool, a CI pipeline, or any other pre-deployment tooling to check a script or expression before ever attempting to deploy the process definition that contains it — instead of only finding out from a rejected deployment.

Adding the Dependency

<dependency>
  <groupId>org.eximeebpms.commons</groupId>
  <artifactId>eximeebpms-commons-script-guard-rules</artifactId>
</dependency>

Usage

ScriptSecurityRuleSet ruleSet = DefaultScriptSecurityRuleSet.INSTANCE;
ScriptValidationResult result = ruleSet.validate(scriptSource, ScriptOrigin.USER);

if (!result.isClean()) {
  for (ScriptSecurityRuleMatch match : result.getMatches()) {
    System.out.println(match.ruleCode() + ": " + match.reason());
  }
}

Rule codes and reasons reported here are identical to the ones in Blocked Patterns and the ones recorded in Violation Monitoring — the engine and this module share one rule set, so the two can never disagree.

Recommended Rollout

1. Audit first — enable Script Guard with mode AUDIT. Existing processes continue to run but violations are recorded.
2. Review violations — use the REST API to identify which processes and patterns are flagged.
3. Allowlist trusted processes — for processes that intentionally use blocked patterns, add them to the allowlist via the REST API.
4. Enforce — switch mode to ENFORCE once all violations are resolved or allowlisted.