Security

In transit. All connections to our websites, the account portal, the terminal session layer and the file transfer endpoints require TLS 1.2 or higher, with TLS 1.3 preferred and modern cipher suites only. Plaintext HTTP redirects to HTTPS, and HTTP Strict Transport Security is enabled.

Administrative access to hosts is over SSH with key-based authentication. Password authentication for shell access is disabled. We do not expose unencrypted terminal protocols to the internet — if your users reach the system over a terminal today, that session is tunnelled inside TLS or SSH by the time it leaves your network.

At rest. Every volume holding customer programs, data files, backups or logs is encrypted with AES-256 using our infrastructure provider's managed key service. Keys are held in the provider's key management service, rotated on the provider's schedule, and never checked into source control or stored on a workstation.

Backups are encrypted with their own keys, separate from the live volumes, and stored in a separate account boundary.

Honest limit. The Runtime must read your data files in cleartext to execute your programs against them — that is what an interpreter does. Encryption at rest protects the storage layer; it cannot protect against someone with legitimate execution access inside your environment. That is why sections 4, 5 and 6 matter more than this one. Any vendor telling you that at-rest encryption solves this problem has not thought about it.

One environment per customer. Each customer gets their own compute instance or instances, their own storage volumes and their own network segment. We do not run multiple customers' programs inside one shared application process, and we do not put multiple customers' files on one shared filesystem.

The Service is cloud-only — every environment runs on our infrastructure, operated by us. There is no self-hosted edition, which means there is no version of this page where a control is somebody else's job. Isolation, access control, backups and recovery are ours to get right, and ours to answer for.

There is no shared database that contains more than one customer's business data. There is no multi-tenant table with a customer identifier column that a missing WHERE clause could leak across. The isolation is at the infrastructure boundary, not in application logic — which means a bug in our code cannot hand your customer master to somebody else.

Network. Environments have no route to each other. Security groups deny by default, and only the ports required for your sessions and our administrative access are open. Nothing in your environment can initiate a connection to another tenant's environment because no path exists.

Operating system. Your Runtime processes run under a dedicated, non-privileged OS account scoped to your data directories. The Runtime executes Business Basic programs; it is not a shell. Its file and process operations are confined to the paths your environment owns.

Session isolation. Each user session is its own operating-system process. Sessions do not share an address space, and two users have nothing in common except the data files their programs open — which the operating system arbitrates, using the same record-locking protocol your current runtime uses. One user's session cannot read or corrupt another’s, because there is no shared structure between them to reach through.

It also means a session that dies — a dropped link, a wedged terminal, a laptop closed at 4:55 — is cleaned up by the operating system, which reclaims its memory, file descriptors and record locks. There is no application-level reaper that could get it wrong and no reason to restart anybody else. This is the architecture, not a stage we are passing through.

Non-production environments never contain live customer data unless you explicitly ask us to mirror your production files for a parallel run — and where we do that, the mirror is provisioned inside your environment boundary, under the same isolation and the same encryption as production. It is never staged in a shared or internal workspace of ours.

Named accounts only. Every member of our team has an individual identity. There are no shared administrative logins and no shared SSH keys. Multi-factor authentication is mandatory on every account that can reach production, on our identity provider, our source control and our cloud console.

Least privilege. Production access is granted by role, limited to the people whose job requires it, and reviewed quarterly. Engineers who do not operate the hosted service do not have production credentials. Sales and finance never do.

Path. Administrative access to customer environments goes through an authenticated bastion. Sessions are logged with the identity, the environment, the time and the commands run. Direct access from personal devices or from outside that path is not permitted.

Break-glass. There is one emergency credential per environment, held in a managed secret store, retrievable only with a second person's approval. Its use raises an alert to the whole team and requires a written explanation within 24 hours. It has never been used silently and it cannot be.

Offboarding. Access is revoked on the last working day, as a checklist item that is signed off, not as an intention. Keys and tokens that person held are rotated.

Customer-side access. You control your own users. We support individual accounts, and we will help you turn off the shared logins your current system has probably accumulated. We will not create an account in your environment for a person you have not authorized, no matter who asks or how urgent they say it is.

Who. A named group of engineers on the hosted-service team. It is a small group and we will tell you its size and its names under NDA if you ask during evaluation. Nobody outside it can reach a customer environment.

When. Only for one of these four reasons:

• Provisioning and migration you asked for — moving your programs and files, running the parallel-run comparison, cutting you over.
• A support request you opened — and only into the area of the system your request concerns.
• An incident affecting the availability or integrity of your environment, where we have to act to keep you running.
• Legal compulsion — a valid subpoena or court order, where we will notify you first and give you the chance to challenge it, unless we are legally prohibited from telling you.

Never for. Product development, market research, competitive analysis, model training, marketing, curiosity, or a demo. Those are contractual prohibitions in Terms section 9.3, not just policy on a page.

Logged. Every administrative session against your environment is logged with who, when, and what. We will provide you with that access log on request, for any period in the last 13 months. Most vendors will not do this. Ask us for it during your evaluation and see whether we deliver.

Where we can, we look at less. When we debug, we work from error output, program source and record structure before we look at record contents. We do not copy production data to a workstation, and we do not paste it into third-party tools.

Honest limit. An engineer with root on the host running your environment can, in principle, read anything on it. That is true of every hosting arrangement that has ever existed, including your closet. What differs is how few people that is, whether it is logged, whether they are contractually bound, and whether the vendor will tell you the truth about it. Our answers: a handful, yes, yes, and this page.

Schedule. A full encrypted snapshot of each customer environment nightly, plus a snapshot immediately before any change we make to your environment — a Runtime upgrade, an OS patch, a migration step.

Retention. Nightly snapshots are kept for 30 days. One snapshot per week is promoted and kept for 90 days. Backups taken before a change are kept for 30 days after that change.

Separation. Backups live in a separate storage account with separate credentials and their own encryption keys, so that compromise of a production host does not by itself give an attacker the ability to destroy your history.

Restore testing. We perform a full restore of a representative environment at least quarterly and verify that the restored system starts, signs on, and reads its files. An untested backup is a rumour; we treat it as one.

Your copy. Under Terms section 16.4 you can ask for a complete copy of your programs and data files at any time, up to four times a year, at no charge, delivered within 10 business days — in their native on-disk format, never converted or re-encoded into something only we can read. Keep your own copy. We would rather you had one than trusted ours.

Deletion of customer content follows the schedule in Terms section 15: gone from live systems within 30 days of the export window closing, and aged out of backups within 90 days of that.

Objectives. For a total loss of an environment, our current targets are a recovery point of 24 hours (the last nightly snapshot) and a recovery time of 8 hours to a working, signed-on system in another availability zone.

How. Environments are defined in infrastructure-as-code and rebuilt from that definition plus the latest snapshot. We do not rebuild from anyone's memory or from a runbook that was accurate last year.

Honest note. Those are targets we have measured in exercise, not a contractual SLA. During pre-GA we do not run hot standbys, so a zone failure means a restore, not a failover. If your business needs a tighter recovery point or a warm standby, we can build it — it is a paid option, it goes in your Order with numbers attached, and we will not pretend it is included when it is not.

Company continuity. The Runtime also runs Unique Photo's own operations. Our incentive to keep it recoverable is not contractual, it is that our warehouse stops shipping too.

If we ever wind down the Service, Terms section 16.5 commits us to 180 days' notice, continued operation through that period, and free transition assistance.

The free report asks for an archive of your programs only. Do not include data files. If we find data files in an upload, we delete them and tell you.

Transport and storage. Uploaded over TLS, written straight to an encrypted object store in a dedicated bucket with no public access, keyed to your request. Never to a laptop, never to a shared drive, never to email.

Processing. The archive is parsed by an isolated worker that performs static analysis only — we do not execute your programs. The worker has no outbound network access, so your source cannot leave it, deliberately or otherwise.

Access. Limited to the engineers producing your report and answering your questions about it. Not to sales. Not to anyone else, ever.

Deletion. The archive, the extracted source and every derivative are deleted within 90 days of upload — or immediately, on request to hello@uniquebb.com, and we will confirm in writing.

What survives. Only anonymous aggregate counts of language features — how often a verb or a file type appears across all reports — with no code, no identifiers and no company name. It is how we decide what to build next.

If you would rather not upload anything until there is paper in place, say so — we will sign a mutual NDA before you send a single file, and we will delete the archive the moment the report is delivered rather than waiting out the 90 days. Ask.

Our entire third-party supply chain is five packages. Not five direct dependencies with a tree underneath them — five, resolved, in total: libc, num-bigint, num-integer, num-traits, and one build-time helper that never reaches the shipped binary. Four packages are compiled in; the fifth runs only on our build machine.

A reviewer on your team can read that supply chain in an afternoon and be finished with it. The enterprise application you assessed last quarter almost certainly resolved to several hundred transitive packages from several hundred authors — and every one of those is an entry in somebody's vulnerability feed, a version to chase on a Friday, and an author whose account you are trusting. We are not claiming five packages makes us secure. We are claiming it makes us reviewable, which is the thing you were actually asked to do.

We wrote the parts most vendors import. The HTTP server, the WebSocket layer, the JSON encoder and parser, SHA-1, base64 and the pattern matcher are ours, written for this product rather than pulled off a public registry.

That is a deliberate trade and it cuts both ways. It is more code we own and are answerable for. It is also far fewer moving parts we do not control: no web framework, no async runtime, no serialization library, and therefore no advisory in any of them that stops your month-end while we wait for an upstream maintainer to cut a release, and then for our own rebuild to follow it. When a defect is in our code, the fix is ours to make the day we hear about it.

There is no virtual machine underneath. The Runtime is a single native binary. Nothing is installed beneath it that carries its own quarterly advisory cycle — which, in most of the questionnaires we answer, is the component the questions are really about. Our previous engine was written in Java and needed a virtual machine of roughly 306 MB just to start. The Rust engine that replaced it is 3.4 MB, about 90 times smaller, and the whole platform, engine plus browser terminal, is 4.4 MB. Those are same-workload figures, each in its default configuration.

Operationally that means an upgrade is one file replaced atomically, preceded by the snapshot described in section 7 and reversible by restarting the previous build (13.6). There is no second runtime to patch, and no version matrix between the two to reason about at two in the morning.

Memory safety, stated precisely. The Runtime is written in Rust. Whole categories of vulnerability — buffer overruns, use-after-free, data races between threads — are prevented by the compiler in ordinary code, rather than left to review and hope.

Rust also allows explicitly marked blocks where those guarantees are suspended. We have about a hundred of them, and nearly all are direct operating-system calls: reading a descriptor, taking a record lock, sizing a terminal, where the kernel's own interface is the only way through. The few that are not system calls carry a written note in the source, next to the code, stating what has to hold for them to be sound.

We are not telling you the Runtime contains no unsafe code. Any program that talks to a kernel does. We are telling you the number is small enough to list, and we will send you the list for the build you are running on request.

What proves it behaves. More than 2,200 automated tests gate every release, and nearly half of the source is test code.

Beyond that, correctness is checked by comparison: the harness runs the same programs on two engines and compares the output byte for byte. We use it against the runtime you license today, and we used it on our own rewrite. When the Rust engine replaced our Java one, all seven benchmark programs produced identical bytes on two independent runs, with zero mismatches. A build that changes what your programs print does not ship.

Honest limit. None of this says the Runtime has no bugs. Memory safety removes a category of vulnerability; it does not remove logic errors, and a logic error in an ERP is still an incident. A small dependency count reduces how much unreviewed code you inherit; it does not review the code we wrote ourselves. And no outside party has assessed any of it yet — see section 2.

Five packages and a short, listed set of unsafe blocks do not add up to a guarantee. They add up to a review you can actually finish, with a scope you can state to your own management.

What you can ask us for. The dependency list with versions, the list of unsafe blocks with their notes, and the test and byte-comparison output. Write to security@uniquebb.com and we will send them. There is nothing on that list we would rather you did not read.

Patching cadence. Operating system and package updates are applied monthly to every host. Vulnerabilities that are rated critical, or that are known to be actively exploited, are patched within 72 hours of a fix being available — sooner if the exposure warrants it.

Dependencies. The Runtime links four third-party packages at runtime. That is a list short enough to review by reading it, and we do — we do not rely on a scanner to tell us what is in a set of four. A build with a known critical vulnerability in a runtime dependency does not ship. Host images are patched and rebuilt on a scheduled cycle, and the Runtime itself is a single binary replaced atomically, so an update is a file swap rather than a package upgrade with its own dependency graph.

Surface. Environments expose only the ports required to serve your sessions. Management interfaces are not internet-facing. Unused services are removed from the image rather than firewalled off.

Change windows. Patches that require a restart of your environment are scheduled with you. We do not bounce a distributor's ERP at 2pm on a Tuesday because a scanner turned amber.

Honest note. We do not currently run a paid bug bounty. We do read and act on every report sent to security@uniquebb.com — see section 15.

We maintain a written incident response plan with defined roles: an incident lead who runs the response, a communications owner who talks to affected customers, and a scribe who keeps the timeline. The plan is exercised, not filed.

Sequence. Detect, contain, preserve evidence, eradicate, recover, notify, review. Containment does not wait for a full diagnosis.

Notification — the commitment. If we confirm a security incident that affects your customer content or your personal data, we will notify you within 72 hours of confirming it. Not 72 hours after we finish investigating; 72 hours after we know you are affected.

That first notification will tell you what happened as far as we understand it, what data and which systems are involved, what we have done to contain it, what we are doing next, and what we recommend you do. If a detail is still unknown, we will say it is unknown rather than leave it out.

Post-incident report in writing within 10 business days of resolution: root cause, full timeline, impact, and the specific changes we are making so it does not recur. You may share it with your auditors and your insurer.

Where the law requires notification to a regulator or to individuals, we support you in meeting your obligations as controller, and we meet ours. See Privacy, section 12.

Review. Every change to the Runtime or the platform goes through version control and peer review. There is no direct commit to the production branch, and no editing files on a live server as a normal practice.

Environments. Development, staging and production are separate, with separate credentials. Production data is not copied into development.

Secrets. Credentials live in a managed secret store and are injected at runtime. They are not in source control, not in build logs, and not in configuration files committed to a repository.

Testing. The Runtime is validated against a conformance suite derived from real production programs — arithmetic to the penny, file operations byte-for-byte, terminal behavior measured against captured output rather than guessed. Regressions are caught by that suite before a release. The counts, and the byte-for-byte comparison against the runtime you license today, are in section 10.

Releases are versioned, changelogged and rolled out to our own production first. We run new Runtime builds against Unique Photo's live operations before they reach a customer. If a release is going to break something, it breaks our order entry first.

Rollback. Every environment upgrade is preceded by a snapshot and can be reverted. We keep the previous Runtime build available so a rollback is a restart, not a rebuild.

We do not operate a datacenter. Customer environments run in the facilities of a major cloud infrastructure provider, and we inherit their physical controls: staffed perimeters, badge and biometric access, video surveillance, environmental and fire suppression systems, redundant power, and audited media destruction. Those facilities hold their own independent certifications; ours are not implied by theirs, and we do not present them as ours.

Our offices. No customer data is stored on office equipment. Company laptops have full-disk encryption, automatic screen lock and remote wipe, and are enrolled in device management.

Customer content is never written to removable media. There are no USB backups of your data files anywhere in our organization.

Printed material containing customer information is not produced. If it ever is, it is cross-cut shredded.

Everyone with production access is an employee of Unique Photo, not an anonymous contractor pool, and is bound by written confidentiality obligations that survive their employment.

Background checks are performed for roles with production access, to the extent permitted by law.

Security training happens at onboarding and annually, and covers the things that actually get companies breached: phishing, credential handling, social engineering over the phone, and the pressure to skip a control because someone senior is in a hurry.

We will never ask you for your password, and we will never ask you to disable multi-factor authentication. If someone claiming to be from UBB asks either, it is not us — hang up and write to security@uniquebb.com.

Send it to security@uniquebb.com. Plain email is fine; we do not require encryption to receive a report, though we will happily move to an encrypted channel for details.

What we commit to: acknowledgement within 2 business days, an initial assessment within 5 business days, regular updates until it is closed, and credit in our release notes if you want it.

Safe harbor. If you research in good faith, stay within the scope below, do not access or modify data that is not yours, do not degrade the service for others, and give us reasonable time to fix the issue before disclosing it, we will not pursue legal action against you and we will say so in writing if you ask.

In scope: our public websites and the account portal. Out of scope: customer environments (they contain other companies' data — never test against one), denial-of-service and volumetric testing, social engineering of our staff or our customers, physical attacks, and findings that are purely the output of an automated scanner with no demonstrated impact.

Authorized testing. Any active security testing needs prior written authorization — see the Acceptable Use Policy. Customers may test their own environment. Ask at security@uniquebb.com, tell us the window and the source addresses, and we will normally say yes within 5 business days.

We complete security questionnaires. Send yours to security@uniquebb.com and we will return it, in your format, within 10 business days. Where the honest answer is "no", the answer will be "no" — you will not get a paragraph of evasion in the comments column.

We will get on a call with your IT team, your auditor or your insurer, and we will put anything we tell you in writing so you can hold us to it.

We will sign a mutual NDA before the detailed conversation, and a data processing addendum before we touch anything of yours. See Privacy, section 4.5.

This page is reviewed at least twice a year and whenever a control materially changes. The review date is at the top. If a control described here stops being true, we change the page — we do not quietly leave it up.