Why Office Unbound · Security & transparency
Security you can inspect.
Updates you decide on.
Office Unbound intends to make its security claims checkable: public source, a published inventory of every component, a record of how each release was built, advisories when something is wrong, and update control in the hands of the people who run the platform.
Project status These are commitments for how the project will work once code and releases exist. No repository, build pipeline or release has been published yet, and no independent review has taken place.
Open source is not a security guarantee
It is a precondition for verification, which is a different thing.
Publishing source code does not make it secure. Open-source software has serious vulnerabilities like any other, and some projects with very wide use have had too few people reading their code. The backdoor discovered in the xz compression library in 2024 was introduced into a public project and caught by a single engineer who noticed a performance anomaly. Openness made the discovery possible; it did not prevent the attack.
What openness does is change who can check. With a proprietary platform, a customer’s view of security is the vendor’s documentation, its audit reports and its contract. With an open platform, the customer, their MSP, a consultant they hire or an independent researcher can read the code, rebuild it, compare the result with what was shipped and look up every dependency. That only helps if the project makes checking practical — which is what the rest of this page is about.
Microsoft and Google invest heavily in security and operate it at a scale no small project can match. Office Unbound is not claiming to be more secure than either. It is designed to be verifiable, and to leave the operational security decisions — when to patch, how to segment the network, who holds the keys — with the organization that bears the risk.
What the project intends to publish
Source transparency as a set of concrete artifacts, each one something an evaluator can retrieve and check. All are planned; none exists yet.
- Available Available and verified in a release
- In development Being built now
- Planned In the roadmap, not yet started
- Under evaluation Being assessed; not yet selected
| Capability | What it means | Status |
|---|---|---|
| Public source code | The source of Office Unbound’s own components — provisioning, administration, migration, the unified interface — in a public repository, with its history. | Planned |
| Inspectable dependencies | Every upstream project and library pinned to a specific version, so an evaluator can see exactly what is included and look it up. | Planned |
| Software bills of materials | A machine-readable SBOM for each release, in a standard format, listing every component, version and license. | Planned |
| Component inventories | A human-readable list of which upstream projects each service is built on, and which versions a given release ships. | Planned |
| Build provenance | A signed record of how each release artifact was produced: the source revision, build environment and steps, so a binary can be traced back to its source. | Planned |
| Release documentation | Notes for every release describing changes, security fixes, upgrade steps, known issues and anything that needs administrator action. | Planned |
| Vulnerability advisories | Published advisories for vulnerabilities in Office Unbound and in bundled upstream components, with severity, affected versions and remediation. | Planned |
| Security scanning | Automated scanning of code, dependencies and container or VM images on every change, with results feeding release decisions. | Planned |
| Independent security review | Review by parties outside the core team, commissioned or community-led, with findings and fixes published once remediated. | Planned |
| Transparent update history | A permanent public record of every release and advisory, so an operator can see what changed between any two versions. | Planned |
What these artifacts are for
Each one answers a question a security team asks before approving software.
- “What is actually in this release?”
- The SBOM. When a vulnerability is announced in a widely used library, an operator should be able to search the SBOMs of the releases they run and know within minutes whether they are affected, instead of waiting for a vendor statement. Established formats such as SPDX and CycloneDX exist for this; the choice of format is part of Phase 1.
- “Was this built from that source?”
- Build provenance. A signed provenance record ties an artifact to the exact source revision and build process that produced it, so tampering between source and release becomes detectable. Industry frameworks such as SLSA describe levels of assurance; the project will state which practices it meets rather than claim a level it has not reached.
- “Is anything known to be wrong with it?”
- Advisories. Each advisory is intended to state the affected versions and components, severity, whether exploitation is known, available workarounds and the fixed version — enough for an administrator to make a decision without reading the code.
- “What did the last update change?”
- Release documentation and the update history. Operators who stage and approve updates need to know what they are approving, including changes to defaults and anything that touches authentication or data storage.
- “Has anyone else looked?”
- Independent review. A project cannot credibly review itself. The intention is to seek outside review of the most sensitive parts — authentication, tenant isolation, administration APIs — and to publish what was reviewed, by whom and what was found, once fixed.
Customer-controlled updates
Cloud platforms update themselves. Office Unbound is designed so the operator — the customer’s IT team or their MSP — decides when a release reaches production, with an expedited path for critical fixes.
The planned update workflow
Notification
Operators are told a release exists, what it contains and whether it carries security fixes, with a link to the advisory.
Staging
The release is applied to a staging environment that mirrors production, and tested against the organization’s own workflows.
Approval
An administrator, or an MSP policy, approves it for a maintenance window. The approval is logged.
Production and rollback planning
The update is applied with a backup and a documented rollback plan held until the result is verified.
MSP-controlled update policies
An MSP running many customers needs policy, not a checklist per tenant. The design includes update rings — a few customers first, the rest after — maintenance windows per customer, and a maximum deferral period after which a security release is applied unless someone explicitly holds it and records why.
Rollback is planned for, not promised. Some updates change database schemas or data formats, and reversing them means restoring from backup. Release notes are intended to say when that is the case.
The risk of waiting
Control over updates is also control over exposure.
Every day a known vulnerability stays unpatched is a day an attacker can use it, and published advisories are read by attackers as closely as by defenders. Customer-controlled updates move that risk from the vendor to the operator. That is the honest cost of the control this platform offers.
For that reason the update design treats security releases differently from feature releases. Feature releases can wait for a convenient window. Security releases are intended to arrive with a severity rating and a plain statement of exposure — is the vulnerable component reachable from the internet, is exploitation known — and the platform is intended to show administrators how long each tenant has been running a version with an open advisory.
- Deferring a feature release is a scheduling decision.
- Deferring a critical security release on an internet-facing service is a risk acceptance, and should be recorded as one.
- An emergency path that skips extended staging exists so that urgency does not become a reason to skip approval and logging altogether.
Security verification practices
The checks the development process is being designed around. They are practices for a codebase that does not yet exist, so each is planned.
Code scanning
Static analysis on every change for injection, unsafe deserialization, weak cryptography and similar classes of bug. Planned
Dependency checks
Every pinned dependency checked against vulnerability databases on each build and on a schedule, so new advisories against old releases are noticed. Planned
Secret detection
Commits and build output scanned for credentials, keys and tokens before they can reach the public repository. Planned
Vulnerability scanning
Release images and deployed services scanned for known vulnerabilities and insecure configuration. Planned
Authorization testing
Tests that every administrative and user action checks roles and scopes — including the ones that are easy to forget, such as exports and bulk operations. Planned
Tenant-isolation testing
Automated cross-tenant tests run on every release; see below. Planned
Regression testing
Every fixed vulnerability gets a test that fails if the bug returns. Planned
Audit logging
Administrative and security-relevant actions logged in a form operators can retain and review. Planned
Security disclosure
A published process for reporting vulnerabilities privately and handling them in coordination with reporters. Planned
Tenant isolation, tested
For MSP deployments, the boundary between customers is the most important security property in the platform.
An MSP hosting forty businesses on one platform is making a promise to each of them that the other thirty-nine cannot see their mail. Office Unbound is being designed with tenant-specific authorization at every layer — identity, APIs, storage, search, administration — and with administrative boundaries so that a technician scoped to one customer cannot act on another.
Designing for isolation is not the same as achieving it, so the plan is to test it continuously. A cross-tenant test suite creates paired tenants and, for every API and every administrative action, attempts to reach the other tenant’s users, mailboxes, files, chat rooms and audit logs using the first tenant’s credentials and roles. Search, sharing links, file previews and export jobs get particular attention, because they are where isolation bugs tend to hide. Any cross-tenant access is a release-blocking failure.
Resource separation is part of the same design: per-tenant quotas so one customer cannot exhaust shared capacity, and the option for an MSP to place a sensitive customer on separate virtual machines entirely.
Reporting a vulnerability
A coordinated disclosure policy will be published alongside the source repository: how to report privately, what reporters can expect in acknowledgment and updates, how fixes and advisories are coordinated, and how reporters are credited.
There is no code to report against yet. Until the repository and its security policy are published, questions about the project’s security approach can be sent through the contact form. The community page will carry the disclosure process when it exists.
Office Unbound holds no security certification and has completed no security audit or penetration test. It makes no claim of SOC 2, ISO 27001, HIPAA or any other compliance status. Certifications apply to organizations and their operations, so an organization running Office Unbound would need to establish its own compliance; the platform intends to provide controls — retention, audit trails, access controls, data export, administrative reporting — that support that work, not replace it.
Reviewing Office Unbound for security?
Tell us what your security team would need to see before approving a platform like this. It shapes what the project publishes first.