How Cardinal Ruler is built and operated

Where the app runs, and what protects it

Cardinal Ruler is a Forge app. It has no servers to harden, no database to patch and no network perimeter of its own, because it runs inside Atlassian's platform alongside the Jira site it is installed on.

Data sits in two places, both Atlassian: Forge app storage, and the Bitbucket Cloud repository your organisation nominates and owns. Atlassian encrypts both at rest. Traffic to the repository is over HTTPS.

The app contacts one external address, api.bitbucket.org. That restriction is declared in the app manifest and enforced by the Forge platform rather than by convention, and there is no wildcard in it.

Permissions

Six Jira permissions are requested, each one because a specific endpoint requires it, and each carrying a note in the manifest naming that endpoint. The app reads workflows, screens, fields and schemes on the site a change is captured from, and writes them to the site a change is deployed to. Every permission is listed with its justification on the app data handling page.

Jira calls run with the app's own identity, so every action that depends on a person's rights checks those rights first: site-administration actions query that account's Administer Jira permission through Jira's own permissions API, and deploy, approval and authoring actions check the user against the roles recorded in your node registry.

The one credential, and how it is held

• The only secret the app holds is the Bitbucket repository access token your administrator supplies.
• It is written to Forge's encrypted secret storage, kept out of the connection record so it cannot surface in a log of that record, and never returned to a browser. It can be replaced, never read back.
• It belongs to the repository rather than to a person, so it survives staff changes and ties your audit trail to no one's account.
• It reaches one workspace and one repository, and grants no access to any Atlassian product API. Revoking it in Bitbucket ends the app's access immediately, without touching the history already committed.

What the logs can contain

Atlassian shares an app's console log lines with the partner that publishes it, so what those lines may contain is a design constraint rather than a promise. Cardinal Ruler builds them from a fixed set of fields with no free-text member: the operation, an error kind, an HTTP status, retry and timing metadata, and the change and step identifiers.

They therefore carry no account identifiers, no email addresses, no configuration names, no field values, no repository or workspace names, and nothing typed into the app. Separately, anything written into your repository passes a redaction step that replaces credential-shaped field names, scrubs known secret patterns, and drops everything that is not a simple value.

How vulnerabilities are found and fixed

• Every change goes through a pull request. Continuous integration runs on every push: type checking, linting, the full unit test suite, and a dependency audit that fails the build on any finding in either the runtime or the development dependency tree.
• Dependencies are kept current rather than audited once. The audit gate means a newly published advisory against any dependency blocks the next merge until it is dealt with.
• Reporting. Report a suspected vulnerability in Cardinal Ruler to the address shown here when JavaScript is enabled, marking it as a security report, or through the contact form. Reports are acknowledged and triaged on receipt.
• Fix times follow Atlassian's Marketplace security bug fix policy: ten days for a critical issue, four weeks for a high, twelve weeks for a medium.

If something goes wrong

Where an incident affects the app, Atlassian is notified within 24 hours and kept updated through remediation, and affected customers are notified within 72 hours of identification. VMotion IT Solutions Ltd also meets its own statutory breach-notification duties, which for an Irish company means the Data Protection Commission.

The audit record is unaffected by any of this: it lives in your repository, under your organisation's control, and an uninstall leaves it exactly as it stands.

Certifications

VMotion IT Solutions Limited holds:

• ISO/IEC 27001:2022, the information security management standard, with recurring external surveillance audits.
• Cyber Essentials.
• FSQS, the Financial Services Qualification System operated by Hellios, used by banks and insurers to assess their suppliers.

All three are held by the Irish entity and are externally assessed rather than self-declared. For current certificates, or any documentation your procurement process needs, use the contact form.

Changes to this page

This page describes the application and the practices around it as they stand on the date above, and every statement on it was taken from the shipped source or from a current certificate rather than from a plan. It is revised whenever those change.