Security¶
This repository is documentation-and-governance-first, but the same discipline that applies to code applies here: this is not a place for secrets or sensitive data, and security-relevant claims about products deserve the same scrutiny as any other claim.
What must never go in this repository¶
- API keys, tokens, passwords, or any other credential, for any service, in any form (including inside code samples — use clearly fake placeholders).
- Customer credentials of any kind.
- Personal financial records (customer or company).
- Health or medical records of any individual.
- Unredacted proprietary data belonging to a third party (e.g., a competitor's internal pricing sheet, a vendor's confidential contract terms).
If you find any of the above already in the repository, do not "fix" it by rewriting history yourself — report it (see below) so it can be removed and rotated/invalidated properly.
Reporting a security issue¶
Send a report to brokenlyre@gmail.com.
A formal, dedicated security contact and disclosure process have not yet been established — this is an interim contact only. This is tracked as an open item; see docs/governance/open-questions.md. Do not assume this address implies a formal bug-bounty or disclosure SLA — none exists yet.
When reporting, include what you found, where, and why you believe it's a security-relevant issue. Do not publicly disclose before the issue has been addressed.
Workbook protection is not security¶
Several products under this company (particularly under the Digital Products venture) may use Excel sheet/workbook protection (locking cells, hiding formulas, password-protecting a sheet) as a usability and integrity feature — it helps prevent accidental edits and protects intellectual effort embedded in a spreadsheet's structure.
This is explicitly not a security control. Sheet protection in Excel is trivially bypassed by anyone with basic tooling. Do not describe workbook protection as "securing" data, and do not use it as a substitute for actual data protection when a product handles anything sensitive. Any customer-facing language about a product being "protected" or "locked" should make clear this refers to accidental-edit prevention, not confidentiality or security guarantees.
Human review for privacy-sensitive features¶
Any feature or product surface that collects, stores, or displays personal data (even something as simple as a household inventory or a customer's name and email) requires human review before shipping, covering at minimum: what data is collected, why, where it is stored, who can access it, and how it can be deleted. This applies regardless of which venture the product belongs to.
Open status¶
The company does not yet have a formal security policy, a designated security contact role, or an incident response process. These remain open decisions — see docs/governance/open-questions.md. Until they are resolved, treat this document as the interim baseline, not a complete security program.