Vulnerability Disclosure Policy

Email buildbidz0@gmail.com. This mailbox is monitored by the BuildBidz security team and is the only channel we treat as an authenticated security report. Please do not open a public issue, post publicly, or contact individual engineers.

A useful report contains:

• The affected URL, endpoint, or application surface, and the environment you tested.
• Clear reproduction steps, ideally with the exact request and response.
• What an attacker gains — the impact matters more to us than the payload.
• Any account or tenant identifiers you used, so we can trace the activity in our audit log.

These are the targets we hold ourselves to, measured in business days from the moment your report reaches the mailbox. They are commitments of process, not a guarantee of a fix timeline for every class of issue.

• Acknowledgement — 2 business days. A human confirms receipt and gives you a reference.
• Triage and severity — 5 business days. We reproduce the issue and tell you the severity we assigned and why.
• Progress updates — every 10 business days until the report is closed.
• Remediation — guided by severity. Issues that expose customer data or cross a tenant boundary are treated as incidents and handled first.

If a report reveals that customer data was exposed, we follow our incident process and our obligations under the Digital Personal Data Protection Act, 2023, regardless of how the issue was found.

In scope: the BuildBidz web application and its API, the BuildBidz mobile and desktop applications, and the authentication, tenant-isolation, procurement, invoice, payment-state, and file-storage behaviour they expose.

Out of scope: findings in third-party services we consume, reports that rely on an already-compromised device or account, missing hardening headers with no demonstrated impact, automated scanner output with no working proof of concept, social engineering of our staff or customers, physical attacks, and denial of service.

Tenant isolation is the boundary we care about most. A report that shows one organization reading or writing another organization’s data will always be treated as high severity.

If you make a good-faith effort to follow this policy, we will treat your research as authorised. We will not pursue legal action against you, and we will not ask your internet provider to identify you. If a third party brings action against you for research that followed this policy, we will make it known that your activity was authorised.

This protection depends on you staying inside the rules in the next section. It cannot waive the rights of our customers or of any third party.

To stay within safe harbour, please:

• Use only accounts and organizations you created or were given permission to test.
• Stop as soon as you have confirmed a vulnerability. Do not pivot, escalate further, or explore how much data you can reach.
• Never download, retain, or share customer data. If you encounter personal data, stop and tell us in the report.
• Do not degrade the service: no denial of service, no load testing, no spam.
• Do not modify or delete data that is not yours.
• Give us a reasonable opportunity to fix the issue before disclosing it publicly. We aim to agree a disclosure date with you rather than impose one.

BuildBidz does not currently operate a paid bug bounty, and we would rather say so plainly than imply a reward we do not offer. We do credit researchers who report valid issues, with your permission and under the name you choose, once the fix has shipped.

This policy is published in machine-readable form at /.well-known/security.txt in accordance with RFC 9116. That file is the authoritative source for our security contact address and for the date this policy is next reviewed.