Security Policy
Last updated 6 October 2026
How Dripwork apps are built and secured, what they can and cannot reach, and how to report a vulnerability. This policy covers every app we publish.
1. Reporting a vulnerability
Email support@dripwork.dev with the subject line Security. Please include what you found, how to reproduce it, which app and which Atlassian product, and the impact as you understand it.
Please report privately first. Give us a reasonable chance to ship a fix before disclosing publicly. We will not take legal action over good-faith research that respects this and does not access, modify or destroy other people's data.
Do not include credentials, API tokens or customer data in a report. If a proof of concept needs them, say so and we will arrange something safer.
2. What happens next
These are our commitments, not estimates.
| Stage | Target |
|---|---|
| Acknowledge your report | 2 business days |
| Assessment and severity, shared with you | 5 business days |
| Fix for a critical or high-severity issue | As fast as we can, and within the deadlines in Atlassian's Marketplace security bug fix policy |
| Fix for a medium or low-severity issue | In a scheduled release |
We keep you updated while we work, tell you when the fix ships, and credit you if you want to be credited. Where an issue affects customers, we notify them and Atlassian in line with Atlassian's incident and vulnerability notification guidance.
3. How our apps are built
Our Atlassian apps are built on Atlassian Forge and run on Atlassian's own infrastructure. We operate no servers, no databases and no file storage of our own, so there is no Dripwork system holding your data to be breached.
Where an app qualifies for Runs on Atlassian, it has no external network permissions at all: it cannot make a request to any host outside Atlassian's platform, and that restriction is enforced by the platform rather than by our code. Each app's listing states whether it carries that designation.
4. Permissions and least privilege
Every app asks for the narrowest set of permissions that does its job, and each app's documentation says what those permissions can and cannot reach. We do not request write access for an app that only needs to read, and we do not request a broad scope because it is convenient.
Apps act with the permissions of the person using them. A user sees only what they could already see in the underlying product, and no feature of ours widens anyone's access.
5. Data handling
- We work on configuration, not content. Our apps are designed around settings and structure rather than the contents of your team's work.
- Stored data stays inside Atlassian. What an app stores lives in Atlassian's hosted storage for your site and follows your site's data residency.
- No analytics or tracking. We do not embed analytics, advertising or session-recording tools in our apps.
- No customer data in logs. Our app code does not log the contents of your work items.
What each app stores, and for how long, is set out in that app's own privacy policy. The Dripwork Privacy Policy covers this website and anything you send us by email.
6. Development practices
- Input that reaches storage is validated and length-limited on the server, not only in the browser.
- Output is escaped by the framework; we do not build HTML from untrusted strings.
- Exported files are generated in the browser, and spreadsheet exports neutralise formula-injection payloads.
- Changes ship through automated tests, including tests for the rules that enforce access and ownership.
- We hold no API keys or shared secrets for customer sites; all access runs through the platform's own authentication.
7. Third-party dependencies
We keep dependencies few and prefer the platform's own libraries. Dependencies are scanned for known vulnerabilities with automated tooling, and results are reviewed before a release. A dependency with a known exploitable vulnerability is updated or removed rather than shipped.
8. Access to our systems
Dripwork is a one-person operation. Access to the developer console, the Marketplace partner account and the source code is limited to that one person, protected by multi-factor authentication. There are no shared accounts and no third-party contractors with access.
We do not request, want or accept administrative access to a customer's Atlassian site in order to provide support.
9. Incidents
If a security incident affects an app or its customers, we investigate immediately, ship a fix as the first priority, and notify affected customers and Atlassian with what happened, what was affected, what we did and what you should do. We would rather tell you about something minor than have you learn about it elsewhere.
10. Scope and limits
This policy covers Dripwork's apps and this website. It does not cover the Atlassian products our apps run inside, or Atlassian's own infrastructure: vulnerabilities in those belong to Atlassian's own security programme. If you report one to us, we will pass it on and say so.
We are a small publisher without formal certifications such as SOC 2 or ISO 27001. We would rather state that plainly than imply an assurance we do not hold. What we do offer is a narrow attack surface, no infrastructure of our own, and a fast, direct line to the person who writes the code.
Atlassian, Jira and Forge are trademarks of Atlassian Pty Ltd. monday.com is a trademark of monday.com Ltd. Dripwork apps are independent products and are not made or endorsed by Atlassian or monday.com.