Vulnerability Disclosure Policy

Last updated: 17 October 2026

TAJ APPS LLC (“TajApps”) publishes two policies on this page. The first explains how to report a security vulnerability in our own services and what you can expect from us. The second explains how we disclose vulnerabilities that our researchers find in other companies’ software.

---

Reporting a vulnerability to us

How to report

Email support@tajapps.com with “Security report” in the subject line. Please include:

• the affected URL or component, and its version where known;
• a description of the issue and its impact;
• steps to reproduce, or a proof of concept;
• how you would like to be credited, if at all.

Reports in English are preferred. Turkish is also fine.

Please do not send:

• automated scanner output with no demonstrated, exploitable impact;
• missing security headers, cookie flags or TLS configuration findings with no working exploit;
• reports based on a software version number alone;
• theoretical issues with no proof of concept;
• anything already listed as out of scope below.

Scope

In scope

• tajapps.com and its subpages.

Out of scope for unsolicited testing

• app.tajapps.com, including the Privara console, API and CLI;
• Privara virtual device images (Android, Kali Linux, iOS analysis);
• any page marked confidential or noindex;
• any instance, tenant, account or data belonging to another customer;
• third-party services we use but do not operate;
• denial of service and resource exhaustion testing;
• social engineering and physical attacks.

Do not test these without our written authorisation. If you want to look at the Privara platform, email support@tajapps.com and tell us what you plan to do. We arrange authorised testing on a dedicated instance case by case.

If you find an issue in an out-of-scope system without testing for it, for example as a customer or during authorised work, report it anyway. We will act on it. The safe harbour below applies only to in-scope testing, but we will not pursue anyone who reports an out-of-scope issue to us in good faith.

How to test

• Use a test account, never a real one. tajapps.com has no customer accounts. For authorised testing of the Privara platform, use only the dedicated instance and account we set up for you.
• Identify your traffic. Send the header X-Security-Research: your-email-or-handle with every request, or include the same value in your User-Agent string, so we can tell your testing apart from an attack.
• Keep the rate low. Send no more than 5 requests per second to any one host, run no high-volume automated scans, and stop your tools as soon as they produce errors or slow responses.
• If you reach data that is not yours, stop and tell us in your report exactly what you saw.

Response targets

When you report an issue to us, you can expect:

• acknowledgement within 5 business days;
• an initial assessment within 10 business days;
• a status update at least every 14 days until the issue is resolved.

We aim to remediate on the following targets, measured from our initial assessment:

Severity	Remediation target
Critical	30 days
High	90 days
Medium and low	Best effort, with our reasoning given in the regular status updates.

These are targets rather than guarantees. If we expect to miss one, we will tell you before the deadline and give you a revised date.

Safe harbour

If you make a good-faith effort to follow this policy while testing the in-scope systems above, TAJ APPS LLC will consider your research authorised, will not pursue or support legal action against you for it, and will work with you to understand and resolve the issue. If you are unsure whether something is in scope or permitted, ask us first at the address above.

What good faith means

You are acting in good faith when you keep testing within the scope above, stop as soon as you have confirmed a vulnerability and go no further than needed to demonstrate it, do not access, modify, delete or retain data that is not yours, do not degrade or interrupt our services, do not pivot from an in-scope system to anything else, and do not disclose the issue publicly before we have resolved it or the response targets above have passed.

Limits of this safe harbour

This safe harbour is given by TAJ APPS LLC and covers TAJ APPS LLC alone. It does not bind our customers, our suppliers, our hosting providers or any other third party, and it does not and cannot limit the application of criminal law in any jurisdiction. If a third party brings a claim against you over research that followed this policy, TAJ APPS LLC will make it known that your research was authorised by TAJ APPS LLC.

Credit and rewards

We credit reporters by name in the published advisory at tajapps.com/advisories unless you ask us not to. We do not currently run a paid bug bounty.

---

Our coordinated disclosure policy for vulnerabilities we find

This section applies when our own researchers find a vulnerability in another company’s software.

Coordination process

1. Verify. We reproduce the issue and assess its severity using CVSS.
2. Notify the vendor. We contact the affected vendor privately through its published security contact, security.txt or support channel. If we get no reply, we try again through at least one other channel.
3. Coordinate a fix. We share the technical details and a proof of concept, agree on a fix and a publication date, and retest the fix where we can.
4. Obtain a CVE ID. We request an identifier from the CVE Numbering Authority (CNA) whose scope covers the product. Where no such CNA exists, we request one from MITRE as the CNA of Last Resort.
5. Publish. We publish an advisory at tajapps.com/advisories, crediting the researcher who found the issue, and we notify the CVE Program so the record can reference it.

If a vendor goes silent, or does not engage, we may involve a national CERT or CERT/CC to help reach them before the deadline.

Disclosure timeline

Situation	When we publish
Standard	45 days after the vendor is notified, or as soon as a fix is available, whichever comes first.
Fix in progress	Up to 14 more days, if the vendor shows that a fix is about to ship.
Fix released	We may wait up to 14 days after the fix ships, so users have time to update.
Actively exploited	7 days after notification. Users need to protect themselves now.
Vendor unresponsive	When the 45-day deadline is reached, with the details limited to what users need to protect themselves.

In no circumstances will we withhold publication more than 75 days after first notifying the vendor. We may publish earlier with the vendor’s agreement, or when the vulnerability is already public.

---

Contact

TAJ APPS LLC
A Kentucky limited liability company
212 N. 2nd St., Ste 100, Richmond, KY 40475, USA
support@tajapps.com

Version 1.5. Last updated 17 October 2026.