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.

Why a sandbox run sends no write

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 has 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.

On 31.10.2026 we attacked a staging installation on our test site from outside and as four accounts: a site administrator, a developer, a Jira user with no Code Studio role and a portal customer. The web trigger took 106 crafted requests and an OWASP ZAP API scan of 121 rules, and refused all of them that carried no valid secret or signature. The test found six faults, and we fixed them the same day. Four were medium or low: a script could exhaust the function’s memory, a busy loop could not be stopped, an editable select took a value it never offered, and a connection’s credential followed a redirect. In the fifth, a field’s script list answered anyone signed in. The sixth ended a run on deeply nested values. The same week, Semgrep’s rule packs over the whole code gave 55 findings. We fixed one (the export envelope did not pin its tag length) and recorded the other 54 as not vulnerabilities, with the reason for each.

Since 01.11.2026 we also scan the code before each release and on the 1st of every month, as clause 5.6 of the data processing addendum sets out, and attack the web trigger again in a separate Forge environment, never on your site. The first of those scheduled attacks has not run yet. The penetration test suite holds 172 cases for the 424 entry points in the code, and first ran in full on 03.11.2026. We run it by hand before a first release, then every six months and whenever an entry point is new or changed, and its automated checks run with every scan. Before each release we also review Code Studio’s software bill of materials (SBOM): every package added, upgraded or removed since the last review, and every licence that needs reading. Oktul holds no audited security certification. Code Studio is listed in the CSA STAR Registry at Level 1, and its completed CAIQ Lite questionnaire is on the security assessment page. 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).