Security

Report suspected security issues to support@shakamize.com with SECURITY in the subject line. This address reaches the person who writes the code, not a queue.

Please include what you did, what you observed and what you expected, and give us a reasonable window to respond before disclosing publicly. We will not pursue a reporter who acts in good faith, stays within their own Atlassian site, and does not access or destroy other people’s data.

There is no bug bounty. We say so rather than leaving you to infer it from silence. Reports are still welcome and still answered.

The app is built on Atlassian Forge and runs inside Atlassian infrastructure. Its data is held in Forge storage associated with your Atlassian site.

There is no Shakamize-operated server in the path, and no customer data is transmitted to any external service. The app uses no third-party analytics, telemetry, advertising or error-reporting service. If that ever changes, this page and the privacy policy are updated before the change takes effect.

For an assessment, that means the surface to review is the app’s declared Forge scopes and its behaviour inside your site, and nothing else. The scopes are tabulated with a reason for each in the documentation.

Because the app runs on Atlassian infrastructure, Atlassian’s handling of that data is governed by your agreement with Atlassian. We make no independent data residency guarantee.

Every change goes through a pull request. Three checks are required before anything can merge to the main branch, and they gate the merge rather than merely reporting:

Alongside them, Dependabot raises vulnerability alerts and automated fix pull requests, configured against every install root in the repository rather than the root alone. A scanner pointed at the root of this repository would silently cover half the tree and report clean, which is the failure worth naming: a partial scan does not error, it produces a confident wrong answer.

Two things this does not claim

Dependabot is detection, not a gate. No required check fails the build on a vulnerable dependency. Semgrep is static analysis and Gitleaks is secret scanning; neither reads the dependency tree. What is in place is an alert and an automated fix pull request, which is a real control and not the same one. New dependency versions are also held for a cooldown period before adoption, so a freshly published malicious release is not pulled in on the day it lands. Gitleaks does not run on Dependabot’s own pull requests, which change a lockfile and nothing else, and Semgrep does.

Shakamize Ltd is one person, and pull requests do not receive peer approval. That is the accurate description of a one person company. It is trivially checkable from the repository’s history, so any other answer would be worse than the weakness it hid. What compensates is that the controls above are automated and required rather than discretionary, and that the parts of the product where a silent error would matter most, the state machine, the hash chain and the restriction writes, are covered by tests that fail when the behaviour changes.

Severity is scored on CVSS and severity selects the deadline. The clock starts when an issue is reported or triaged, not when it is read.

Where severity cannot be determined, the higher deadline applies until it can. An unknown severity is not a low one. That is the same rule the product itself follows when it reports what it cannot establish rather than rounding it to healthy.

Notification runs on its own clock, separate from remediation.

Notification is not delayed to make remediation look faster, and it is not conditional on the incident being publicly known.

The limit on what we could reconstruct

Platform logs are retained for 14 days. That retention belongs to Atlassian and nothing we do extends it, so an incident older than 14 days may not be reconstructable from them. We would rather you knew that before an assessment than during one.

The audit trail inside the product is not a substitute and we will not offer it as one. It records what the app did in your site. It is not a record of our own environment, and treating one as the other would answer a question nobody asked.

No credential, token, password, or personal data beyond the identifier a record requires ever reaches a log. Two things make that true rather than aspirational: the house rule is to log volumes rather than rows, so counts and durations are logged and the records themselves are not; and the platform enforces the same shape by charging for log writes above an allowance and capping output per invocation.

Audit trail entries contain no free text. The reason an approver gives is a code, and the sentence you read is generated from that code when the entry is displayed, so personal data cannot arrive in the record by being typed into a comment.

Accounts that can reach the app, the repository or the publishing pipeline use a password manager and multi-factor authentication. Secrets are inventoried and rotated on event, meaning on suspected exposure, on a change of access, and on the retirement of anything that held them.

Nobody at Shakamize Ltd has standing access to your Confluence content. The app acts within the scopes you approve at install time, and the operator’s access to your site is whatever your own Confluence permissions grant, which is normally none.

The audit trail is hash-linked, and the checker that verifies it is published as source under the Apache 2.0 licence with a release for every version. You run it yourself, over an export you hold, on a machine we do not control. The documentation describes the hash construction in enough detail to reimplement independently, which is the point: a vendor asserting that its own record is intact is worth less than a record you can check.

The trail is tamper-evident, not tamper-proof. Verification detects modified or removed entries within the chain. It does not by itself detect a chain truncated at its most recent end, which is why keeping successive exports matters and why the documentation says so.

Shakamize Ltd
Security reports: support@shakamize.com, with SECURITY in the subject line
Privacy and data subject requests: see the privacy policy