Security & disclosure
A security vendor should be held to the standard it sells. This page is the policy we operate under — published, dated, and machine-readable.
Machine-readable
Our disclosure contact is published to RFC 9116, so scanners and researchers can find it without guessing.
/.well-known/security.txtoffscriptlabss@gmail.comMachine-readable
Our disclosure contact is published to RFC 9116, so scanners and researchers can find it without guessing.
/.well-known/security.txtoffscriptlabss@gmail.comIf you have found a security issue in an OFFSCRIPT property, we want to hear about it. This page says exactly how to report one, what we will do, and what we ask of you.
In scope
- toadlabs.in and its subdomains
- Any OFFSCRIPT-operated application or API
- Our public source repositories
Out of scope
- Systems belonging to our clients — report those to the client, or to us only if we operate them under contract
- Findings from automated scanners with no demonstrated impact
- Social engineering of our team or contractors
- Physical attacks, or anything that degrades service for others
- Missing security headers or best-practice deviations with no exploitable path
What we will do
- Acknowledge your report within two business days
- Give you an assessment and an intended fix timeline within ten business days
- Keep you updated while we work it, and tell you when it is fixed
- Credit you publicly if you want it, and stay quiet if you do not
- Not pursue legal action against good-faith research under this policy
What we ask of you
- Give us reasonable time to fix before disclosing publicly
- Do not access, modify, or exfiltrate data that is not yours
- Use only your own test accounts
- Do not run denial-of-service or spam testing
- One issue per report, with enough detail to reproduce it
Your data
What happens to your data during an engagement
We are asking you to hand over access to the thing you care most about protecting. Here is precisely how it is treated.
Access
We ask for the narrowest access that lets us do the agreed work, on named accounts that can be revoked. We tell you what we intend to touch before we touch it, and we do not share credentials between engineers.
Storage
Engagement data lives on encrypted disks, in a workspace scoped to that engagement. Findings and evidence are not copied to personal devices or to third-party AI services.
Retention
Test data, credentials, and evidence are returned or destroyed at the end of the engagement, and we confirm it in writing. We keep the final report only as long as you want us to.
Disclosure
What we find on your systems is yours. We do not name clients, publish findings, or use your engagement as a case study without written permission.
Deliverable
What a report actually contains
We have no sanitised sample to hand out yet — publishing one would mean publishing a client's findings. This is the structure every report follows instead.
01 — Executive summary
One page, no jargon. What was tested, what the overall posture looks like, and the three things that matter most.
02 — Scope and methodology
Exactly what was in and out of scope, the standards applied, testing windows, and the limitations of the assessment.
03 — Findings by severity
Each with reproduction steps, affected endpoints, evidence, real-world impact, and a concrete fix — not a scanner ID.
04 — Remediation plan
A prioritised order of work you can hand straight to a sprint, with effort estimates where we can give them honestly.
05 — Retest results
Issued after you remediate. States what closed, what did not, and what remains accepted risk.
Appendix — Informational notes
Hardening opportunities and observations with no direct security impact, kept out of the main body so it stays actionable.
Still have a question?
Ask before you scope. We would rather answer an awkward question early than have it surface mid-engagement.
Ahmedabad, Gujarat, India