Security policy
Scope
This policy covers the apps VestaNabu LLC publishes on the Atlassian Marketplace under the Monaidea name: Ledgerstone, a read-only Jira permission audit, and Flagstone, a read-only view of open Confluence tasks and inline comments. VestaNabu LLC, 202 N Cedar Ave Ste 1, Owatonna, MN 55060, United States. Adopted on 4 October 2026 and reviewed whenever an app or Atlassian's rules change, and at least once a year.
Report a vulnerability
Email support@monaidea.com with "Security" in the subject. Say what you found and how to reproduce it, and which app and Atlassian site are involved. We answer within two business days. Please test only on Atlassian sites you own and never access other people's data. Reports also reach us through Atlassian Marketplace Security tickets.
How the apps are built
- Runs on Atlassian. The apps run only on Atlassian Forge: no servers of our own, no calls outside Atlassian, no remote back ends and no web triggers.
- Read-only access. Granular read scopes plus app storage, and no write scopes, so the apps cannot change Jira or Confluence. Ledgerstone's admin page reads Jira as the viewing administrator, so Jira applies that person's own permissions, and anything Ledgerstone gathers with its own access is shown only after Jira confirms that the viewer holds the Administer Jira permission. Flagstone reads every task, comment and page it shows as the viewing person, so Confluence applies that person's own permissions; the counts its scheduled scan gathers with its own access appear only on its admin page, and only for the spaces the viewer can see.
- No personal data stored. The apps keep only counts and configuration names in Forge hosted storage in the region of the customer's site: for Ledgerstone, permission scheme, filter, dashboard, group and role names; for Flagstone, space keys and counts per space and per page, never task or comment text or page titles. People's names are shown live and never saved. Data is deleted when an app is uninstalled, per Forge platform behaviour. Details are in each app's privacy policy: Ledgerstone and Flagstone.
- No secrets in the apps. The apps hold no secrets. Our deployment credentials are never put in code, commits or logs, and are kept only on the machines that need them.
Change control
Every production change passes automated tests (including privacy and logging tests), code linting, Atlassian's Forge checks, a check that refuses any new permission, outside connection, remote back end, web trigger or licensing change without the owner's approval, a deployment to a separate development environment, and an independent automated code review. After each release, production errors are watched, and a release that causes errors is rolled back automatically.
Logging and monitoring
App logs hold counts, timings, HTTP status codes, error kinds and our own messages. They never hold personal data, tokens, or Jira or Confluence content, and an automated test checks this. App logs are visible only to the apps' developers in Atlassian's developer console. Production errors are counted every hour, and any error goes straight to our engineering queue and our status report.
Dependencies and vulnerability fixes
We audit the apps' production dependencies every week. Vulnerabilities are triaged by CVSS severity, and our fix deadlines follow Atlassian's security bug fix policy for cloud apps: critical within 10 days, high within 4 weeks, medium within 12 weeks and low within 25 weeks, counted from when a report is received or triaged. For a critical vulnerability we tell affected customers and Atlassian, using Atlassian's vulnerability notification template.
Incident response
We follow Atlassian's app security incident management guidelines. An incident is any actual or suspected unauthorised access to, or use, disclosure, change or destruction of, customer data; a compromise of the app, its code, its deployment pipeline or our Atlassian or GitHub credentials; or anything in the app that materially degrades Atlassian's systems.
- At once: record what is known, then contain it: roll the app back, stop its scheduled job, or ask Atlassian to delist it temporarily. Revoke and replace any exposed credential.
- Within 24 hours of discovery: raise a P1 ticket with Atlassian, and send updates at least every 6 hours during remediation.
- Within 72 hours: notify affected customers by email, using Atlassian's incident communication template.
- Until fixed: fix, verify, and confirm the fix with Atlassian.
- Within 2 weeks after: review the incident (remaining signs of compromise, lessons learned, prevention, logging gaps) and share the findings with Atlassian.
What we don't have yet
We are a small company. We do not yet have security certifications or external audits, penetration tests or a bug bounty programme. This page will say so when that changes.