Secure Development Framework
This page describes the target development framework for building, delivering and operating
software inside a client's own environment: how production and development are separated, what
connects them, and where the security boundary runs. It is written to be shared with any client in
any industry.
The framework rests on four rules:
Original data never leaves the client environment. It lives in the client's production memex,
inside the client's own cloud subscription, and people reach it only through memex, by their role.
No human has access to the production cluster. Deployment and configuration run through a
source-control App and its pipelines under the memex system identity; merges, deployments and
script runs are approved by a client employee on a documented request.
Only two things cross the ringfence: compiled binaries from the public App Store, and people
logging in with an identity issued by the client.
The consultant works on anonymised generic data only , in a separate interface environment with
the same structures and no original records.
The reference stack is an enterprise identity provider, a managed Kubernetes service and a hosted
source-control tenant; the same roles map onto any equivalent.
Target development framework: secure production and development
Reference architecture
Client environment
ringfenced: every access via the client identity provider
memex (production) on Kubernetes
Original data
Access: client users only, via memex, by role
Data operations
anything touching original data runs as an approved
script executed by memex, logged and reproducible
App Store (lives in this memex)
binaries from the public registry; the project module
from the project repository; no source code enters
AI on original data: memex harness with approved models only
Client employee
approves merge, deploy and script runs on a fully
documented request (what, why); runs scripts and
inspects project data; the counterpart for everything
that requires client hands
Access and data boundary: security relevant
No human has access to the cluster: only the source-control
App, run by the memex system identity.
People reach data via memex only, by their role.
Original data never leaves this environment; content goes
only to security-approved models inside it.
The vendor only ever gets anonymised generic data.
Client identity provider
secures memex, the cluster and the source-control tenant
memex system identity: enterprise app in this tenant
step 2: this set-up is rebuilt here, one instance first;
the client provides the domain name and the certificate
Interface
what connects the two environments, and nothing else
The public registry instance
the source of all binaries
the only place where the platform, all modules
and plugins can be seen; compiles the sources and
distributes the binaries; the App Store of every memex
downloads its packages from here
only compiled packages, never source code, no client data:
not security relevant
Client source-control tenant
belongs to the client, secured by the client identity provider
Project repository
the project plugin sources of the client memex;
pull requests and issues of the project;
merge and deploy approved by a client employee
Source-control App and pipelines
the App is run by the memex system identity;
the pipelines apply the chart and the cluster configuration
no human access to the cluster
Access
client identity provider only; vendor staff use dedicated
client accounts for the project-relevant services
no system connection to the vendor environment
Interface memex: the vendor's test environment
vendor subscription and tenant; cost billed to the client
Anonymised generic data
same structures, no original records; any coding tools;
reproduce issues, test, load-test and verify fixes
Access: the vendor ยท not security relevant
step 1: the plain set-up, no data at all; syncs project sources
with the client tenant; installs from the App Store
Vendor environment (consultant)
no client data, ever: not security relevant
Platform, modules and plugins
vendor source-control tenant
the platform
plugins repository: the project-relevant plugins
domain repositories: the industry-specific modules
relevant modules agreed per project
visible to the client only through the public registry,
as binaries in the App Store
the source code stays here
licensing per the licence agreement
Vendor development
own instance, own subscriptions (AI coding agents)
holds no client data at all
How the vendor works on the project
platform and plugin work is committed here;
project work happens in the Interface memex (vendor
identity) and in the client tenant (dedicated client
account), as pull requests
nothing is pushed into the client environment from here
Principle
Vendor employees have no contact
with production data.
Costs
the vendor carries only its AI coding-agent subscriptions;
the Interface memex subscription and all other project-related
services on vendor tenants are passed through to the client;
everything in the client environment is the client's cost
Client ringfence
publish
App Store
binaries
deploy
issues
Project sources: pull and push
commits
vendor staff
No system connection between the vendor environment and the client environment. Security relevance stops at the client ringfence.
The only crossings: compiled binaries from the public registry, and people logging in with a client identity.