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 can be changed at runtime via the REST API without restarting the engine. All engine nodes pick up the new configuration within 30 seconds.

Blocked Patterns

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

Configuration

Script Guard is 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

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 can be set statically in application.yml (see Configuration) or updated at runtime via the REST API. Runtime updates are stored in the ACT_GE_PROPERTY table and 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.

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.getRuleCode() + ": " + match.getReason());
  }
}

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.