Our apps run entirely on Atlassian's infrastructure. They are built on Atlassian Forge and eligible for Atlassian's Runs on Atlassian programme: no remote backend, no network calls outside Atlassian, no servers of ours and no copy of customer data held by us.
Reporting a security issue
Email soporte@vantelia.es with "Security" in the subject, or raise a request on the support portal. Include the app, your site URL if relevant, what you found and how to reproduce it. We acknowledge security reports within two business days. Please give us the time set out below to fix an issue before disclosing it publicly.
How we handle vulnerabilities
- Triage. Every report is reproduced and assessed for severity, from what data it could expose and to whom.
- Remediation deadlines. We follow Atlassian's Marketplace security bug fix policy, counted from the moment a vulnerability is confirmed:
| Severity | Example | Fix within |
|---|---|---|
| Critical | One customer's data reachable by another, or by anyone unauthenticated | 2 weeks |
| High | Privilege escalation within a site, or loss of a control the app provides | 4 weeks |
| Medium | A weakness that needs unusual conditions or elevated access to exploit | 6 weeks |
| Low | Hardening and defence in depth | 3 months |
- Fixing. Each fix comes with a test that fails without it, and goes through the same checks as every release before it ships.
- Releasing. Fixes are deployed through Forge, which updates installations automatically for minor versions. If a fix needs customers to accept a new major version, we say so in our notification.
- Dependencies. Production dependencies are scanned with
npm auditbefore every release, and advisories affecting them are fixed or mitigated within the deadlines above. We also follow Atlassian's platform advisories for the Forge packages and APIs our apps use.
Security incidents
An incident is a vulnerability in one of our apps, unauthorised access to any account or system that could reach our apps or their release process, an Atlassian advisory affecting them, or a customer report suggesting data was exposed or altered. When one occurs we:
- record a timeline from the first report;
- assess whether customer data is at risk;
- contain it first: credentials that may be exposed are revoked immediately;
- notify Atlassian through the Marketplace support portal once severity is assessed and before the fix ships, using Atlassian's vulnerability notification template;
- notify affected customers directly, through the technical contact on their installation, when their data was or may have been exposed, following Atlassian's incident communication template and incident management guidelines;
- fix, verify on a real installation, and write a short post-incident review with the change that would have prevented it.
Key security controls
| Area | What we do |
|---|---|
| Architecture | Apps are built on Atlassian Forge with no remote backend and no egress outside Atlassian. Where an app uses AI, it uses Atlassian-hosted models (Forge LLMs), inside Atlassian's platform. |
| Data protection | App data is stored only in Atlassian's Forge hosted storage, inside each customer's own Atlassian cloud instance and subject to its data residency. We keep no copy of customer data and have no servers that could hold one. Each app's privacy page lists exactly what it stores and when it is deleted. |
| Access control | Before reading or changing data on a user's behalf, our apps check with Jira's or Confluence's permission APIs that the user is allowed to; data fetched from the product in the browser is fetched as that user. Each app requests only the scopes it uses. |
| Secure development | Input is validated server-side, identity is taken from the Forge context rather than from the request, and output is rendered through Atlassian's UI Kit. Every release passes automated tests that include the apps' security guarantees, a manifest check, and the dependency audit. |
| Secrets | Our apps hold no secrets and do not ask customers for credentials or tokens. Credentials for our own developer and hosting accounts are not stored in source code and are revoked when no longer needed. |
| Logging and monitoring | Logs are limited to what is needed to diagnose errors (the operation, the error and internal identifiers) and stay in Atlassian's Forge platform; we do not log the text people write in our apps. We review Forge logs and invocation metrics after every release and whenever a customer reports a problem. |
| Accounts | Access to the Atlassian developer console, the Marketplace partner account and the source code is limited to the developer who builds the apps. |
Related
- Privacy and data handling, per app: Document Control · Estimation · Retrospectives · Standup
- Atlassian Forge security
Changes
Material changes will be reflected here and the "Last updated" date revised.