URSACORP Apps › Security Policy

Security Policy

How URSACORP LLC handles security issues and incidents, manages vulnerabilities, and secures the apps it publishes on the Atlassian Marketplace.

This is the Partner Security Policy for URSACORP LLC, covering the four apps we publish for Jira Cloud: Issue Aging Chart, Epic Lens, Sprint Countdown and Worklog Pivot. Data-collection practices are covered separately in our privacy policy.

URSACORP is a small company and this policy describes what actually happens, not an aspirational programme. Where we do not hold a certification or run a control, we say so rather than leaving it vague.

Reporting a vulnerability

Email security@ursacorp.org. This address is monitored and security reports are prioritised over all other correspondence.

Please include the app and version, what you did, what happened, and what you expected. A proof of concept, a screenshot or a short screen recording helps a great deal. If a report needs to be encrypted, say so in a first message and we will arrange a channel.

What to expect from us:

• An acknowledgement within the timeframe in the table below, from a person, not an autoresponder.
• An assessment of severity and impact, and our reasoning, so you can disagree with it.
• Progress updates until the issue is closed.
• Credit in the release notes if you want it, and none if you do not.

We do not run a paid bug bounty. We will not pursue legal action against anyone who reports a vulnerability to us in good faith, who stays within their own Jira site or a test site they control, who does not access, modify or destroy other people's data, and who gives us a reasonable chance to fix the issue before disclosing it publicly.

Handling security issues and incidents

We treat all of the following as security incidents, whether we find them ourselves or they are reported by a customer, a researcher or Atlassian:

• A flaw that lets a user see Jira data they have no permission to see, or that lets untrusted content execute in another user's browser.
• A high or critical severity vulnerability in a dependency the app actually reaches at runtime.
• Compromise of a credential that can publish or modify an app: the Atlassian account, the Forge CLI token, or the GitHub account holding the source.
• Any suspected unauthorised change to a published version of an app.

Response targets

The fix timeframes are the ones Atlassian's Security Bug Fix Policy for Marketplace apps requires of every cloud app. We commit to that required floor rather than advertising faster targets a company of this size could not reliably staff; in practice a reachable critical or high finding in apps this small is usually fixed much sooner. Where this page and Atlassian's policy ever diverge, Atlassian's policy governs.

What we do

1. Record. The report is logged with the app, version, reporter, and known impact.
2. Assess. We reproduce the issue on a test Jira site, assign a severity from the table above, and establish which published versions are affected.
3. Contain. A compromised publishing credential is rotated first: Atlassian account password and MFA, Forge CLI token, GitHub token. If a published version is actively harmful we ask Atlassian to unlist it rather than leave it installable while a fix is built.
4. Fix. We patch, deploy to a test site, verify the specific failure is gone, then release a new version through the Marketplace.
5. Notify. For any incident of high severity or above we notify Atlassian and affected customers within the timelines in Atlassian's incident and vulnerability notification guidance. Notification is not held back waiting for a fix: a report of what is known and what is being done comes first.
6. Close. We write down the cause and what changed, so the same failure cannot recur silently.

Vulnerability management

Our attack surface is deliberately small: the apps run on Atlassian Forge, hold no credentials, store nothing, and call no host outside Atlassian. Most of the residual risk is in third-party code, so that is where the effort goes.

• Dependency scanning (SCA). We run npm audit against the full dependency tree of every app before each release. GitHub Dependabot alerts are enabled on the source repositories, so new advisories against already-released dependencies reach us without us having to look for them.
• Triage. Each finding is assessed for whether the app actually reaches the vulnerable code path at runtime, not just whether the package appears in the tree. Reachable high and critical findings are fixed on the timelines above. Findings we judge unreachable are recorded with the reasoning and revisited at the next release rather than dismissed.
• Disclosure. Known unresolved findings are disclosed in our Atlassian Marketplace security questionnaire responses rather than left unmentioned.
• Patching. Dependency updates ship as part of ordinary releases. A fix for a reachable high or critical finding is released on its own if it would otherwise wait.
• Change review. URSACORP is a one-person company, so there is no second reviewer. Every change is instead re-read before release against a fixed checklist covering the places where Jira data crosses into the page: output escaping, query construction, and CSV export. We describe this accurately rather than call it peer review.

We do not currently run automated SAST or DAST tooling, and we do not employ external penetration testers. We would rather state that plainly than imply coverage we do not have.

Security controls

Architecture

• All four apps are built on Atlassian Forge and run entirely on Atlassian's infrastructure, inside the customer's own Jira site.
• The apps declare no external egress permissions. They cannot call any host outside Atlassian, and this is enforced by the Forge platform rather than by our own discipline.
• The apps use no Forge Storage and no database. Jira data is read, rendered in the browser, and discarded when the page closes. Nothing is retained after the request.
• No end-user data is logged. No analytics, telemetry or third-party scripts are loaded.
• There are no sub-processors, because no data ever leaves Atlassian's platform.

Least privilege

• Every app requests read-only Jira scopes. None requests any write scope.
• Each app requests the smallest set its API calls actually require. The exact scopes, with a justification for each one, are listed on each app's documentation page.
• Every Jira request runs as the signed-in viewer, not as the app. An app can therefore only ever show a person what they could already open in Jira themselves, and a bug in our code cannot widen anyone's Jira permissions.
• The apps never ask users for Atlassian API tokens, personal access tokens or passwords, and hold no customer credentials of any kind.

Handling untrusted input

Jira content is untrusted input: issue summaries, user names and field values can contain anything a user typed. Our controls at that boundary:

• Values from Jira are HTML-escaped before being written to the page, and text nodes are used in preference to markup wherever a value does not need formatting.
• JQL is built from validated components. Identifiers are matched against strict allowlist patterns and rejected if they do not match; free-text values are quoted and escaped rather than interpolated raw.
• Values interpolated into API paths and query strings are URL-encoded, and query lengths are bounded.
• CSV export follows RFC 4180 quoting and additionally defends against spreadsheet formula injection by prefixing values that begin with a formula lead character.

Access and operations

• Publishing access to the Marketplace listings and the Forge apps is held by one named person, the company's owner. There are no shared accounts.
• Multi-factor authentication is enabled on the Atlassian and GitHub accounts that can publish or modify an app.
• Source code is held in private repositories. Released versions are built from committed source.
• The development workstation runs with full disk encryption, automatic operating system updates, and Gatekeeper, XProtect and System Integrity Protection enabled.
• Credentials capable of publishing are rotated immediately on any suspicion of compromise.

Compliance posture

We hold no SOC 2, ISO 27001 or comparable certification, and we have not completed a CAIQ. For a company of this size those would be documents rather than assurance, and we would rather be accurate about that. What does apply:

• The apps run on Atlassian infrastructure, so Atlassian's own platform controls, certifications and data-residency handling apply to the environment they execute in.
• We process no personal data of our own: we are neither a data controller nor a data processor for the Jira data these apps display, because none of it is transmitted to us or stored by us.

Contact and review

• Security reports and questions: security@ursacorp.org
• General support: support@ursacorp.org
• Atlassian: through the Marketplace partner service desk at ecosystem.atlassian.net.

This policy is reviewed at least annually, and after any incident of high severity or above.