Secure Software Development & Product Security

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 Bioscope Foundry product surface, primarily the conductor TypeScript monorepo (the MSO platform running on Foundry’s FHIR service), the foundry-master-agent Rust workspace (Atlas orchestrator and the Forge Agent tiers), the customer-facing web properties (marketing-website, pureethosmed-website), and the supporting CLIs and tooling repos. It governs how software is designed, written, reviewed, tested, and deployed, and how vulnerabilities discovered along the way are tracked to closure.

Security is integrated into all phases of Foundry’s product development lifecycle:

• Secure design: application risk classification, RFC-driven design review, threat modeling, data-flow analysis.
• Secure development & testing: secure coding standards, peer review, linting with security rules (oxlint --type-aware), dead-code detection (knip), open-source security analysis, static and dynamic application security testing, periodic penetration testing, a responsible-disclosure inbox.
• Remediation: every finding tracked through the Vulnerability Management process; no Critical or High finding ships to production unexcepted.

Detailed architectural and security documentation is maintained in Foundry’s internal architecture documentation.

2. Policy statements

Bioscope Foundry policy requires that:

(a) Software engineering and product development must follow security best practices. Products must be “Secure by Design” and “Secure by Default.”

(b) Quality assurance activities must be performed, including:

• Peer code reviews prior to merging into the protected main branch; and
• Thorough product testing before release (unit tests with vitest, end-to-end tests with playwright for web surfaces, cargo test --workspace for Rust, and nix flake check --impure after every flake change).

(c) Risk assessment (threat modeling) must be performed for new products and major changes to existing products that touch PHI, authentication, authorization, or production infrastructure.

(d) Security requirements must be defined, tracked, and implemented as part of the work item in Linear.

(e) Security analysis must be performed for any open-source or third-party components introduced into Foundry software.

(f) Static application security testing (SAST), including type-checking via tsgo --noEmit, lint with security rules via oxlint --type-aware, and dependency scanning, must be performed throughout development and before each release.

(g) Dynamic application security testing (DAST) must be performed before each release for customer-facing web surfaces.

(h) All Critical or High severity security findings must be remediated prior to release.

(i) All Critical or High severity vulnerabilities discovered post-release must be remediated within the SLAs defined in the Vulnerability Management Policy.

(j) Any exception to remediation must be documented and approved by the Security Officer.

(k) PHI must never leave Foundry’s FHIR service (R4) boundary. PHI must not appear in source code, test fixtures, logs, prompts, agent memory, generated documentation, or commit history. Test fixtures use placeholder strings.

3. Development process

3.1 Overview

Foundry follows a release strategy that gives every production change a traceable lineage. Features, enhancements, and defects are tracked as Linear issues in the relevant project. An engineer proposes the change in a feature branch, opens a GitHub pull request, and continuous integration (GitHub Actions, pinned to commit SHAs) runs the full check suite. Once review and CI pass, changes merge into main and promote through environments under the Configuration & Change Management process.

Foundry practices continuous delivery through development, staging, and production environments. Infrastructure is written as code (Terraform / Pulumi under infra/ in conductor, Nix flakes for foundry-master-agent) and managed in source control alongside the application. Lower environments use synthetic, placeholder data; PHI is never copied out of production.

Production deployments are gated by a Linear change-management ticket that records sign-offs from engineering, security, and product as appropriate. Roll-outs happen continuously, without service impact; if a deploy degrades production, it is rolled back and the offending change is reverted from source before the proposal cycle restarts. Feature toggles allow code to land in production ahead of customer-visible enablement (dark launching); enablement of a toggle is itself a change-managed event.

3.2 Secure development standards

Traceability of code changes lets Foundry’s software remain a living system. Linear is the system of record for change context. Every commit and pull request should reference a Linear issue ID that explains why the change is necessary; the resulting commit history lets us trace the lineage of any line of production code.

All Foundry git repositories are hosted in Foundry’s GitHub organization and share a baseline configuration. Repos are internal by default. The standard can be relaxed with documented justification; exceptions are socialized to the Security Officer.

Developers must document, in the change itself, any new or altered functions, ports, protocols, services, environment variables, and third-party dependencies introduced.

Branch strategy and code review process:

1. All development happens on feature branches cut from main. Changes for a single feature or fix live on a single branch.
   • Changes must be covered by a unit test (vitest / cargo test) where feasible, or by an integration / end-to-end test (playwright) where unit coverage cannot exercise the behavior.
   • Integration tests are required when unit tests cannot reliably exercise all facets of the change.
2. Developers follow conventional commit style. Commit messages are written in the present tense and start with the relevant Linear issue ID where applicable. Per Foundry organizational convention, commits do not include Co-Authored-By trailers, “Generated with Claude Code” footers, or other tool-marketing metadata.
3. Once the feature and tests are complete, a pull request is opened in GitHub. The PR description names the Linear issue, summarizes the change, and calls out anything reviewers should look for.
4. Code review happens through the PR mechanism.
   • Reviewers note potential issues; the author addresses them or explains why they are not applicable.
   • New commits to a PR reset stale approvals.
   • Each reviewer approves explicitly, after which the author merges into main.
   • A PR can only merge with at least one approval from someone other than the author.
5. If the change interacts with PHI (FHIR resources in conductor, memory events / mount security in foundry-master-agent), controls access to data that may contain PHI, or alters production infrastructure, security review is required before the PR can be marked complete.
   • The reviewer performs a secure-development review against Foundry’s standards. Foundry completed a platform-wide review on 2026-02-21; its findings are binding for new web app code.
   • The reviewer verifies that authenticated user actions generate appropriate audit log entries: codes only, never free-text PHI.

3.3 Release strategy

Releases follow continuous delivery into production through development, staging, and production environments. Infrastructure-as-code (Terraform / Pulumi for the AWS environment, Nix for the Rust workspace) is managed under source control, and every infrastructure change follows the same review and change-management path as application code. Detailed code-promotion and production-release procedures are covered in Configuration & Change Management.

4. Source code management

Foundry uses GitHub for source control. A designated Security Officer owns cross-cutting security concerns. Access and configuration standards include:

• All developers authenticate to GitHub per the Access Policy:
  • SSO via the workforce identity provider, with phishing-resistant MFA enforced at the IdP.
  • SSH key access permitted for git CLI; keys are rotated and inventoried.
• Every repo:
  • has a named owner;
  • is internal by default; public visibility requires explicit Security review;
  • uses the standard CODEOWNERS pattern for security-sensitive paths.
• Branch protection on main:
  • main cannot be rebased;
  • direct pushes to main are blocked;
  • history rewrites of main are blocked;
  • deletion of main is blocked;
  • force-push is blocked.
• Pull request requirements before merge:
  • at least one approving review from a non-author;
  • required status checks must pass: at minimum pnpm check (which runs pnpm fmt, pnpm lint, pnpm typecheck, pnpm knip, and the test suite) for TypeScript repos and cargo test --workspace + nix flake check --impure for Rust + Nix repos;
  • Foundry conventions forbid committing credentials, API keys, private keys, or cleartext password material of any kind. CI secret scanning and workflow linting enforce the rule, additional static analysis of workflows runs locally, and every PR is human-reviewed against it.
• Third-party GitHub Actions are pinned to immutable commit SHAs. Floating tags (@v3, @main) are forbidden, a well-known supply-chain footgun. Workflow linting runs in CI to catch violations, with additional static analysis of workflows performed locally. Production container images are pinned to explicit version tags; content-digest pinning is a near-term roadmap item.

5. High-level application security requirements

All Foundry software must include the following application security principles. Web applications must defend against the common web vulnerability classes called out in Foundry’s secure-development standards and the findings of the 2026-02-21 platform review.

1. Protect sensitive data: PHI, PII, credentials, and patient-identifying tokens. PHI in transit is encrypted with TLS 1.2 or higher; PHI at rest lives only in Foundry’s FHIR service and is encrypted with provider-managed or customer-managed keys (CMEK on request).
2. Provision strong access control. Identity, authentication, authorization, and accounting are enforced before any request reaches the FHIR store. Each workforce console enforces the strongest MFA factor it supports; a WebAuthn / FIDO2 passkey is enforced today on the AWS root account, with hardware security keys planned. SMS one-time codes are prohibited for workforce use, per Foundry’s credential baseline.
3. Log every transaction and access: who, when, which records, the outcome. Audit log rows record machine-readable codes, never free-text PHI bodies.
4. Implement client-side security at application endpoints: CSP, SRI, secure cookies, sandboxed iframes where embedded content is unavoidable.
5. Communicate securely between services. Service-to-service traffic inside the production environment is mutually authenticated; egress from the PHI-handling account is restricted.
6. Use secure defaults. Deny by default in authorization; explicit allow lists.
7. Maintain the security of all third-party and open-source dependencies. Upgrades run on a scheduled manual review cadence, published advisories are triaged by Security, and license scanning is part of the same gate; automated dependency-update tooling is being rolled out.
8. Validate every data input. Encode every output appropriate to its context (HTML, attribute, URL, JS, SQL). Schema validation at API boundaries.
9. Deploy and configure applications securely. Terraform / Pulumi for the AWS environment, Nix for the agent runtime; secrets supplied through the managed secrets store and never embedded in code or images.
10. Perform regular vulnerability analysis and apply patches promptly, on the timelines in Vulnerability Management.
11. Secure privileged access to production. Break-glass paths are logged and reviewed; standing production access is minimized.

All software must complete the SAST/DAST/dependency-scan gate before reaching production. Findings flow to the Vulnerability Management process.

6. Secure design and application threat modeling

The Foundry Security function, in collaboration with the engineering team, performs application threat modeling and risk assessment on a per-application basis. The approach blends industry-standard methods (STRIDE-style decomposition, attack-tree thinking, application-security verification checklists) with Foundry-specific concerns, most notably the PHI boundary and the agent-tier model defined in foundry-master-agent (Atlas at Tier 0, executives at Tier 1, Foundry ops at Tier 2, clinic-scoped clinical agents at Tier 3, sandboxed Moltworkers at Tier 4).

Major changes are captured via an RFC process. The RFC template requires a Security Considerations section documenting:

• identified risks,
• attack vectors,
• mitigating controls.

Each RFC captures sufficient detail of the feature or component to be developed, including:

• authentication and authorization mechanisms;
• network communications and service boundaries;
• data encryption in transit and at rest;
• the AWS services used and whether they are HIPAA-eligible under the BAA;
• logging and audit code coverage;
• data-flow diagrams and PHI boundary annotations;
• edge cases, drawbacks, and considered alternatives.

RFCs must be approved before implementation. Security is included as a required reviewer on RFC PRs that touch PHI flow, authentication, authorization, or production infrastructure.

6.1 Platform design details

Architectural specifications are maintained in Foundry’s internal architecture documentation, covering the system overview, the FHIR data model, and security and compliance. For the agent platform, internal documentation captures roughly twenty HIPAA-aware invariants that must hold before any change merges.

7. Dependencies & supply chain

Foundry treats the supply chain as part of the attack surface.

• GitHub Actions pinned to immutable commit SHAs. Floating tags (@v4, @main) are not permitted. CI workflow linting catches violations.
• Production container images are pinned to explicit version tags. Pinning images to their content digest is a near-term roadmap item.
• npm dependency upgrades honor a 7-day cooldown (minimumReleaseAge / --min-age 7) where the tooling supports it. This window is intended to reduce exposure to typosquats and short-lived malicious releases.
• Inventory and scanning. Published security advisories are triaged by Security, and dependency upgrades run on a scheduled manual review cadence; automated dependency-update tooling is being rolled out. Manual review and license scanning happen on dependency introductions.
• License hygiene. New dependencies are reviewed for license compatibility before adoption.
• Secret hygiene. Committing credentials is prohibited by Foundry’s contributor guides, which call out the credential patterns to reject on sight: messaging-platform bot tokens, AI-provider API keys, private keys, cleartext password material, and cloud access keys. GitHub secret scanning is enabled fleet-wide and blocks pushes of high-confidence patterns. Test fixtures use placeholder strings, never real credentials. Secrets that must live in a repository are stored only in encrypted form; one-way password hashes are safe to commit because they cannot be reversed.

8. SAST, DAST & penetration testing

8.1 Static application security testing

SAST runs on every PR through the standard pnpm check pipeline for TypeScript repos and cargo test --workspace + nix flake check --impure for Rust + Nix repos. Specifically:

• Type-check with tsgo --noEmit (TypeScript-go native), not tsc. Type errors are a release blocker.
• Lint with oxlint --type-aware (Oxidation Compiler), not ESLint. Security rules are enabled.
• Format with oxfmt, not Prettier. Format drift is a release blocker.
• Dead-code detection with knip. Removing unused exports reduces the attack surface.
• Manual code review by Security on PRs that touch PHI, authentication, authorization, or production infrastructure (see §3.2).
• Periodic deep review by Security as part of the weekly security cadence and by request via a Linear ticket on the Security project.

8.2 Dynamic application security testing

DAST is run against staging instances of the customer-facing web surfaces (marketing-website, pureethosmed-website, and the conductor web app) before each release that materially changes attack surface. Dedicated DAST tooling is being added to the pipeline; baseline scans are also available on request to the Security function.

8.3 Penetration testing

Foundry commissions an external penetration test of the operating platform from a qualified independent security firm at least once per year; the first external engagement is being scheduled. The Security function also performs internal white-box penetration testing of the platform on a documented cadence. The platform-wide OWASP Top 10 review was completed on 2026-02-21. External pen-test reports are held by the Security Officer and findings are tracked in Linear under the Security project.

9. Responsible disclosure

All software contains defects, including security defects. Foundry maintains a responsible-disclosure inbox at security@bioscopefoundry.com. Researchers acting in good faith are welcomed; we commit to acknowledging reports within a reasonable timeframe, triaging and remediating in accordance with our Vulnerability Management SLAs, and crediting reporters where they wish to be credited.

10. Outsourced software development

Where Foundry engages outside developers or contracting firms to build software on its behalf, the engagement must follow the same rigor and process as internal engineering. Outsourced developers must:

• develop in Foundry’s secure environment (Foundry-managed laptop posture or sanctioned Codespaces), accept Foundry’s security policies, and follow the same secure coding standards;
• receive secure-coding training equivalent to Foundry’s internal training program;
• follow Foundry’s source-control, code-review, and security-scanning processes;
• run an endpoint-compliance agent that verifies disk encryption, patching, screen-lock, firewall, and antimalware posture.

The contracting firm must demonstrate appropriate background-check practices during their own hiring process. Any outsourced engagement that may touch PHI flows is also subject to a Business Associate Agreement with the contracting firm.

11. HIPAA best practices for software development

11.1 Use only HIPAA-eligible services in the cloud (and any other cloud)

Foundry’s production environment for PHI is the Foundry-operated FHIR service (R4). Amazon Web Services (AWS) is a Foundry subprocessor and operates under a Business Associate Agreement covering its HIPAA-eligible services. PHI must only flow through HIPAA-eligible services covered by that BAA. Non-eligible services may be used in support of the production environment so long as they do not have access to PHI.

Where additional cloud services are introduced (for example, additional AI inference providers or analytics platforms), they may only be used to process PHI under a BAA and only via their HIPAA-eligible service offerings.

References:

• AWS HIPAA-eligible services reference
• the Foundry-operated FHIR service (HAPI FHIR running on AWS)

11.2 Separate access and data between production and non-production

Separation of duties between production and non-production environments is a HIPAA compliance requirement and a Foundry policy. Production PHI is never copied to development, staging, or local environments. Non-production data sets are synthetic or thoroughly de-identified.

11.3 Never log PHI

It is both a security best practice and a contractual obligation under the AWS BAA to keep PHI out of application logs, prompts, agent memory, and generated documents. Logs record machine-readable identifiers and audit codes; PHI bodies stay inside Foundry’s FHIR service on AWS. The foundry-master-agent mount-security and Beacon Layer redaction controls are designed to enforce this at the agent runtime: Moltworkers (Tier-4 sandboxed workers) cannot hold PHI by construction.

11.4 Include the right language in notices

Specific HIPAA language must be included in patient-facing terms, consents, and communications. Because Foundry acts as a business associate, patient-facing language belongs to the practice’s Notice of Privacy Practices. Where Foundry communicates with patients on a practice’s behalf (for example, appointment reminders), the practice’s notice and identifying information are surfaced, not Foundry’s. See HIPAA Notice & Business Associate Statement.

11.5 Data protection

Follow the requirements set out in:

• Data Management: classification model and handling matrix;
• Data Protection: encryption, key management, redaction;
• Business Continuity & Disaster Recovery: backup and recovery for PHI-containing systems.

12. Production system monitoring and paging

Production software and infrastructure are monitored continuously for health and for security-relevant events. The on-call rotation is paged via the on-call paging service when an error or anomaly is detected; secondary notifications route to Slack and email. See Incident Response for the response playbook and System Audits & Monitoring for monitoring controls and log retention.

13. Roles & responsibilities

• Security Officer: owns this policy, approves exceptions, owns the platform-wide secure-development review cadence and external penetration test engagement.
• Engineering Lead: owns adherence to the development process across the fleet; resolves disputes between speed and rigor in favor of rigor where PHI or production infrastructure is involved.
• Repository owners: named on each repo; responsible for keeping branch protection, CODEOWNERS, and required checks current.
• All engineers: responsible for following secure coding standards, writing tests, requesting security review where required, and refusing to merge code that fails the gate.

14. Review & revision

This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale. Material revisions are approved by the Security Officer in coordination with the Policy Management process. Notable triggers for off-cycle review: a material update to Foundry’s secure-development standards, a material change to the Foundry toolchain (e.g., a move off oxlint/oxfmt/tsgo), or a finding from penetration testing that exposes a process gap.

15. Related policies

• Vulnerability Management
• Threat Detection & Prevention
• Configuration & Change Management
• Access Control
• Data Protection
• AI Governance
• HIPAA Notice & Business Associate Statement
• Framework crosswalk