Security Disclosure¶

MassMod LLC Security posture for MassMod's Atlassian Marketplace apps

Effective Date: August 10, 2026 Last Updated: August 10, 2026

1. Introduction¶

This document describes the security architecture, access controls, data handling, and operational posture of MassMod LLC's ("MassMod") Atlassian Marketplace applications — Formation for Jira and Agile Tools for Jira (each an "Application"). It is intended for:

Customer security reviewers evaluating a MassMod Application for deployment;
Atlassian Marketplace, as part of its security review process;
Anyone evaluating MassMod's security claims.

We aim to be specific, accurate, and transparent — including about constraints and limitations. We do not make claims we cannot substantiate, and we would rather under-promise than overstate our posture. Where a section gives concrete detail (scopes, storage keys, the permission model), it uses Formation for Jira as the worked example; Agile Tools for Jira follows the same Runs-on-Atlassian architecture with its own least-privilege scope set.

2. Architecture Summary — Runs on Atlassian¶

MassMod's Applications run entirely on Atlassian's Forge platform. They have no MassMod-controlled servers, no external databases, and no third-party hosting. They make no network calls to any non-Atlassian system — all data access is through Forge's in-platform request APIs to the customer's own Atlassian products.

Layer	Provider	Function
Application runtime	Atlassian Forge	Hosts the Application's server code (Node.js), event handlers, and resolver functions
UI rendering	Atlassian Forge (Custom UI iframe)	Renders the admin interface; all assets are bundled and fonts are self-hosted — no external CDN
Data storage	Atlassian Forge KVS / storage (`storage:app`)	Stores the Application's configuration and derived state within the customer's Atlassian organization
Scheduled execution	Atlassian Forge scheduled triggers	Runs the periodic compliance sweep
External network egress	None	The Application declares no external destinations

Implication: customer data never leaves Atlassian's infrastructure as a result of the Application's operation. MassMod has no operational "back office" with access to customer data.

3. Runs on Atlassian (RoA) Eligibility¶

MassMod's Applications are eligible for and participate in Atlassian's Runs on Atlassian (RoA) program. The manifest declares no external egress (permissions.external is absent; there are no remote back ends), which we verify with forge eligibility before every release.

Multi-product note (Formation). Formation is a Jira application that can be optionally installed on Confluence to publish Config-Evidence exports. Confluence is reached through Forge's in-platform requestConfluence API (the Confluence product REST API), not through external network egress — so RoA eligibility is preserved. Customers who do not install the Confluence component are unaffected; the export simply degrades to a "connect Confluence" prompt.

4. Atlassian Platform Certifications¶

Because the Applications run on Atlassian Forge, they inherit the security controls and certifications of the underlying platform. Atlassian maintains:

SOC 2 Type II (Security, Availability, Confidentiality, Privacy);
ISO 27001 (Information Security Management);
ISO 27018 (Protection of Personal Information in Public Clouds);
GDPR readiness with EU data-residency options;
Continuous security monitoring of the Forge platform.

Atlassian's Trust Center is at https://www.atlassian.com/trust. Customer security teams should rely on Atlassian's certifications for assurance about the infrastructure that hosts the Applications.

5. Authentication and Access Control¶

Authentication is provided by the Atlassian Forge platform using the customer's own Atlassian identity. The Applications manage no passwords and no sessions of their own. Access is enforced at several layers:

Installation gate (platform-enforced). Only Atlassian Site or Organization Administrators can install a Forge application; regular users cannot.
Admin surface (platform-enforced). Formation's administration UI is a jira:adminPage module. Only users with the Jira Administrator global permission can see it, open its URL, or invoke its resolver functions — the Forge platform enforces this at both the UI and the resolver layer, so non-admins cannot reach the backend even by direct API attempts.
Viewer-scoped reads. Data the Application reads to surface information to a user runs with that user's own permissions (asUser), so a user never sees issues, fields, or configuration they could not already see in Jira.
One deliberate elevated path (Config Evidence). Formation's Config-Evidence native capture reads organization-level structural configuration (permission schemes, workflow schemes, and their associations) with application credentials (asApp). This path is admin-only, gated server-side by an entitlement check, and reads configuration structure only (see §7).
Server-side enforcement. Field governance, WIP transition limits, and transition gates are enforced in Forge validators and triggers on the server; the client is never trusted.
Server-side licensing. Edition entitlement is checked on the server for every gated function, independent of anything the UI displays.

6. Scopes and Least Privilege (Formation)¶

Formation requests a frozen, least-privilege scope set, each scope tied to a named capability:

Scope	Why it is required
`read:jira-work`	Read issues, fields, projects, issue types, and search users for rule targeting
`write:jira-work`	Write the enforced field value, post alert comments, and create UI-Modification entities
`storage:app`	Persist configuration and derived state in Forge KVS
`manage:jira-configuration`	Shape forms beyond value/lock/require (hide, relabel, re-help) via UI Modifications, and read workflow/permission-scheme structure for Config Evidence
`read:servicedesk-request`	Read service desks and request types for Jira Service Management rule contexts
`read:jira-user`	Read the viewer's account and group membership for audience targeting, and search groups for the editor
`read:space:confluence`	List Confluence spaces as export destinations (Advanced; Confluence install only)
`read:page:confluence`	List parent pages for the evidence export (Advanced; Confluence install only)
`write:page:confluence`	Create the evidence page on export, via `asUser` so the admin's own Confluence permissions apply (Advanced; Confluence install only)

Scope breadth does not affect RoA eligibility — RoA is about egress and storage, not scope count. Any future scope change is a deliberate, re-consented major version.

7. Data Handling¶

7.1 What the Application reads¶

Within the customer's Atlassian organization, Formation reads: issues, fields, projects, and issue types; JSM service desks and request types; the viewer's account and group memberships for rule targeting; and — for Config Evidence — the structure of permission schemes and workflow schemes.

7.2 What the Application stores¶

Formation stores its configuration and derived state in Atlassian's Forge KVS, within the customer's Atlassian organization:

Storage key	Contents	Purpose
`formationConfig`	The admin's rules, WIP limits, gates, and settings	The live governance configuration
`formationVersionIndex` + `formationVersion:{id}`	Point-in-time snapshots of the configuration	Version history, diff, and one-click rollback (Advanced)
`formationEvidenceIndex` + `formationEvidence:{id}`	Structural config snapshots + SHA-256 integrity hashes	Config Evidence capture, drift, and verifiable integrity (Advanced)
Sweep / gates / WIP / audit keys	Compliance-sweep state, gate/WIP configuration, and an audit log of rule activity	Enforcement and observability

All data resides in Atlassian's Forge storage within the customer's Atlassian organization. No copies are made on MassMod-controlled systems.

7.3 Structure only — logic is not captured¶

Config Evidence captures configuration structure. The bodies of workflow rules, automation rules, and scripts are not readable by any Forge application; Formation discloses them as "not inspectable" and never captures them. Evidence snapshots are hashed with SHA-256 (node:crypto) so their integrity can be independently verified.

7.4 Retention¶

Retention is bounded automatically: the version index is pruned to the most recent 50 snapshots and the evidence index to the most recent 30. On uninstall, Atlassian's Forge platform removes all of the Application's data per Atlassian's retention policies.

8. No Stored Secrets¶

Formation stores no API keys, tokens, or secrets of any kind. All Atlassian access is mediated by the Forge platform (asApp / asUser); there is no credential for the Application to hold, rotate, or leak. This is a direct consequence of the Runs-on-Atlassian architecture.

9. Audit Trail¶

The Application records an audit log of rule activity (which rules fired, and when) and a version history of configuration changes (with author and a field-level diff). Rule activity is exportable to CSV for SIEM ingestion or offline retention. Audit and version data live in Forge KVS within the customer's Atlassian organization.

10. Vulnerability Reporting¶

We take security vulnerability reports seriously. Please report privately — do not open a public issue.

Email: security@massmod.app
Subject: "Security Vulnerability Report"

Our commitment:

Acknowledge receipt within 2 business days;
Provide an initial assessment within 5 business days;
Remediate confirmed vulnerabilities in priority order by CVSS severity, with coordinated disclosure, within Atlassian's Marketplace Security Bug Fix Policy timelines — Critical (≥ 9.0) 10 days, High (≥ 7.0) 4 weeks, Medium (≥ 4.0) 12 weeks, Low (< 4.0) 25 weeks;
Credit responsible reporters publicly, with permission.

Safe harbor: researchers acting in good faith, following responsible-disclosure practice and not violating customer privacy, will not be subject to legal action by MassMod.

11. Operational Security¶

Source control. Application source is maintained under version control in Bitbucket, with two-factor authentication enforced.
Automated dependency scanning (SCA). npm audit runs on every push, on every pull request, and on a weekly schedule; High/Critical findings in shipped dependencies fail the build. Production dependencies are limited to Atlassian's official @forge/* SDKs.
Software Bill of Materials. A CycloneDX SBOM (sbom.cdx.json) is generated each release.
Manifest scope/egress check. forge lint and forge eligibility run locally before every deploy, keeping the Runs-on-Atlassian posture verified and Atlassian API credentials out of CI.
Personnel access. MassMod personnel (currently the founder) authenticate to the Forge platform via Atlassian SSO, to email infrastructure via a 2FA-enforced provider, and to source control via Bitbucket (2FA). MassMod personnel do not have operational access to customer data, because customer data does not reside on MassMod-controlled systems.
Release process. Development → staging → production, deployed via the Atlassian Forge CLI.

12. Subprocessors¶

The only subprocessor relevant to customer application data is Atlassian Pty Ltd, as the operator of the Forge platform where the Applications and their data reside. Subprocessors for MassMod's broader business operations (for example, email and DNS for company contact data) are disclosed in the Privacy Policy.

13. Compliance¶

GDPR / UK GDPR. A Data Processing Agreement is published for each Application — see the Formation DPA and the Agile Tools DPA.
SOC 2. MassMod does not currently maintain its own SOC 2 audit; it relies on Atlassian's SOC 2 Type II coverage of the Forge platform, and will pursue independent certification as its customer base justifies it.
HIPAA. The Applications are not marketed or supported for processing protected health information (PHI).
FedRAMP. The Applications are not authorized for environments requiring FedRAMP authorization.

14. Known Limitations¶

In the interest of transparency:

Config Evidence captures structure, not logic. The bodies of workflow/automation rules and scripts are not readable by any Forge application; they are disclosed as "not inspectable" rather than captured (a platform limitation, not a defect).
No per-administrator RBAC within the Application. All Jira Administrators see the same administration view; access is gated at the Jira Administrator role.
Deterministic by design. The Applications perform no runtime AI/ML inference on customer data.
Data residency is determined by Atlassian's Forge platform for the customer's organization; the Application does not offer a separate residency selection.

15. Contact¶

Security inquiries / vulnerability reports: security@massmod.app
Customer security questionnaires: support@massmod.app (subject: "Security questionnaire")
MassMod LLC

Version History¶

Version	Effective Date	Summary of Changes
1.0	August 10, 2026	Initial publication.