Security at Skrado

Production security baseline

These are baseline controls, not a guarantee that every preview environment or legacy deployment already meets each item. A customer evaluating production use should request the current deployment checklist and any exceptions in writing.

Customer security responsibilities

• Use unique passwords, keep browser and device software updated, and do not share user accounts.
• Limit owner access, assign roles carefully, and remove users and drivers promptly when their relationship ends.
• Treat driver links, quote links, session cookies, exports, and API keys as credentials. Do not place them in public messages, tickets, or repositories.
• Verify recipients before exporting or sending seller, driver, buyer, VIN, location, pricing, and job information.
• Keep a validated record outside Skrado for any operation where loss or delayed access would create a safety, legal, or financial emergency.
• Report suspected compromise quickly and avoid continuing to use a credential you believe is exposed.

Report a vulnerability or incident

Use the recorded support form, select “Security concern,” and start the message with [SECURITY]. Include:

• the affected URL, organization, feature, or version;
• the date and time observed, impact, and clear reproduction steps;
• screenshots or request/response excerpts with passwords, session cookies, API keys, and unrelated personal data removed;
• a safe way to contact you and whether you believe active exploitation is occurring.

For active account compromise, also write “URGENT ACCOUNT SECURITY” in the subject, sign out affected sessions when possible, rotate exposed keys, and tell us which credentials may be involved. Do not send secrets in the report.

Good-faith research guidelines

We welcome responsible, low-impact reports. There is no paid bug-bounty program or guaranteed reward. To remain within this good-faith policy:

• Test only accounts and organizations you own or have written permission to test.
• Stop immediately if you encounter another person's data; do not copy, alter, download, retain, or disclose it.
• Do not use denial of service, automated high-volume scanning, social engineering, credential attacks, malware, physical attacks, or third-party provider attacks.
• Do not make a vulnerability public until we confirm a reasonable remediation window, and never publish personal data or credentials.
• Make a good-faith effort to avoid privacy violations, service disruption, data destruction, and degraded customer operations.

If research follows these rules and is intended to improve security, Biznomad will not initiate legal action based solely on that research. This statement cannot authorize conduct prohibited by another party or applicable law.

Response process

1. We acknowledge a credible report and assign an owner.
2. We reproduce, assess severity, contain active risk, and preserve relevant evidence.
3. We develop and test a fix, rotate affected credentials when needed, and deploy through the controlled release process.
4. We notify affected customers or authorities when facts and applicable obligations require it.
5. We close the report with a summary appropriate to the reporter and record preventive follow-up work.

Response times depend on severity, available contact information, and whether the report can be reproduced. The Support page lists operational response targets; they are targets, not a service-level agreement.