Configuration & Change Management

Policy · v2026.06 · Owner: Engineering Lead / Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30

1. Purpose & scope

This policy applies to every production change Bioscope Foundry makes, to the cloud environment that hosts conductor and Foundry’s FHIR service, to the macOS launchd + Nix deployments that run foundry-master-agent and the Maverick OpenClaw, to the Cloudflare Workers deployments that serve the marketing surfaces, and to the access-control, feature-flag, and network configurations that surround them. The intent is to ensure every change is traceable, reviewed by someone other than the author, tested, and reversible.

2. Policy statements

Bioscope Foundry policy requires that:

(a) All production changes, including software deployments, feature-flag enablement, infrastructure changes, network changes, and access-control updates, must go through an approved change-management process.

(b) Each production change must maintain complete traceability documenting the request, the requester, the date and time, the actions taken, and the result. The system of record is Linear (the production-change tracker) and GitHub (the merging pull request).

(c) Each production change must be tested before implementation. Testing includes, at minimum, usability, security, and impact testing appropriate to the change.

(d) Each production change must include a rollback plan that the on-call operator can execute without further design work.

(e) Each production change must be approved.

• Approvers are determined by change type. PHI-adjacent changes require Security review.
• Approvers must be someone other than the author or executor of the change.
• Auto-approval is permitted only for pre-approved categories (e.g., routine dependency upgrades that pass the standard gate); each auto-approval rule is documented and signed off by the Security Officer in advance.

(f) Configuration drift must be detectable. Infrastructure is managed as code; out-of-band changes are minimized and reconciled back into source promptly.

3. Configuration management processes

1. Configuration is automated. cloud infrastructure is managed with Terraform (or Pulumi in the repos where Pulumi has been adopted). The agent runtime is managed with Nix flakes; macOS launchd units are declared and reproducible. Cloudflare Workers deployments are driven by Wrangler configuration committed to source.
2. All changes to production systems, networks, and security configurations are reviewed and approved by Security when they touch PHI flow, authentication, authorization, firewall rules, IAM, encryption keys, or network perimeter controls.
3. All production changes are tested before implementation: at minimum via the terraform plan, pulumi preview, or nix flake check --impure output reviewed in the PR. For application code, the full CI gate (pnpm check / cargo test --workspace) must pass.
4. Implementation is performed by authorized personnel. The set of humans able to apply a change to production is documented in the Access Policy.
5. Inventory is automated. System inventories are generated from the source-of-truth IaC and from AWS / Cloudflare APIs:
   • Resources are categorized and labelled by environment (dev, staging, prod).
   • Resources are classified by the data they store or process per the Foundry data-classification model (see Data Management).
   • The Security function maintains automation that monitors all changes to production assets and produces inventory diffs for review.
   • Asset inventory drives the risk-assessment inputs in Risk Management.
   • Periodic manual audits reconcile the IaC inventory against the live cloud state.
6. Baselines for hardening. Foundry uses recognized baselines as the hardening reference:
   • cloud environments follow the CIS Cloud Foundation Benchmark.
   • Production container images are pinned to explicit version tags before promotion; pinning images to their content digest is a near-term roadmap item. Local development stacks may reference upstream tags for convenience but are not part of any PHI data plane.
   • The Nix flake-based runtime for foundry-master-agent provides reproducible system configuration by construction.
7. Time synchronization. Production hosts and managed endpoints sync to authoritative time sources (authoritative time servers, device vendor time servers).
8. Separation of frontend and backend. User-facing surfaces are deployed independently from data-handling services. The customer-facing conductor web app is separate from its services and from the FHIR service store.
9. Full-scale testing before promotion. Software and infrastructure changes complete the standard gate before being promoted to production.
10. Code review. Static analysis (tsgo, oxlint --type-aware, knip, cargo) and human review run on every PR, see Secure SDLC §3.2.

4. Configuration monitoring & auditing

Infrastructure and configuration state is captured continuously:

• provider-side configuration and posture monitoring is being stood up as part of the security-tooling rollout; misconfigurations are alerted to Security and triaged into Linear.
• Drift between Terraform / Pulumi state and live cloud resources is reconciled at every plan. Drift outside a planned change is investigated immediately.
• Configuration auditing rules are defined against approved baselines; deviations (open ingress, public buckets, IAM expansions, encryption disabled) generate alerts.
• The cloud audit log is the system of record for control-plane changes in AWS and is reviewed by Security weekly. PHI never appears in those logs.

5. Production systems provisioning

1. Before provisioning a new production resource, a request must be opened in GitHub (PR against the IaC repo) and tracked in the production-change tracker.
2. Linear access is restricted to authenticated workforce; access is granted per Access Control.
3. The Security function must approve the provisioning request before the resource is created, unless a pre-approved automation path applies (e.g., a routine ephemeral worker in a sandboxed environment).
4. Once approved, the implementer configures the resource against the standard baseline for its role. Where the resource will store or process PHI, the encryption configuration is verified: provider-managed or customer-managed encryption keys (CMEK) at rest, TLS 1.2+ in transit.
5. Sensitive data in motion is always encrypted.
6. Once provisioned, a security analysis is performed: automated configuration / vulnerability scans or manual inspection by Security. Verifications include, without limitation:
   • removal of default credentials and provisioning users;
   • network configuration (no unintended public exposure);
   • encryption settings on data volumes and buckets;
   • monitoring agents installed where applicable;
   • IAM bindings minimized to least privilege.
7. Resources are fully promoted to production only after verification against Foundry’s standards and the change request is approved.

6. Endpoint configuration controls

Workforce endpoints, primarily macOS (Apple Silicon), are configured either manually by IT or the owner, or automatically through the MDM platform. The following baseline applies at minimum:

• full-disk encryption (FileVault) enabled;
• unique user accounts with strong, passwordless authentication where available;
• automatic OS and security patching enabled;
• screen-lock timeout and password protection;
• EDR / endpoint protection agent installed;
• Foundry-approved configuration profile applied (firewall on, sharing off, remote management restricted).

Endpoint configuration is inspected by Security via the MDM console, manually as needed, automatically via continuous compliance checks. See Endpoint & MDM for the full standard.

7. Server & service hardening

7.1 provider-managed compute

Production workloads run primarily on provider-managed compute (Amazon ECS container services and Lambda functions, selection depends on the workload). Hardening derives from the CIS Cloud Foundation Benchmark plus Foundry-specific controls:

• production container images pinned to explicit version tags before promotion, with content-digest pinning on the near-term roadmap;
• workload identity used in preference to service-account keys;
• service-to-service traffic mutually authenticated;
• egress from the PHI-handling account restricted by network perimeter controls;
• logging configured per System Audits & Monitoring.

7.2 Nix + macOS launchd (agent runtime)

The Maverick OpenClaw deployment in agents/ and parts of foundry-master-agent run on macOS Apple Silicon under launchd, configured by Nix + Home Manager. Hardening derives from the reproducibility of the Nix flake itself: the system configuration is checked into source, nix flake check --impure runs after every flake change, and any drift between declared and observed configuration is detectable and reversible. PHI-eligible mounts are gated by the agent’s mount-security checks (Tier-4 Moltworkers cannot hold PHI by construction).

7.3 Windows

Foundry does not run Windows systems in its production environment or as standard workforce endpoints. Any future introduction of Windows would require a security review and the addition of a Windows-specific hardening standard to this policy.

8. Network controls

Network controls on sensitive segments are configured such that:

• vendor defaults are modified securely: default credentials rotated, default SNMP / management strings changed, default keys regenerated;
• credentials and keys are rotated when a person with knowledge of them leaves or changes role;
• traffic filtering and inspection (firewall rules, cloud-provider WAF and DDoS protections, VPC flow logs) are enabled;
• an up-to-date network and data-flow diagram is maintained as part of Foundry’s internal architecture documentation;
• AWS network controls are implemented as VPCs, subnets, security groups, and firewall rules, all managed in source, all changes following the standard PR and change-management path.

9. cloud environment structure

Foundry uses AWS Organizations with separate accounts for management and for workloads. PHI-handling workloads run in a dedicated production account behind network perimeter controls. Identity is federated through Foundry’s identity provider; engineers assume IAM roles in target accounts through role bindings managed in IaC. Non-production accounts hold synthetic data only; production PHI is never copied to lower environments.

Exact account layout is documented in an internal infrastructure runbook and is reviewed in the Risk Management cycle.

10. Change management for deploys

The continuous-delivery pipeline (GitHub Actions, pinned to commit SHAs) automates change-request creation and approval gating. Deploys follow a three-step process:

1. Create change request. When a deploy to a controlled environment is requested, the workflow opens (or updates) a Linear change-management ticket in the production-change tracker, populated from PR metadata and user input.
2. Obtain approval. Slack notifies potential approvers. Approvers review the ticket, summary, components, justification, rollback plan, links to the PR and Linear issue, and approve or reject. Approvers are someone other than the author or executor.
3. Detect risky changes, deploy, close. The workflow proceeds only against an approved ticket.
   • A terraform plan (or pulumi preview) runs first to surface risky changes.
   • Categories that count as “risky” include changes to IAM policies, KMS key policies, bucket policies, firewall and network perimeter rules, security groups, and any deletion in a production account. These categories require explicit Security approval.
   • On completion (success or failure), the Linear ticket is updated with the result and closed.

11. Patch management

11.1 Workforce endpoints

Foundry requires automatic security patching to be enabled on all workforce endpoints. Patch state is inspected via the MDM console; endpoints out of compliance are remediated or removed from production access until they catch up.

11.2 Cloud workloads

Foundry follows a cattle-not-pets approach in the cloud:

• managed serverless compute and managed functions workloads are rebuilt and redeployed on every deploy and CI run; base images and dependencies are refreshed as part of each rebuild.
• A scheduled rebuild cadence, to pick up upstream security patches in base layers between deploys, is being established.
• Dependency updates run on a scheduled manual review cadence, with the Foundry 7-day cooldown (minimumReleaseAge / --min-age 7) honored to reduce exposure to short-lived malicious releases; automated dependency-update tooling is being rolled out. Patches that close Critical / High findings can override the cooldown with Security Officer approval.
• provider-managed services (Foundry’s FHIR service, a managed relational database, etc.) are patched by the cloud provider under the shared-responsibility model; Foundry monitors provider security bulletins and applies any required customer-side actions on the SLA in Vulnerability Management.

11.3 Agent runtime

The Nix flake for foundry-master-agent pins all inputs. Patches arrive as flake-input bumps in PRs that run nix flake check --impure and the full Rust test suite before merge. Production hosts pull the new generation via the standard deploy path; the previous generation is preserved for rollback.

12. Production deploy / code promotion processes

To promote changes to production, a valid and approved change request is required. The change request, typically a Linear ticket linked to a merged PR, captures, at minimum:

• summary of the change;
• impacted components;
• justification;
• rollback plan;
• links to the relevant pull request(s) and Linear issue(s).

For code deploys, additional fields are recorded:

• build job name and run ID;
• deploy action (plan / apply);
• deploy branch;
• target environment (e.g., foundry-prod, conductor-services-prod).

At least one approval from someone other than the author is required for each change request, and required CI status checks must be green at the commit being promoted. Branch protection on main enforces this at the GitHub level.

13. Emergency change

When an emergency arises, a zero-day affecting a production dependency, a live incident requiring immediate mitigation, a recovery from an outage, and the standard change-management path cannot be followed without unacceptable delay, the emergency-change process applies.

• Notification. The Engineering Lead and Security Officer must be notified before the change by Slack, phone, or both. Depending on the nature of the emergency, executive leadership and/or affected practices may also be informed.
• Access & execution. The change is made using one of the documented break-glass mechanisms in Access Control: support / troubleshooting access, root-account access where strictly necessary, or local system access. Every use of a break-glass mechanism is logged.
• Post-emergency documentation. A production-change ticket must be created within 24 hours of the emergency change, capturing:
  • the reason for the emergency change;
  • the access mechanism used;
  • the steps taken and the change made;
  • the standard-process sign-offs that would have been required, recorded retroactively.
• Prevention & improvement. Security and Engineering jointly review the emergency change and the conditions that necessitated it. Process improvements or preventive controls are recorded as Linear issues and tracked to completion.

14. Roles & responsibilities

• Security Officer: owns this policy, approves Security-sensitive changes and auto-approval rules, and chairs the emergency-change review.
• Engineering Lead: owns the deploy pipeline, approves engineering-side changes, and assigns the on-call rotation.
• Repository / system owners: approve changes within their domain and ensure rollback plans are realistic.
• All engineers: open changes via PR; never apply changes to production outside the documented process unless the emergency-change path applies.

15. Review & revision

This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale, including changes to the cloud organization layout, to the IaC tooling, or to the auto-approval rule set. Material revisions are approved by the Security Officer in coordination with the Policy Management process.

16. Related policies

• Secure SDLC & Product Security
• Vulnerability Management
• Threat Detection & Prevention
• Incident Response
• Access Control
• Endpoint & MDM
• System Audits & Monitoring
• HIPAA Notice & Business Associate Statement