Safe harbour for good-faith research.

TenderPulse takes security research seriously. If you discover a vulnerability in our service, we want you to tell us, and we want the act of telling us to be safe and welcome — not legally fraught. This page describes the rules of the road for good-faith vulnerability disclosure to TenderPulse.

Concretely, we commit to: acknowledging your report within 72 hours of receipt, providing a triage update within 7 days, fixing confirmed vulnerabilities within timeframes proportional to their severity, and publicly crediting you in our changelog (if you wish) once the fix is deployed.

The following properties and surfaces are in scope:

• tenderpulse.com.bd — apex marketing and content site
• dashboard.tenderpulse.com.bd — authenticated customer application
• manage.tenderpulse.com.bd — admin tooling (limited black-box only; please do not attempt to register an account)
• REST and GraphQL API endpoints under api.tenderpulse.com.bd
• Authentication flows including sign-up, login, OTP, password reset, and session management
• Payment integration (EPS handover, callback verification)
• Email and SMS templates rendered from our infrastructure

Vulnerability classes we are particularly interested in: authentication or authorisation bypasses, server-side request forgery, SQL or NoSQL injection, remote code execution, data leakage between tenants, privilege escalation, IDOR (insecure direct object reference), exposed credentials in artefacts, and memory-safety issues.

Out of scope:

• Denial-of-service attacks (volumetric or application-layer)
• Social engineering of TenderPulse staff or customers
• Physical access to TenderPulse offices
• Vulnerabilities in third-party services (our cloud provider, Anthropic, EPS, Cloudflare, Resend) — please report those to the respective vendor’s VRP
• Issues requiring physical access to a victim’s device or the victim’s active cooperation
• Best-practice findings that do not lead to a security impact (missing security headers without a demonstrable exploit, TLS cipher preferences, etc.)
• Self-XSS that requires a victim to paste a payload into their own browser console
• Rate-limit findings on public endpoints unless they enable a concrete attack (account enumeration, credential stuffing at scale)

When researching vulnerabilities on TenderPulse, please:

• Use only test accounts you have created yourself. Do not access data belonging to other customers.
• Stop the moment you have confirmed the vulnerability. Do not attempt to access more data, escalate further, or pivot to production systems.
• Do not modify or destroy data. Read-only proof-of-concept is sufficient.
• Do not exfiltrate data beyond the minimum needed to demonstrate the issue. If you accidentally see customer data, stop immediately and report.
• Do not test denial-of-service, account enumeration via mass brute force, or any technique that affects service availability for other customers.
• Keep the vulnerability private until we have confirmed a fix is deployed. We will coordinate the public disclosure timeline with you.

Reports that go through this process will be treated as good- faith research and protected by the safe-harbour clause in §1. Reports that do not — for example, ones that demand payment as a condition of disclosure, or ones that follow public exploitation — fall outside the safe harbour and we reserve our legal rights.

Send your report to help@tenderpulse.com.bd with the subject line “VULN-DISCLOSURE: [short title]”. Include:

• A description of the vulnerability and its impact
• Steps to reproduce, including any payload or PoC code
• The affected URL, endpoint, or component
• Your test account ID (if applicable)
• Whether you wish to be credited publicly (and how — name, handle, or anonymous)

For especially sensitive reports, you may use our PGP public key, fingerprint F2D3 9C45 7BA2 1E6F 3D3D 8E1F C0DA AE52 8FFA 11C7. Reach out for the full key block via email; we will respond with the armored key within one business day.

We do not currently operate a paid bug bounty programme. We do offer non-monetary acknowledgement: public credit in our changelog, a private letter of recommendation on request (if appropriate for your career situation), and a TenderPulse swag pack for the first valid report from any researcher.

Our internal SLAs for handling reports:

• Acknowledgement — within 72 hours of receipt, we send a human reply confirming we received your report and assigning a tracking ID.
• Triage — within 7 calendar days, we send a severity assessment, an initial reproduction confirmation (or a request for clarification), and an estimated fix timeline.
• Fix and verification:
  • Critical (CVSS 9.0+) — patched within 7 days
  • High (CVSS 7.0–8.9) — patched within 30 days
  • Medium (CVSS 4.0–6.9) — patched within 90 days
  • Low (CVSS < 4.0) — best-effort, typically next planned release
• Public disclosure — coordinated with the researcher. Default is 90 days from initial report, or sooner if a fix is verified deployed.

If we cannot meet a stated timeline, we will tell you explicitly with a revised estimate and the reason. We do not silently miss deadlines. ISO/IEC 27001

We will publicly thank the researchers who help keep TenderPulse customers safe. As reports are received, validated, and fixed, this section will list each researcher (by their preferred name or handle) along with the year of the disclosure. Researchers who prefer to remain anonymous can opt out at the time of report.

As of this version of the page, no public-facing vulnerabilities have been disclosed via this channel. The list will appear here as the policy is exercised.