FieldLock for Jira · version 1.0 · 4 September 2026
FieldLock is an Atlassian Forge app. It has no external backend, no server of ours in the data path, no analytics and no third-party services. Everything it stores stays inside your own Atlassian instance, in your Atlassian region. The practical consequence is the one worth stating first: we cannot read your data, because no copy of it ever reaches us. There is no database on our side to breach, no API key of yours for us to lose, and no export of your issues sitting anywhere outside Atlassian. (The only server we run hosts these documentation pages; it never sees customer data — see section 10.)
One narrow exception is stated here rather than buried: the app's own technical log lines, visible to us in Atlassian's developer tooling, carry issue, project and field identifiers — never field values, reason texts or names. We declare those identifiers as end-user data in our Marketplace privacy and security statement, and section 5 describes exactly what they contain.
This document describes what we do control — the app's own security properties, how it is built and released, how we handle reports and incidents — and is honest about what we do not have. It is written for a security reviewer who needs to answer «what is the risk of installing this», so it states limits plainly rather than claiming certifications we have not earned.
Security contact:
support@aphexcoding.tech, subject line
SECURITY.
FieldLock is published by Yzukar, trading on the Atlassian Marketplace as Aphex Coding — a sole-proprietor software vendor based in Poland (EU). There is no separate security department, and this policy does not pretend otherwise. What compensates for the small size is the deliberately small attack surface: the app was designed so that a vendor compromise cannot expose customer data, because the vendor holds none.
Anything below that reads like a corporate control (access reviews, onboarding and offboarding, segregation of duties) should be read at that scale — one person, one set of credentials, no employees or contractors with access to anything.
Security here is split between three parties, and it is worth being precise about which one holds what:
| Layer | Owner | What it covers |
|---|---|---|
| Infrastructure | Atlassian | Hosting, encryption at rest and in transit, network security, physical security, availability, platform patching, tenant isolation. Published at atlassian.com/trust. FieldLock runs entirely on Forge, so this layer is Atlassian's programme, not ours. |
| Platform runtime | Atlassian Forge | Sandboxed execution, egress blocked by default, scoped OAuth tokens, hosted storage (KVS and Forge SQL) pinned to your instance's region, function isolation between tenants. |
| Application | Yzukar (us) | The app's own logic: permission checks, the tamper-evident log, the signing key, what gets written to storage and to logs, the minimum set of scopes requested, and secure development and release of that code. This is the part this policy is really about. |
| Configuration | You, the customer | Who is a Jira administrator, who is named as an approver in the app's project settings, which field is protected, and your own Atlassian account security (SSO, MFA, session policy). |
This is the control that matters most, so it is stated as a set of verifiable facts rather than as a promise:
permissions.external and no remotes. There is nowhere for data to go.You do not have to take our word for any of the above. Forge apps run on Atlassian's infrastructure under Atlassian's egress controls, and the app's declared scopes and permissions are visible to your administrator before installation.
Least privilege. The app requests only the scopes it needs to do its job: read and write Jira work items, read Jira user information (to resolve who an approver is), and app storage. It requests no administrative scopes and no access to other Atlassian products.
Authorisation is checked per action, in the backend. Approval and unlock actions verify the caller's project permissions and their visibility of the issue on the server side, using the caller's own identity — not the app's. Hiding a button in the interface is not treated as a security control.
Input validation. User input reaches the app from exactly two screens: the change-request form on the issue (a proposed value and a justification) and the project settings page. Values are coerced to string, Unicode-normalised (NFC), trimmed and checked against the configured field type; empty input is rejected rather than silently clearing a protected value. Justifications are length-limited and reject line breaks and control characters. Database access uses parameterised statements only.
Tamper-evident audit log. The change log is append-only and hash-chained with SHA-256: each entry commits to the previous one, so a deleted or edited entry breaks the chain and becomes detectable. The log is the product's core value, so its integrity is a security property, not a convenience.
Per-installation signing key. Exported proof documents are sealed with a keyed hash (HMAC-SHA-256) using a random key generated by each installation. The key is stored in app storage, never leaves it, and is never displayed, exported or written to a log — the export carries the seal, not the key. A proof can therefore be re-verified inside the installation that issued it, and one customer's key cannot validate another customer's proof.
Fail-closed on authorisation, and explicit about licence state. When a permission check cannot be completed, the app denies the action rather than allowing it. Licence state is a separate question and we answer it plainly. With an inactive licence the app stops accepting changes, requests, approvals and settings edits, while the log and proof export keep working, so audit data is never held hostage. In Locked mode the protected value stays frozen. In Guarded mode the protected field is your own native Jira field, not ours, so protection stops entirely and the field returns to normal Jira behaviour — we will not hold a customer's own field hostage over a licence. Where the platform reports no licence information at all, the app treats the state as active rather than inactive; that is a deliberate choice, so that a paying customer never loses protection because of a missing licence signal.
Tenant isolation. Forge storage is scoped per installation by the platform. The app has no cross-tenant queries and no concept of a global administrator.
The technical logs our code writes are visible to us only through Atlassian's developer tooling, with the platform's retention of 30 days. They contain issue, project and field identifiers, event types, entry numbers, hash fragments and licence state.
They deliberately do not contain protected field values, reason texts, user display names or the signing key. Where the app records that an unapproved change occurred, it logs the fact that the old and new values differed — never the values themselves.
We do not ship logs anywhere. There is no log aggregation service, no observability vendor and no third party with whom logs are shared. We treat identifiers in logs as end-user data and declare them as such in our Marketplace privacy and security statement, rather than claiming the logs are anonymous.
Monitoring is proportionate and we say so plainly: there is no 24/7 security operations centre, no alerting and no automated intrusion detection on the application, and we do not retain logs for 12 months. Atlassian monitors the platform; we review application logs when investigating a report or a release.
Change review, described exactly as it is. Changes go through a structured review against a checklist — authorisation, input handling, secret handling, error paths — before release. What that is not: there is no enforced pull-request gate on the repository and no independent second reviewer, because there is one person here. That is exactly what we answered in Atlassian's Marketplace Security questionnaire, and this page does not upgrade it.
Automated tests. The app ships with an automated test suite that must be green before release; it covers the permission checks, the log chain and the licence gate specifically, not just the happy path.
Dependency hygiene, with the current numbers rather than a principle. The
runtime dependency set is deliberately minimal: Atlassian's Forge packages and React. It is scanned
with npm audit as part of the release routine. As of 4 September 2026 that scan
reports 8 advisories (5 high, 3 moderate) in the runtime tree, all of them transitive
through Atlassian's own @forge/react → @atlaskit packages (for
example an advisory in uuid reaching us via @atlaskit/react-ufo). None of
them has a fix we can apply without forking Atlassian's UI library, we have not claimed that the
affected code paths are unreachable, and we re-check on every release and update as soon as
Atlassian ships fixed packages. This is why our answer to Atlassian's question «are your libraries
free from vulnerabilities» is No — we would rather show the number than imply a
clean tree.
No secrets in the repository. The app holds no API keys, and the source repository contains no credentials, tokens or customer data. Publisher credentials are held outside the repository.
Release path. Code is deployed to Forge environments through Atlassian's own tooling; a production release is a deliberate, separate step from development and staging.
Access to the Atlassian Marketplace publisher account, the Forge developer console and the source repository is limited to the sole proprietor. The publisher account is protected by two-step verification with a time-based one-time password, and its recovery key is kept separately from the account it protects; repository access uses key-based authentication. There is no written password policy and no periodic access review, because there is no one to enforce them against — we said exactly that in the questionnaire. No employee, contractor or third party holds access to any of these accounts.
Because the vendor holds no customer data, the blast radius of a compromise of those accounts is the ability to publish a malicious app version — which is why the publisher account's two-step verification, and Atlassian's own review of published versions, are the controls that matter here, and why we do not share those credentials with anyone.
Write to support@aphexcoding.tech with
SECURITY in the subject line. Security reports jump ahead of ordinary support.
| Step | What we aim for |
|---|---|
| Acknowledgement | within 2 business days |
| Initial assessment | within 5 business days — severity, whether it is reproducible, and what we intend to do |
| Fix for a confirmed critical or high issue | we prioritise it over other work and keep the reporter updated until a fixed version is released |
| Credit | we will credit you if you want it, and respect a request to stay anonymous |
These are targets, not contractual guarantees. This is a one-person operation, so a report that arrives during illness or leave may wait longer; we would rather write that here than quote a response time we cannot always meet.
For confirmed vulnerabilities in the app, the deadlines that apply to us are the ones in Atlassian's Marketplace Security Bug Fix Policy, which binds us as a Marketplace partner. We work to those rather than inventing our own.
Please give us a reasonable chance to fix an issue before disclosing it publicly. We will not pursue legal action against a researcher who reports in good faith, stays within their own test instance, does not access other customers' data and does not degrade the service. Please do not run automated scanning against Atlassian's infrastructure — that is Atlassian's estate, not ours, and is covered by Atlassian's own programme.
We do not operate a paid bug bounty.
If we become aware of a security incident affecting the app, we will:
Our role under GDPR is processor, not controller; the notification obligations towards supervisory authorities and data subjects remain with you as controller, and our job is to give you what you need to meet them.
This is our stated procedure and our commitment to you. It is deliberately not called a plan: we told Atlassian in the Marketplace Security questionnaire that we do not maintain a comprehensive, periodically tested incident-response plan, and that answer stands. What you get here is what we will do, published in advance, from one person who can act on it the same day.
The app has no service of ours to go down: it runs inside Atlassian's platform, so its availability is Atlassian's availability. If we were to disappear entirely tomorrow, an installed copy would keep running on Atlassian's platform and your log and proof exports would remain readable from your own instance; active protection depends on an active licence, as described in section 4. The source code is version-controlled with off-machine backups.
This page and the app's other documents are static pages on a small server we run for documentation only. That server holds no customer data; if it were compromised or lost, no customer data would be involved.
Stated plainly, so that no reviewer has to guess and no answer here contradicts our Marketplace submissions:
If your procurement process requires any of these, tell us before you buy — we would rather lose the sale than have you discover a missing artefact during an audit. Where a control is genuinely provided by Atlassian rather than by us (infrastructure certifications, penetration testing of the platform, physical security), the artefact you need is Atlassian's, and it is published at atlassian.com/trust.
This is version 1.0, published 4 September 2026. Material changes will be published on this page with a new version number and date. The related documents are the privacy policy (what data is involved and why) and the data processing agreement (the Article 28 GDPR contract, whose Article 32 section states the same technical measures summarised here).