Security at CoLateral
This page describes how CoLateral is built and operated, in enough detail to be checked. It is a factual summary, not a certification: CoLateral holds no SOC 2 report and no ISO 27001 certificate, and does not claim to. Where something is not yet done, this page says so rather than leaving it out.
On this page
1. Reporting a vulnerability
Write to security@colateral.engineering. That address is also published at /.well-known/security.txt in the format described by RFC 9116.
Useful reports say what you did, what happened, and what you expected instead. Include the build number if the report is about the desktop application. CoLateral is run by one person, so an acknowledgement should be expected within five business days rather than within hours.
There is no bug bounty and no payment. What is offered instead is a straight answer: whether the finding is being fixed, and when. Findings that are accepted as real are written up in the repository with the remediation beside them, in the same form as the outside audit of August 2026.
Please do not run automated scanners against the hosted endpoints, do not test with anyone else's license key or account, and do not access, alter, or retain data that is not yours. Reports made in good faith within those limits will not be met with legal action.
2. What the product is
CoLateral is a desktop application that runs on the engineer's own machine, a static marketing website, and a small backend that issues licenses, records purchases, and serves downloads. Project files, drawings, and calculation inputs stay on the engineer's disk. The backend never receives them.
3. Licenses and devices
A license key is generated with 80 bits of entropy and is stored only as a SHA-256 hash. The plain key exists in the message that delivered it and nowhere on our side, which is why a lost key is reissued rather than looked up.
Activating a license binds it to a device. The device is identified by four values hashed on the machine before they are sent, so no hardware identifier leaves the computer in a readable form. Three of the four matching count as the same machine, so replacing a disk or renaming a computer does not consume a second license.
The application holds a signed token, which it stores encrypted at rest and tied to that machine and user account. On Windows this uses the operating system's own data protection interface; on macOS and Linux it uses a keyed scheme derived from the same machine fingerprint, and the file is written so that only its owner can read it. A store copied to another machine does not open.
4. Packs are signed twice
An expansion pack is distributed as a single sealed artifact. Its payload is encrypted with AES-256-GCM; the whole envelope is signed with Ed25519 by the creator who built it, and signed again by CoLateral at publication. The application only ever installs the second signature, and it checks that signature against a public key compiled into the application binary rather than against the key travelling inside the artifact.
That second check is the one that matters. An artifact carries its own public key, so an attacker who modifies a pack and re-signs it produces something internally consistent. Pinning the publishing key is what makes the difference visible.
5. Packs run in a sandbox the application enforces
A pack's user interface runs in its own isolated origin with its own content security policy. It cannot reach the application's storage, another pack, the local agent bridge, or the network unless the pack's signed manifest declared the exact domains and the buyer agreed to them.
The policy is not supplied by the part of the application that loads the pack. It is derived independently, in the native layer, from the signed manifest, and a policy that does not match is refused. The archive is also rebuilt and re-hashed there, so the bytes handed to the sandbox are provably the bytes that were signed. A permission that the manifest did not declare cannot be granted, and a buyer's choice can only narrow what was declared, never widen it.
The marketplace is not open to third-party packs. It will not open until the sandbox's remaining behaviour has been measured in the shipped application rather than reasoned about.
6. Revocation
A published pack can be withdrawn. Withdrawal is recorded in a ledger that is only ever appended to, so a pack pulled on one day and restored on another leaves two records rather than none, each naming who acted and why.
A withdrawn pack is refused at download, disappears from the store catalogue, and is refused by an installed copy from its own local record, without a network connection, on every launch. This is the one place in CoLateral that fails closed. Everywhere else, an unreachable server leaves the workspace working, because software that hides an engineer's work when a server is down is broken rather than secure.
7. Payments
Payments are processed by Stripe. Card numbers are never sent to, handled by, or stored by CoLateral. Every write triggered by a payment event is keyed so that a retried delivery cannot create a second license or a second ledger entry, and refunds are issued through a single path that keeps the payment processor and our own ledger in agreement.
8. Encryption
Everything served over the public internet, including the website, the backend, and installer downloads, is served over TLS only. Data stored by the backend, by the object store that holds installers and packs, and by the payment processor is encrypted at rest by those providers. License keys, download tokens, and creator API tokens are additionally stored only as hashes, so a copy of the database grants nobody the ability to activate or download anything.
Installer downloads are handed out as links that are minted for one request and expire in minutes. The storage bucket behind them is not publicly readable.
9. Access and operations
CoLateral is operated by one person. Administrative access to the backend, the payment processor, the domain, and the source repository is held by that person alone, under multi-factor authentication where the provider offers it. Administrative endpoints require a bearer token compared in constant time; every administrative action that changes stored state writes an audit record naming the actor and the time. Publishing a pack to the store cannot be done by an automated reviewer at all, structurally, because that step puts third-party code on customers' machines.
Source is mirrored to a second location nightly and the whole test suite is re-run against it, so a failure is noticed the next morning rather than at the next release.
10. Your data, and deleting it
What CoLateral holds about a customer is described in the Privacy Policy: an email address, an optional name, the record of the purchase, and any review text written about a pack.
A request to delete personal information is honoured by redaction: the address, the name, and any device name are removed, and the financial record of the sale is kept, because accounting records must be retained under Canadian tax law and a ledger a customer can edit is not a ledger. The retained rows carry no name and no address after the redaction. Requests go to support@colateral.engineering.
11. Certification
CoLateral has not been audited against SOC 2 and is not certified to ISO 27001. Both require an independent examiner and evidence of controls operating over time, and neither has been engaged. The controls described on this page are real and are tested in the repository; describing them is not the same as an audit, and this page will not say otherwise until one has happened.
12. Contact
Security reports: security@colateral.engineering
Everything else: support@colateral.engineering or the contact form.