Security
This page brings together three policies: vulnerability disclosure, incident response, and information security. It describes what we actually do, at our own scale — an independent publisher releasing an application hosted entirely on the Atlassian Forge platform, with no server or infrastructure of its own.
1. Vulnerability disclosure
How to reach us
Send any report to contact@miksumia.com. We acknowledge receipt within two business days and keep you informed of progress. Anonymous reports are accepted.
Useful information
- description of the vulnerability and of its potential impact;
- where it occurs;
- steps to reproduce, with screenshots or scripts if possible.
French and English are equally acceptable.
Target remediation times
They run from the triage of the report. They comply with the Atlassian Marketplace security bug fix policy, which sets the maximum timeframes for a Cloud application.
| Severity | Target | Atlassian maximum timeframe |
|---|---|---|
| Critical | 7 days | 10 days |
| High | 4 weeks | 4 weeks |
| Medium | 12 weeks | 12 weeks |
| Low | 25 weeks | 25 weeks |
Scope
This policy covers the “Miksumia Publisher” application and the miksumia.com website. The third-party platforms on which the application runs or whose APIs it consumes — Atlassian, Google — fall outside this scope: contact their respective programmes directly.
What we ask of you
- report the flaw to us as soon as it is discovered, and give us a reasonable time to fix it before any publication;
- do not degrade the service, or destroy or modify data;
- exploit a flaw only to the extent necessary to demonstrate it: no data extraction, no persistence, no pivoting to other systems;
- stop testing immediately and notify us if you access personal or confidential data, and keep that data confidential.
The following are not authorised: denial-of-service testing, social engineering and physical testing.
Our commitment
Research conducted in accordance with this policy is considered authorised. We will not take legal action against it and we will work with you to understand and fix the problem.
2. Incident response
Purpose and responsibility
This policy defines the course of action in the event of a security incident or data breach concerning the application. As MIKSUMIA is a one-person company, the managing director assumes all roles: receiving the report, investigation, remediation, communication.
Reporting
Any suspected or confirmed incident must be reported without delay to contact@miksumia.com, whether the report comes from a customer, a security researcher, a third-party platform or our own monitoring.
Procedure
- Triage. Reproduce the problem, establish its nature and extent, and determine whether personal data is involved.
- Contain. Suspend or revoke the access concerned. The application can be disabled on an installation, and the Google authorisation revoked, without waiting for the fix.
- Fix. Develop the fix, verify it with tests, then deploy it to development before production.
- Communicate. Inform the administrators of the sites concerned, and the third-party platforms when their scope is involved.
- Prevent recurrence. Add a test covering the case, and look for occurrences of the same pattern elsewhere in the code.
- Record. Document the incident, its cause and its resolution.
Personal data breach
In the event of a personal data breach likely to result in a risk to the data subjects, we notify the CNIL within 72 hours of becoming aware of the breach, in accordance with Article 33 of the GDPR. Where the risk is high, the data subjects are informed without undue delay, in accordance with Article 34. The administrators of the Confluence sites concerned are informed in all cases.
3. Information security
Scope
The application runs entirely within Atlassian Forge's managed sandbox. We operate no server, no database and no network of our own. The security of the hosting infrastructure is the responsibility of Atlassian; what follows describes what is our responsibility.
Data retained, location and subprocessors
The application retains, per Confluence site, in the Forge storage hosted by Atlassian:
- the connection settings: Drive folder identifier, target space, status, synchronisation and translation settings;
- for each synchronised document: Drive identifier, document title, type, parent folder, Confluence page identifier, SHA-256 fingerprint of the published content, technical state;
- for each folder: folder title and identifiers; exclusion rules (file and folder identifiers);
- technical records: synchronisations, notification channels, monthly AI counters, emergency switches, audit events, technical facts per PDF.
The full content of documents is not retained: it is read, converted and published in Confluence. The Google refresh token is kept in Forge's encrypted secrets storage.
Data is processed and stored on the Atlassian Forge infrastructure. Miksumia operates neither a server nor a database. Data leaves Atlassian only to the Google services below; calls to Confluence go through Forge and are not an egress to the outside. For hosting (location, encryption, certifications), see Atlassian's pages: Atlassian Trust Center and Forge security.
| Subprocessor | Role |
|---|---|
| Atlassian | Application hosting and storage (Forge); Confluence |
| Read-only access to Drive, Sheets and Slides (OAuth authorisation); Gemini API for only the features enabled by an administrator |
Declared network destinations
Exactly the addresses declared in the application's manifest:
- www.googleapis.com, oauth2.googleapis.com, sheets.googleapis.com, slides.googleapis.com, docs.google.com and *.googleusercontent.com: reading of the connected files and OAuth authorisation, read-only. They receive the access token and file identifiers;
- generativelanguage.googleapis.com: Gemini API (Gemini Developer API, not Vertex AI). It is the only service that receives customer content.
Gemini receives content in two cases only. (1) Translation: as soon as an administrator chooses a language for a folder, the text of its documents is sent to it on every synchronisation of that folder. (2) AI reading of a scanned PDF: it is requested document by document, and the pages of the PDF are then sent. A fixed instruction accompanies the request; the title, the file name, the space and the user are not sent. Nothing else leaves Atlassian: no Confluence content, no Atlassian user data, no telemetry, no audience analytics, no external logging.
Retention and deletion
- Storage has no time-to-live: records last as long as the connection. Only the OAuth anti-CSRF state expires (10 minutes).
- Deleting a connection (after disconnecting it) erases its document records, its folder mappings, its exclusion rules and its last synchronisation.
- Disconnecting the Google account revokes the token with Google, then deletes it.
- On uninstallation, the application first revokes the Google authorisation
(
preUninstallstep), suspends the connections and removes the notification channels. Atlassian then deletes the stored data after 28 days, according to the Forge hosted storage lifecycle (Atlassian documentation). - Pages already published remain in the customer's Confluence space, to which they belong.
- There is no self-service export. Any request: contact@miksumia.com.
Logs
Logs contain event names, technical identifiers, counters and error codes. Error messages displayed or logged are composed by the application; text coming from an upstream service is classified, then discarded. No customer content in production logs.
Data classification
- Secrets. OAuth credentials and Google refresh tokens. Handled according to the “secrets management” section below.
- Customer content. Documents read from Google Drive and derived content. Processed in memory, published in Confluence, retained only to the extent described above and in the privacy policy.
- Technical data. File identifiers, document and folder titles, fingerprints, counters, synchronisation states.
Access control
The application's features are restricted to the administrators of the Confluence site, verified server-side on every request with Confluence itself, never inferred from the interface. Access to Google Drive is requested read-only and limited to the folders explicitly connected by the administrator.
The publisher's administration accounts — Atlassian developer console, Google Cloud console, code repository — are personal and protected by two-factor authentication.
Secrets management
No secret appears in the source code. The OAuth client credentials are supplied at deployment through Forge environment variables. Refresh tokens are written exclusively to Forge's encrypted storage, revoked with Google and then deleted when the account is disconnected or the application is uninstalled. No secret is logged, returned in a response, or included in an error message.
Encryption of communications
All communications use HTTPS. The authorised network destinations are declared in the application's manifest and enforced by the platform at runtime: no other destination is reachable.
Development
- design review before implementation;
- automated tests run in continuous integration on every change;
- static security analysis of the source code, reproducible and repeatable;
- dependency analysis, with tracking of published vulnerabilities, including those introduced transitively.
Independent assessment
Miksumia Publisher V2.7.0 was assessed by TAC Security against the CASA specification v2.1.1 at assurance level AL1 (grey-box testing, 7–23 September 2026; report issued 25 September 2026). Result: In Compliance. The assessment was carried out for Google's OAuth restricted scopes (Drive read-only).
The tests used the “App Defense Alliance ADA Burp Audit Scan Configuration” configuration.
Google OAuth verification
Google's OAuth verification of the application was approved on 28 September 2026.
Cloud Security Alliance STAR registry
Our answers to the Cloud Security Alliance CAIQ Lite v4.1.0 questionnaire are listed on the CSA STAR registry since 6 October 2026 (STAR Level One): Miksumia Publisher for Confluence on the STAR registry. Level One is a self-assessment: the answers are ours, not checked by an auditor.
Review
These policies are reviewed at least once a year, and with every substantial change to the application's architecture.