Development and supply chain
Secure development lifecycle, peer review and change control of the code. Build, artefact signing, component inventory and vulnerability management of our own code.
Nobody claims a control they do not exercise
The model is the same one any infrastructure provider uses: Opendome answers for what it operates and delivers; the customer, or the operator of the deployment, answers for what they operate. What differs is that here the split is published rather than left in a contractual annex.
Validation rule. In its policies Opendome documents and validates only the points that fall to it, and its share of the shared ones. Where the matrix does not assign a point to Opendome, no Opendome policy claims that it controls it: whose it is gets documented, and it is expressly delegated.
It is an internal rule, but it has a useful external effect: it bounds what you can audit us on and what you have to cover yourselves.
What is always Opendome's
Whatever the deployment model, these responsibilities are never delegated, because they belong to the creation of the software and to the running of the organisation itself. They are the floor of the matrix.
Licences and internal security
Compliance with the licences of the open source software that is distributed. Security of staff, of workstations and of corporate systems.
Even where a particular deployment is operated by a third party, the security of the artefact that is distributed is always Opendome's.
Fourteen control points, three models
Legend: Opendome answers for the point · Customer the customer answers · Operator the third party that deploys answers · Inherited a control delegated to the infrastructure provider and verified by Opendome.
| # | Control point | Managed | BYOC | Self-host |
|---|---|---|---|---|
| 01 | Physical security, data centre and hardware | InheritedThe provider's certification and agreement retained as evidence | Customer | Operator |
| 02 | Network and base infrastructure | Opendome | CustomerOpendome configures the encrypted tunnel | Operator |
| 03 | Operating system, cluster and its hardening | Opendome | OpendomeProvisions and hardens | Operator |
| 04 | Access plane | Opendome | Opendome | Operator |
| 05 | Platform: operation and updates | Opendome | OpendomeRemotely | Operator |
| 06 | Data isolation and governance | Opendome | Opendome | OperatorDeny by default is a property of the product and travels in the artefact |
| 07 | Encryption at rest | Opendome | OpendomeCustomerOpendome configures; the customer holds the medium | Operator |
| 08 | Data residency and sovereignty | OpendomeEU | CustomerIts infrastructure, its country | Operator |
| 09 | The customer's end users | CustomerOpendome provides the mechanism | Customer | Operator |
| 10 | Backups and data continuity | Opendome | OpendomeCustomerOpendome operates; destination, retention and residency are set by the customer | Operator |
| 11 | Logging, monitoring and detection | Opendome | OpendomeThe logs may reside on the customer's infrastructure | OperatorThe product emits the audit log; monitoring it is the operator's |
| 12 | Incident response | OpendomeLeads | OpendomeCustomerOpendome, the software and the operation; the customer, its infrastructure | OperatorOpendome maintains advisories and coordinated disclosure |
| 13 | Patching of the running deployment | Opendome | Opendome | OperatorOpendome publishes signed releases and advisories |
| 14 | Role under the GDPR | Opendome processor · customer controller | Opendome processor · customer controller | Opendome is not a processor; the operator is the controller and, where applicable, the processor |
Exactly where the boundary lies
BYOC is the model that raises the most questions, because the infrastructure belongs to the customer and the software is operated remotely by Opendome. This is the split.
Software and logical governance
The operating system and the cluster it provisions and hardens, the access plane, the operation and updating of the platform, the logical governance of the data and the configuration of encryption at rest.
Infrastructure and users
The physical security of its infrastructure, the network and the firewall of its environment, data residency and sovereignty, custody of the storage medium and the management of its end users.
Backups and incidents
Backups and incident response, where Opendome operates and the customer supplies the destination, the retention and the context of its infrastructure.
This split is documented in the agreement with each customer, as a security annex, so that both parties know their obligations before the deployment.
What Opendome maintains when it operates nothing
When a third party deploys the software on its own account, Opendome neither operates the deployment nor holds its data, and that deployment falls outside the scope of our management system. Opendome's responsibility is limited to four commitments, and it meets them.
| Artefacts | Deliver signed software, with its component inventory, of verifiable provenance. |
| Documentation | Publish hardening and secure deployment guides. |
| Vulnerabilities | Maintain the security advisory and coordinated disclosure process for the software. |
| Licences | Ensure compliance with the licences of the distributed software. |
The product's security properties — deny by default and governed consumption in particular — travel in the artefact and benefit the operator. But the secure operation of the deployment is the responsibility of whoever operates it.
Review of the split
A session with your team to determine which model fits, to review point by point what each party takes on, and to prepare the security annex to the agreement.
Request a technical meeting