Security

Code Studio runs code your people write. These are the controls around it, each enforced in the application’s source and held by its tests.

The script sandbox

A script runs in QuickJS compiled to WebAssembly, a fresh runtime per run. It reaches nothing but the functions it is handed, and values cross as JSON.
Memory, stack and run time are capped, and a deadline or a stop request interrupts it.
Clock and randomness come from the host, so a continuation replays them exactly.
A WebAssembly module has no imports beyond AssemblyScript’s own two and a tick counter, gets copies of its arguments, and cannot make a request, read storage or see a secret. The server validates it on save and compiles it again from source when an administrator publishes it.
A script cannot reach Code Studio’s own dynamic form registrations in Jira, in either mode.

The sandbox mode holds by construction

No engine reaches the network except through the host, and in the sandbox the host records every write and answers it with a simulated response. An unknown write is recorded as unknown, never sent.

Who may do what

Every server entry point checks the licence first, then the caller’s role, asked of the required product on every call. The one exception is the weekly personal data report.
Nothing a browser, a rule or an HTTP request sends is a decision. Mode, principal, the script a listener or rule runs, and a connection’s base URL are all read from stored configuration.
Production runs published revisions, which only administrators publish.
Spaces limit who sees and edits scripts, decided on the server for every call and every Rovo action.
A Rovo action takes its caller from Atlassian’s context and refuses unless the product, asked as that person, names the same account.

Credentials

A connection’s credential is added after the script built the request. No credential reaches a browser: every record goes to the console through a function that names its fields.
Code Studio takes no Atlassian account’s API token or password. Another Atlassian site is reached with a service account and Bitbucket with an access token, and the server refuses basic sign-in to an Atlassian host on every path that saves a connection, imports included.
A secret variable reaches the script and is blanked out of every log line, result, error and listed change.
An export carries secrets only inside an AES-256-GCM envelope keyed with scrypt from a passphrase.

Entry points without a user

API triggers: every field of the request is treated as an attacker’s. The secret travels in the Authorization header and is compared with its stored SHA-256 in constant time. An unknown trigger and a wrong secret get the same answer.
Repository webhooks: believed only with a valid HMAC-SHA256 signature over the exact body, compared in constant time.

Logs

Nothing in a Forge log, which Atlassian shares with Oktul, names a customer or their content: no account id, key, page id, script name or code, output, URL, token or error object. A test holds every logging call to literal text. A script’s output goes to its run’s own log in your site.

Egress

Five hosts are declared; every other host is approved by your administrator in Atlassian’s own dialog. There is no wildcard in the manifest. See connections and variables.

Reviews and reports

The whole application was reviewed against these rules on 16.10.2026, and the findings were fixed. Oktul holds no audited security certification. Report a vulnerability through the Oktul Help Center (opens in a new tab) or to support@oktul.com.

A problem or a question? Write to support@oktul.com or open a request in the Help Center (opens in a new tab). Both open a request with a reference and an SLA.