Work-A-Beez Responsible Disclosure Policy
Last updated: July 24, 2026
Effective Date: July 23, 2026
At Work-A-Beez, security is one of our highest priorities.
We value the efforts of security researchers, customers, and members of the security community who help us identify potential vulnerabilities responsibly.
This Responsible Disclosure Policy explains how to report suspected security vulnerabilities and describes our commitment to investigating and addressing legitimate reports.
Important: This policy is not a Bug Bounty Program and does not provide financial compensation unless expressly stated in writing by LBS.
Table of Contents
- Purpose
- Scope
- Safe Harbor
- What to Report
- What Not to Report
- Reporting Guidelines
- Our Commitment
- Response Timeline
- Coordinated Disclosure
- Exclusions
- Legal Notice
- Contact Information
Purpose
This policy exists to:
- Improve platform security
- Encourage responsible reporting
- Protect customers
- Establish a coordinated disclosure process
- Minimize security risks
- Foster collaboration with the security community
Scope
This policy applies to publicly accessible Work-A-Beez systems, including:
- www.workabeez.net
- app.workabeez.net
- docs.workabeez.net
- Official Work-A-Beez APIs
- Official mobile applications
- Official customer portals
It does not apply to third-party systems, vendors, or integrations that are not owned or operated by LBS.
Safe Harbor
If you act in good faith and follow this policy, LBS will generally not pursue legal action against you for your security research.
To qualify for Safe Harbor you must:
- Act in good faith
- Avoid customer disruption
- Avoid privacy violations
- Report findings promptly
- Give us reasonable time to investigate
- Avoid public disclosure before remediation
Safe Harbor does not apply to malicious activity or violations of applicable law.
What to Report
Examples of reportable vulnerabilities include:
Authentication Issues
- Authentication bypass
- Session hijacking
- Account takeover
- Privilege escalation
Authorization Issues
- Broken access controls
- Permission bypass
- Unauthorized data access
- Tenant isolation failures
Injection Vulnerabilities
Examples include:
- SQL Injection
- Command Injection
- LDAP Injection
- NoSQL Injection
Cross-Site Vulnerabilities
Examples include:
- Cross-Site Scripting (XSS)
- Cross-Site Request Forgery (CSRF)
API Vulnerabilities
Examples include:
- Authentication weaknesses
- Authorization failures
- Sensitive data exposure
- Rate limiting bypass
Sensitive Data Exposure
Examples include:
- Personally identifiable information
- Payroll data
- Employee records
- Authentication tokens
- API keys
Security Misconfigurations
Examples include:
- Open administrative interfaces
- Misconfigured cloud resources
- Public storage buckets
- Weak TLS configurations
Other Security Issues
Examples include:
- Remote Code Execution
- Insecure Direct Object References
- Server-Side Request Forgery
- Path Traversal
- XML External Entity (XXE)
- Deserialization vulnerabilities
What Not to Report
The following generally do not qualify as security vulnerabilities:
- Missing security headers without exploitability
- Clickjacking on non-sensitive pages
- Outdated browser warnings
- Rate limiting suggestions without impact
- UI bugs
- Cosmetic issues
- Duplicate reports
- Social engineering
- Physical security issues
- Vulnerabilities affecting unsupported browsers
Reports lacking sufficient evidence may be closed without action.
Activities That Are Not Permitted
Researchers must not:
- Access customer accounts
- View customer information
- Modify customer data
- Delete customer information
- Interrupt production services
- Deploy malware
- Conduct denial-of-service attacks
- Perform spam campaigns
- Attempt ransomware attacks
- Extort LBS or customers
Testing Guidelines
When conducting research:
You should:
- Minimize requests
- Avoid automated scanning that impacts performance
- Test only your own accounts
- Stop testing after confirming the issue
- Avoid persistence mechanisms
- Protect any data encountered
Reporting Guidelines
Please include as much information as possible.
Helpful information includes:
- Vulnerability description
- Steps to reproduce
- Affected URL
- Affected endpoint
- Screenshots
- Video demonstration (if applicable)
- Proof of Concept
- Estimated impact
- Browser and operating system
- Date discovered
Reports containing sufficient detail can generally be investigated more quickly.
How to Report
Please send vulnerability reports to:
Security Team
Email:
info@lbsconnect.net
Subject Line:
Security Vulnerability Report
Please encrypt sensitive reports when practical.
Our Commitment
When receiving a legitimate report we will generally:
- Acknowledge receipt
- Validate the report
- Assign severity
- Investigate
- Develop a remediation plan
- Deploy a fix
- Notify the reporter (when appropriate)
Typical Response Timeline
Although timelines vary depending upon complexity, our general goals are:
| Activity |
Target Time |
| Acknowledgement |
Within 3 business days |
| Initial Review |
Within 5 business days |
| Investigation |
As soon as practical |
| Resolution |
Based on severity |
| Public Disclosure |
After remediation |
These timelines are goals rather than contractual commitments.
Coordinated Disclosure
We request that researchers:
- Keep reports confidential
- Avoid public disclosure
- Allow reasonable remediation time
- Coordinate announcements with LBS
Premature public disclosure may increase customer risk.
Recognition
At our discretion, we may acknowledge individuals who responsibly disclose significant vulnerabilities.
Recognition may include:
- Thank-you correspondence
- Hall of Fame listing (future)
- Public acknowledgement (with permission)
Unless otherwise stated, Work-A-Beez does not currently operate a monetary bug bounty program.
Severity Assessment
Reports are evaluated based upon:
- Customer impact
- Exploitability
- Ease of exploitation
- Data sensitivity
- Business impact
- Platform exposure
Severity may be classified internally as:
- Critical
- High
- Medium
- Low
- Informational
Exclusions
This policy does not authorize:
- Penetration testing against customer environments
- Testing third-party vendors
- Testing employee devices
- Phishing employees
- Social engineering
- Physical intrusion
- Denial-of-service attacks
Legal Notice
Nothing in this policy:
- Grants ownership rights
- Creates contractual obligations
- Waives legal protections
- Authorizes illegal activity
LBS reserves all legal rights regarding unauthorized access or unlawful conduct.
Contact Information
Security Team
Work-A-Beez by LBS
Website
https://www.workabeez.net
Email
info@lbsconnect.net
General Support
info@lbsconnect.net
Related Documentation
- Security Overview
- Data Protection Overview
- Compliance Overview
- Privacy Policy
- Terms of Service
- Acceptable Use Policy
Revision History
| Version |
Date |
Description |
| 1.0 |
July 23, 2026 |
Initial publication |
Disclaimer
This Responsible Disclosure Policy is intended to facilitate the responsible reporting of security vulnerabilities affecting Work-A-Beez. It does not constitute authorization to access systems without permission or engage in activities prohibited by law. LBS reserves the right to modify or discontinue this policy at any time without prior notice.
© 2026 LBS. All rights reserved.
Work-A-Beez® is a product and trademark of LBS. All rights reserved.
Work-A-Beez