Only the following versions of Grantex components receive security patches:

If you are running a version not listed above, please upgrade before reporting.

Do not open a public GitHub issue for security vulnerabilities.

Report via one of:

• Email: security@grantex.dev
• GitHub Security Advisories: Report a vulnerability

Include in your report:

• A clear description of the vulnerability and its potential impact
• The affected component(s): auth-service, sdk-ts, sdk-py, cli, or SPEC.md
• Steps to reproduce or a minimal proof-of-concept
• Any suggested mitigations you have identified

If a report contains exploit code, customer data, or other material you do not want to send in cleartext, request our PGP key by emailing security@grantex.dev with the subject "PGP key request" and we will reply with the current public key and its fingerprint within one business day. No public PGP-key URL is currently published, so email is the source of truth. Do not assume any key you find on a public key server is ours unless the fingerprint matches what we emailed you.

Acknowledgement and substantive-response windows apply to every report. Remediation targets depend on the assessed severity using the CVSS v3.1 qualitative scale:

Severity is assigned by the Grantex security responder based on CVSS v3.1 exploitability, scope, and impact. We will share our reasoning with the reporter and adjust on substantive feedback. If the issue is in a third-party dependency, the calendar starts when the upstream patch (or a Grantex mitigation) is available.

We follow a coordinated disclosure model:

1. Reporter submits vulnerability to security@grantex.dev.
2. We triage, reproduce, and confirm within 7 business days.
3. We develop and test a fix, keeping the reporter in the loop.
4. We publish a patched release and a CVE (if applicable).
5. Reporter is credited by name (or anonymously, at their choice) in the release notes.
6. Reporter may publish their own write-up 30 days after the patched release ships, or earlier by mutual agreement.

We will not pursue legal action against researchers who act in good faith and follow this policy.

• Vulnerabilities in third-party dependencies (report upstream; let us know so we can track)
• Physical access attacks
• Social engineering of Grantex staff
• Denial-of-service attacks against hosted infrastructure
• Findings that require the attacker to already have valid admin credentials with no additional privilege escalation
• Automated scanner output without evidence of exploitability

Grantex does not currently operate a paid bug bounty programme. We are an open-source project and a small commercial team; a formal monetary programme is on the roadmap but is not in place today, and we will not invent one.

What we do offer:

• Researcher credit — researchers who report a valid vulnerability and follow this policy may be credited by name (or anonymously, on request) in the release notes for the fix. No separate public Hall of Thanks page is currently published.
• CVE assignment — for qualifying issues we will request a CVE via the GitHub CNA and credit you in it.
• Swag — Grantex stickers / shirt, on request, when shipping logistics allow.

If you are reporting to us under a third-party VDP platform (e.g. HackerOne, Bugcrowd) on behalf of one of our customers: please also send a copy to security@grantex.dev so we can triage in parallel.

• Data Processing Addendum (template)
• Sub-processor disclosure
• Data residency statement
• Privacy Policy (draft)
• Terms of Service (draft)
• Cookie Policy (draft)
• SOC 2 readiness control mapping — not a third-party attestation; see the file's own warning block.