Skip to main content
This page is the public reference for the engineering documentation cited in the Cell Labs, Inc. Secure Development Policy. It summarizes the principles applied across all business-critical RevDesk systems and the controls that surround them.

​
Secure-by-design principles

These principles guide every design and code review at Cell Labs, Inc.
  • Minimize attack surface. Every new feature deliberately limits the inputs it accepts, the actions it exposes, and the data it stores. Unused endpoints, scopes, and permissions are removed.
  • Establish secure defaults. New features ship with the most restrictive viable configuration. Customers opt in to looser settings, not out of safer ones.
  • Least privilege. Application code, infrastructure roles, third-party integrations, and human operators receive the minimum permissions needed for the task. Credentials are scoped per role and rotated.
  • Defense in depth. No single control is relied upon. Authentication, authorization, input validation, output encoding, network segmentation, and audit logging are layered.
  • Fail securely. Errors do not leak data or grant access. A failed authorization check denies the request; a failed dependency does not bypass safeguards.
  • Don’t trust services. External services — including paid integrations — are treated as untrusted inputs. Responses are validated, retries are bounded, and timeouts are enforced.
  • Separation of duties. Authors do not approve their own changes; admins cannot unilaterally exfiltrate data without producing an audit trail.
  • Avoid security by obscurity. Controls do not depend on the secrecy of design, only on the secrecy of keys.
  • Keep security simple. Simpler controls are easier to verify. Complex schemes are reviewed especially carefully.
  • Fix security issues correctly. Security fixes address the root cause, include a regression test where feasible, and are reviewed with the same rigor as any production change.

​
Privacy-by-design principles

These principles, derived from Ann Cavoukian’s framework, apply to every system that processes customer or end-caller data.
  • Proactive, not reactive; preventative, not remedial. Privacy risks are addressed in design, not patched after incidents.
  • Privacy as the default setting. Data collection, retention, and sharing default to the minimum required to deliver the feature. Customers explicitly opt in to anything broader.
  • Privacy embedded into design. Privacy controls are part of the feature’s architecture, not bolted on at the end of a release.
  • Full functionality — positive-sum, not zero-sum. Security, functionality, and privacy coexist. We do not treat them as trade-offs to be negotiated away.
  • End-to-end security — full lifecycle protection. Data is encrypted in transit and at rest, access is logged, and deletion is supported across all storage tiers.
  • Visibility and transparency. Privacy practices are documented and verifiable. This page is part of that commitment.
  • Respect for user privacy — keep it user-centric. Customers can see what’s stored about them, export it, and request deletion.

​
Environment segregation

Production, staging, and development environments are logically and (where possible) physically segregated. Each has its own:
  • Database instance with separate credentials
  • Secret store namespace
  • Deployment target
  • Telemetry stream
Customer Confidential data is not used in development or testing environments without explicit, written authorization from both the data owner and the CTO. Anonymized or synthetic fixtures are used by default.

​
Application vulnerability management

  • Static analysis. Linters, type checking, and dependency vulnerability scanners run in CI on every pull request. High-severity findings block merge.
  • Dependency review. Third-party libraries are reviewed before adoption and tracked via lockfiles. Automated alerts surface newly disclosed vulnerabilities.
  • Patch timeline. Patches that materially impact security are deployed within 90 days of discovery. Critical vulnerabilities are escalated and patched on a much shorter timeline.

​
System security and acceptance testing

Security functionality is tested throughout the development lifecycle, not only at release:
  • Unit and integration tests cover authentication, authorization, and data-handling paths.
  • End-to-end tests cover critical user journeys (signup, payment, calendar sync, call placement).
  • A release checklist is completed before any production deploy, documenting test results and any remediation activities.
When operating platforms or upstream services change (framework upgrades, runtime upgrades, telephony provider changes), affected business-critical applications are reviewed and re-tested before the change reaches production.

​
Test data protection

Test data is selected carefully and protected at the level appropriate to its sensitivity. Customer Confidential data is not used for testing without the explicit permission of the data owner and the CTO. When customer data is required for incident reproduction, access is scoped, logged, and time-limited.

​
Restrictions on changes to third-party software

Modifications to third-party software packages are discouraged. Where unavoidable, changes are limited to the minimum required, isolated in vendored forks, and reviewed under the same procedure as first-party code.

​
Developer training

Software developers receive secure development training at least annually. Training content is determined by the CTO and addresses, at minimum:
  • Authorization bypass prevention
  • Secure session ID handling
  • Injection attack prevention (SQL, command, template)
  • Cross-site scripting (XSS) prevention
  • Cross-site request forgery (CSRF) prevention
  • Identification and avoidance of vulnerable libraries

​
Exceptions and enforcement

Requests for exceptions to the Secure Development Policy must be submitted to the CTO for approval. Violations should be reported to the CTO and may result in immediate withdrawal of system access and disciplinary action up to and including termination.