Custom Fields for JSM PortalSecurity & compliance
Written for the people who sign off on the app: security review, data protection and procurement. Every answer follows from how the app is built.
The short version
| Question | Answer |
|---|---|
| Where does the app run? | Entirely on the Atlassian Forge platform, inside your Atlassian tenant. There is no vendor-operated infrastructure in the path. |
| Does any data leave Atlassian? | No. The app declares no external endpoints, remotes or web triggers. The platform itself would block an outbound call. |
| Are there sub-processors? | None. No third party receives any data, because no data is sent anywhere. |
| Does the vendor have access? | No. We cannot reach your site, your requests or the app’s stored configuration. |
| Are field values stored? | No. They are read from Jira when a request is viewed and never cached. |
| Can a customer read another request? | No. The request comes from Atlassian’s page context, which only carries the request being viewed. |
| Runs on Atlassian? | The app is eligible for Atlassian’s Runs on Atlassian programme, as a consequence of the answers above. |
Why unlicensed users can read and write at all
A portal customer has no Jira licence, so they cannot read most fields or write any. The app does both with its own app-level permissions, which is the only way it can work. The safety comes from what surrounds those calls: the request is always the one Atlassian says is being viewed, only the fields an administrator configured are read, and a write passes six server-side checks before Jira is called.
The consequence to plan for: Jira’s issue history attributes a portal edit to the app, not to the customer. The app therefore keeps its own log of which customer changed which field, on which request.
Data residency
The app has no servers of its own. It reads your Jira through Atlassian’s own APIs, from inside Atlassian’s infrastructure, and keeps its configuration in Forge storage in the same place. Your site’s data residency configuration governs it, exactly as it governs the rest of Jira.
What is stored
| Data | Personal data? | Retention |
|---|---|---|
| Configuration: projects, field IDs, labels, headings, hints, translations, editing settings | No | Until you change it |
| Change log: the administrator’s account ID and a timestamp for each configuration change | Account IDs are pseudonymous identifiers | Last 100 changes |
| Customer log: the customer’s account ID, a timestamp, the request key and the field IDs changed | Account IDs are pseudonymous identifiers | Last 200 changes |
No field values, no names, no e-mail addresses, no IP addresses. Nothing is recorded for anyone who only views a request, and with portal editing off the customer log is never written. Uninstalling the app deletes all of it.
Permissions (Forge scopes)
Eight scopes. Four serve the Assets feature, all of them read-only. There is no user-lookup scope and no egress permission.
| Scope | Why it is needed |
|---|---|
read:jira-work | Read the configured fields on the request being viewed; list the site’s fields and service projects for the admin pickers; read what a field accepts on that request. |
write:jira-work | Apply a customer’s permitted change. One kind of write only: an update of the request the customer is viewing. Never creates, transitions or deletes an issue. |
read:permission:jira | Verify Jira administrator, or project administrator on that project, before any configuration is read or written. |
storage:app | Forge storage for the configuration and the two capped logs. |
read:cmdb-object:jira | Resolve an Assets object to its name, and search objects for the customer’s picker within the allowed types. |
read:cmdb-schema:jira | List the Assets object schemas for the type picker. |
read:cmdb-type:jira | List the object types inside those schemas, which is what an administrator allows. |
read:servicedesk-request | One call only: look up the Assets workspace ID, which every Assets route needs. No request content is read through it. |
Controls reviewers ask about
| Control | Implementation |
|---|---|
| Authorization on every call | Admin calls re-verify Jira administrator, project calls re-verify project administrator on the project from Atlassian’s context, portal calls take the request from that context. Nothing is trusted from the browser. |
| Write constraint | Only fields marked editable, on the viewed request, for the chosen audience, with values Jira accepts. A payload naming any other field is refused as a whole. |
| No escalation through configuration | The security level and container fields are refused in the storage layer, so import and manual entry cannot introduce them. People fields can never be made editable. |
| Output safety | A value in an unrecognised shape renders as nothing, so an internal structure cannot reach an unlicensed customer. |
| Injection resistance | Every REST path parameter is validated against a strict pattern, taken from Atlassian’s context, or a constant. Assets object IDs must be digits. |
| Concurrency | Optimistic locking on every configuration save, and a baseline check on every customer edit. |
| Dangerous constructs | No dynamic code evaluation, no raw HTML, no browser storage, no direct network calls. |
| Automated verification | Storage, validation, rendering, editing, portal decisions, retries and all 26 locale files are covered by a test suite that runs on every change, plus static analysis in CI. |
Data protection
You are the controller of your data. We are neither controller nor processor of it: the app runs inside your tenant and we receive nothing, including the two logs, which only your own administrators can read or delete. Your processor for data on the platform is Atlassian, under their agreement with you, so no data processing agreement with us is needed. We will confirm that in writing for your procurement file.
What we do not claim
- No certification of our own. Atlassian’s certifications cover the platform the app runs on. They are Atlassian’s, and we do not present them as ours.
- The logs are not a compliance archive. They keep the last 100 and 200 entries.
- Jira’s issue history will not name the customer for a portal edit. That is a platform fact, not a setting.
Reporting a security concern
E-mail security@vi2va.de rather than the public support channel, with enough detail to reproduce it. We confirm receipt, keep you informed until it is resolved, and will not pursue anyone reporting in good faith. Please never include API tokens or passwords; we will never ask for them.
Start with the three fields your customers ask about most
Show them first. Open one for editing when you are ready. Nothing becomes editable until you switch it on.