Rule Kit for Jira Workflows — Security Policy

Last updated: 4 November 2026

This page covers Rule Kit for Jira Workflows (“the app”), a Jira Cloud app built on Atlassian Forge by MSC Labs. What data the app reads and logs is described in its privacy policy; this page says how we keep it secure.

In short

• The app runs only on Atlassian's platform and is eligible for Atlassian's “Runs on Atlassian” programme: no servers, storage or network requests of our own.
• We cannot see your work items. The only app data we can see is its Forge logs, which hold no work item content.
• We fix reported vulnerabilities within Atlassian's deadlines and tell Atlassian about any security incident within 24 hours.

Data handling

• No egress. The app makes no requests outside Atlassian. Its manifest declares no external fetch permissions, no remote backend and no web trigger.
• No storage of its own. The app has no database, no file storage and no Forge storage. Each rule's settings are saved by Jira inside the workflow, in your site.
• Least privilege. The app asks only for the Jira permissions its rules need; each one is listed with its use in the privacy policy.
• Logs. Forge logs record the rule, the work item key, the outcome and, when Jira refuses a change, the HTTP status and error text. They hold no summaries, descriptions, field values, names or account IDs. Atlassian keeps them for 30 days.
• No secrets. The app holds no API keys, tokens or passwords for any other service.

Encryption and hosting

The app keeps no data, so it has nothing of its own to encrypt. Everything it handles stays on Atlassian's infrastructure, where your site is hosted, and follows your site's data residency. Encryption in transit and at rest is provided by Atlassian; see the Atlassian Trust Center.

Access

MSC Labs is one developer, Muhammed Said Çakır. Only he can deploy the app. Every production version is built from a private source repository, and every change in it is on the repository's main branch, where it passed the app's tests. We have no access to your Jira site; what we can see is the app's Forge logs and the list of sites where it is installed.

Vulnerability management

• Dependency alerts (GitHub Dependabot) are watched, and npm audit runs before every deploy.
• Every change runs the app's tests, type check and build in CI; Atlassian's forge lint runs before deploying.
• Vulnerabilities reported to us or through Atlassian are rated by CVSS and fixed within Atlassian's deadlines for cloud apps:

A fixed version reaches every site on the same major version automatically.

Security incidents

We follow a written incident response plan based on Atlassian's guidelines:

1. Assess what happened, which versions and sites are affected, and whether any end-user data was touched.
2. Notify Atlassian within 24 hours of becoming aware, and update them at least every 6 hours until it is resolved.
3. Contain: deploy a fixed or reduced version, roll back, or ask Atlassian to hide the app; revoke and rotate credentials if an account is involved.
4. Fix the cause and add a test that would have caught it.
5. Tell affected customers, where possible within 72 hours of identifying the incident: what happened, the impact, and any action they need to take.
6. Review within 14 days of containment and record the changes made.

Reporting a vulnerability

Write to muhammedsaidcakir@msclabs.tr with “Security” in the subject. Please include the steps to reproduce and the app version. We confirm receipt within 2 working days and keep you informed until it is fixed. Please do not test against Jira sites you do not own.

Certifications

The app holds no security certifications of its own (such as SOC 2 or ISO 27001). It runs on Atlassian's platform, whose certifications are listed in the Atlassian Trust Center.

Changes to this policy

When our security practices change, we update this page the same day and change the date above.