Security Policy

Effective from: 30 September 2026

1. Purpose

This Security Policy explains how DELTRIG protects the Service, how to report a vulnerability, and what you can expect from us when you do.

It forms part of, and must be read together with, our Terms of Service, Privacy Policy and Acceptable Use Policy. It is issued by DELTRIG, a sole proprietorship owned and operated by Rahul Chouhan, of Dakra, Khalari, Ranchi, Jharkhand, India – 829210.

Why we publish this. Someone who finds a flaw in our Service will do one of three things: tell us, tell nobody, or tell somebody else. A page that says where to send it, and promises not to punish them for sending it, is what makes the first outcome the likely one.

2. How We Protect the Service

We are honest about the scale of this operation: DELTRIG is one person. That shapes the measures we take, and it is a reason to prefer boring, verifiable controls over elaborate ones.

• Encryption in transit for all traffic, with HTTP Strict Transport Security enforced.
• Passwords stored only as salted hashes. We cannot read your password and neither can anyone who obtains our database.
• Licence keys stored only as hashes. The key exists in the email it was sent in and nowhere on our systems — which is why we cannot read it back to you, and why a breach of our database would not yield a working key.
• Domains and IP addresses hashed in licence-activation and abuse logs, rather than recorded in the clear.
• Stored credentials and third-party secrets encrypted at rest, and never written to configuration files or version control.
• Two-factor authentication available on customer accounts, and used on our own administrative access.
• Least privilege. Administrative access is limited to the proprietor. There is no support team with standing access to customer data.
• Server-side payment verification. An Order is marked paid only after our server confirms the payment directly with our payment partner and the amount matches. Nothing a browser reports is trusted with that decision.
• We never receive your payment credentials. See Clause 6 of the Privacy Policy.
• Signed, short-lived download links, so a URL cannot be lifted from a history, a log or a screenshot and reused.
• Signed, replay-protected licence requests, so a captured activation cannot be replayed.
• Rate limiting and automated abuse prevention on authentication, forms and the licensing API.
• A restrictive Content-Security-Policy and standard hardening headers on the site.
• Regular backups, held separately from production.

No system is perfectly secure and we do not claim otherwise. What we claim is that we take the ordinary measures seriously and that we will tell you the truth if something goes wrong.

3. Reporting a Vulnerability

Email [email protected] with the subject line “Security”.

Please include: what the issue is; the URL, endpoint or component affected; clear steps to reproduce it; the impact you believe it has; and any proof-of-concept, log excerpt or screenshot. If you would like credit, say so and tell us the name or handle to use.

Do not report a vulnerability through a public channel — a review, a social post, a public issue tracker, or the automated chat assistant. Those are visible to everyone, including whoever would exploit it.

Reports in English are fastest for us. You do not need a formal write-up; a clear paragraph is fine.

4. What We Commit To

• Acknowledgement within 72 hours.
• An initial assessment within 7 days, telling you whether we have reproduced it and how we are rating it.
• Progress updates while we work on it, rather than silence.
• A fix as quickly as the severity warrants. A critical issue takes priority over everything else we are doing. We will give you our expected timeline rather than a vague assurance.
• Credit where you want it, in the fix announcement or on request.
• We will tell you when it is fixed, and we will not quietly patch and stop replying.
• Where a flaw affects a product you or others have installed, we publish an update and say in the changelog that it is a security fix, so customers know to apply it with priority.
• Where a flaw exposed personal data, we notify affected individuals and the relevant authority as the law requires, and we describe what happened accurately rather than minimising it.

What we do not offer is a paid bounty. We are a one-person business and we will not pretend to a budget we do not have. What we offer instead is a fast, honest response, public credit, and a genuine thank you.

5. Safe Harbour

If you make a good-faith effort to comply with this Policy while researching and reporting, we will not pursue or support legal action against you, and we will not report you to law enforcement, in respect of that research.

We will treat your research as authorised conduct for the purposes of our Terms of Service and Acceptable Use Policy, notwithstanding the technical-conduct prohibitions in Clause 6 of the Acceptable Use Policy, and we will say so if asked by a third party.

This commitment is limited to conduct within Clauses 6 and 7 below. It does not extend to accessing or exfiltrating another person's data, to extortion, or to activity that damages the Service or its customers. And it cannot bind a third party — if your testing reaches a provider's infrastructure rather than ours, their terms apply and we cannot grant authorisation on their behalf.

6. Rules for Testing

To stay within Clause 5, please:

• Only use your own account and your own data. Create a test account if you need one.
• Stop as soon as you have confirmed a vulnerability exists. Proving access is possible is the finding; you do not need to demonstrate how much data you could reach.
• Do not access, modify, download, retain or disclose anyone else's data. If you encounter personal data accidentally, stop, do not save it, and tell us in the report.
• Do not degrade the Service. No denial-of-service, no load or stress testing, no automated scanning at a volume that affects availability, no spam.
• Do not use social engineering against us, our providers or our customers, and do not phish.
• Do not attempt physical access to any premises or hardware.
• Do not place a backdoor, persist access, or leave anything behind. Remove any test artefact you create.
• Do not test third-party services we rely on. Report to them directly.
• Do not demand payment in exchange for disclosure, or withhold details pending a fee. That is extortion, not research, and it falls outside Clause 5 entirely.

7. Disclosure Timing

Please give us 90 days from your report before publishing details, or until a fix is released, whichever is sooner.

If we are taking longer than that, talk to us — we will explain where it stands and agree a date rather than stalling. If we go quiet on you, or we are plainly not acting, publishing after 90 days is reasonable and we will not treat it as a breach of this Policy.

We will not ask you to keep a fixed issue secret indefinitely, and we will not use a disclosure deadline as leverage.

8. Scope

In scope: the website and application at deltrig.com and its subdomains; the customer account, checkout and download systems; the licensing and update API; our published products, where the flaw is in code we wrote.

Out of scope — these are generally not accepted as vulnerabilities, though a clear demonstration of real impact will still be read:

• Findings from automated scanners with no demonstrated impact.
• Missing security headers, or a cookie flag, with no exploitable consequence.
• Rate-limit or brute-force reports on endpoints that are already rate limited.
• Self-inflicted cross-site scripting requiring the victim to paste code into their own console.
• Clickjacking on a page with no sensitive action.
• Version disclosure, banner grabbing, and directory listings with no sensitive content.
• Email configuration findings (SPF, DKIM, DMARC) absent a demonstrated spoofing impact.
• Vulnerabilities in third-party services, libraries or platforms we merely use — report those upstream.
• Issues requiring a rooted or jailbroken device, an outdated browser, or physical access.
• Social engineering, phishing, or a report that we could be phished.
• Denial of service, and reports that a large enough request volume would overwhelm us.
• Behaviour that is a documented design decision — for example that download links expire, that update checks are cached for some hours, or that a fixed-term licence stops receiving updates. If you think a documented decision is nonetheless a security problem, argue it; we will listen.

9. Security of Your Own Installation

Once you install one of our products on your own server, its security becomes a shared matter, and most of it is on your side of the line. A product's code being sound does not secure a system you configure, host, extend and populate.

The measures that matter most:

• Keep the platform, its dependencies and the server patched. Most compromises of a site running our software are compromises of the surrounding stack.
• Apply our security updates promptly. When a changelog says a release is a security fix, treat it as urgent.
• Use strong, unique credentials for the platform, the database, hosting and file transfer, and enable two-factor authentication wherever it is offered.
• Take backups and verify they restore. A backup you have never tested is a hope, not a control.
• Do not commit secrets to version control, and do not leave a configuration file readable over HTTP.
• Remove what you are not using. A dormant plugin still executes.

If you believe your installation has been compromised and one of our products may be involved, tell us at [email protected]. Even if the cause turns out to be elsewhere, we would rather look.

10. Account Security, and What We Never Do

We will never ask you for your password, or for a one-time sign-in code. Not by email, not in chat, not by telephone, not ever. Anyone who asks — including someone claiming to work here — is attempting to take your account.

We do not operate a telephone support line, so a call claiming to be from DELTRIG support is not from us.

We will never ask you to install software, run a script, or grant remote access to your machine in order to receive support.

Our emails come from the deltrig.com domain. If something claiming to be from us looks wrong, do not click it — forward it to [email protected] and we will confirm whether it is ours.

If you believe your account has been accessed without your authority: change your password immediately, then email [email protected]. We can review the account's activity and lock it while we investigate.

11. Changes and Contact

We may update this Policy. The current version is published on this page with its effective date. Superseded versions are retained and available on request.

Security reports and anything urgent: [email protected]
Account security help: [email protected]
Personal data and breach enquiries: [email protected]

Thank you for reading this page. Most people never will, and the ones who do are usually the ones about to do us a favour.

DELTRIG
Security correspondence
Sole proprietorship — Proprietor: Rahul Chouhan
Dakra, Khalari, Ranchi, Jharkhand, India – 829210
Email: [email protected]
Website: https://deltrig.com