Vulnerability Management

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

1. Purpose & scope

This policy governs how Bioscope Foundry discovers, tracks, prioritizes, and remediates security vulnerabilities across its production systems and supporting infrastructure, including the conductor TypeScript platform, the foundry-master-agent Rust workspace, the Maverick OpenClaw deployment in agents/, customer-facing web surfaces, and the development tooling and CLIs maintained in Foundry’s GitHub organization. It also covers vulnerabilities reported to Foundry through the responsible-disclosure inbox and findings produced by penetration testing.

2. Policy statements

Bioscope Foundry policy requires that:

1. All product systems must be scanned for vulnerabilities on a continuous basis (via CI security checks and published-advisory triage) and reviewed at least quarterly and with each material release.
2. All vulnerability findings must be reported and tracked to resolution in Linear under the Security project. Records of findings are retained for at least six years to align with HIPAA’s documentation retention requirement.
3. All personnel performing internal security testing shall:
   • be a Foundry Security function member, or otherwise specifically authorized by the Security Officer for a given test scope and duration;
   • have appropriate training or experience with the tools and techniques used;
   • maintain currency of knowledge through training, conferences, and continuing professional education.
4. Critical and High severity findings affecting production must be remediated within the SLAs defined in §5. No release ships to production with an unresolved Critical or High finding unless an approved Exception is in place.
5. Exceptions to remediation must be documented, reviewed, and approved by the Security Officer and the impacted asset owner.

3. Vulnerability discovery

Foundry uses a layered approach to discover vulnerabilities across the software supply chain and runtime environment.

1. Software composition analysis (SCA). Dependency upgrades run on a 7-day release-age cooldown (minimumReleaseAge) and a scheduled manual review cadence; published advisories affecting Foundry dependencies are triaged into Linear with severity, exploitability, and reachability annotations. Automated dependency-update tooling is being rolled out.
2. Static analysis in CI. Every pull request runs the standard check suite: type-checking with tsgo --noEmit, security linting with oxlint --type-aware, dead-code analysis with knip, and the Rust + Nix equivalents (cargo test --workspace, cargo audit, nix flake check --impure). Findings produced by these tools are surfaced on the PR itself.
3. Secret scanning. GitHub secret scanning with push-protection is enabled fleet-wide, blocking known-secret patterns before they land in a remote branch. Foundry contributor guides prohibit committing credential material of any kind, messaging-platform bot tokens, AI-provider API keys, private keys, cleartext password material, and cloud access keys, and PR review enforces the rule. One-way password hashes are safe to commit; cleartext is not.
4. Cloud security posture monitoring. Cloud posture and misconfiguration monitoring is being stood up as part of the security-tooling rollout. Findings flow to the same Linear pipeline as software findings.
5. Threat intelligence and advisory monitoring. The Security function monitors CISA advisories, AWS and Foundry FHIR-service security bulletins, Anthropic and OpenAI security disclosures (for AI dependencies), and upstream advisories from the maintainers of Foundry’s software dependencies. See Threat Detection & Prevention.
6. Manual security review. Security reviews PRs that touch PHI, authentication, authorization, or production infrastructure (see Secure SDLC §3.2). Periodic deep reviews are performed as part of the weekly security cadence.
7. Penetration testing. At least one annual external engagement plus internal white-box tests (see §8).
8. Responsible disclosure. External reports arrive at security@bioscopefoundry.com; each report is acknowledged and triaged into the same Linear queue.
9. Platform-wide secure-development review. Foundry performs periodic platform-wide reviews against its secure-development standards; the most recent completed 2026-02-21. Its findings are binding for new web app code and tracked to remediation under this policy.

4. Reporting, tracking & remediation

Foundry tracks vulnerabilities in Linear under the Security project. Records of findings are retained for at least six years.

4.1 Reporting a finding

• Upon identification of a vulnerability (in software, system, or process), a Linear issue is created in the Security project.
• The issue captures the following structured fields where applicable:
  • Source of finding (SCA / SAST / DAST / manual review / pen test / external disclosure / threat intel).
  • In production (yes / no / N/A).
  • Affected component (repo name, package, service, or infrastructure resource).
  • Severity rating (see §5).
  • Reachability / exploitability assessment.
• The title of the finding follows the format “[Sev] {short description}” (e.g., “[High] Outdated jsonwebtoken dependency in conductor services”).
• The description contains technical details with no PHI and no confidential customer information, plus a link to the source advisory or finding.
• The priority on the Linear ticket matches the severity rating.

5. Severity ratings & SLAs

Severity reflects the realistic worst-case impact of the vulnerability in Foundry’s environment, weighted by exploitability and whether the affected surface processes PHI. SLAs drive remediation timelines from the point the finding is created. Findings that are actively being exploited in the wild are treated as Critical regardless of base score.

If a severity rating is changed after creation, the SLA adjusts as follows:

• Severity upgrade: the SLA resets from the time of escalation.
• Severity downgrade: the SLA time remains based on the original creation date of the finding.

6. Resolving & closing findings

• The finding is assigned to the owner responsible for the affected system, repo, or package. CODEOWNERS drives routing where ambiguous.
• All findings are addressed against the applicable SLA. Findings approaching or breaching SLA are surfaced to the Security Officer and the Engineering Lead in the weekly security review.
• No release ships to production with an unresolved Critical or High finding unless an approved Exception is in place (see §7).
• A finding may be resolved by:
  1. providing a valid fix or mitigation that addresses the root cause;
  2. determining the finding to be a false positive, with rationale recorded in the issue; or
  3. documenting an approved Exception with a compensating control.

6.1 Closing a finding

• The assignee records the resolution (fix PR link, mitigation description, or Exception link) as a comment on the Linear issue.
• The finding is re-assigned to the reporter or to a member of the Security function for validation.
• Upon validation, the finding is marked Done (closed).
• A finding may only be closed once the fix has been deployed to development / staging and a targeted production-release date is noted on the ticket. Findings remain open until the fix lands in production.

7. Exceptions

• An Exception may be requested when a direct fix is not available, for example, a fixed version of a dependency is not yet released, is incompatible with the current runtime, or has not yet cleared the 7-day npm cooldown (minimumReleaseAge / --min-age 7) Foundry applies to dependency upgrades to reduce supply-chain risk.
• A compensating control must be in place, technical (WAF rule, network restriction, configuration change), procedural (heightened monitoring, additional human review), or a combination, such that the residual risk is acceptable.
• The Exception is opened as a Linear issue and linked to the original finding.
• Each Exception is reviewed and approved by the Security Officer and the impacted asset owner.
• All Exceptions are reviewed every six months to re-assess validity, and immediately when an upstream fix becomes available.

8. Penetration testing

• External penetration testing is commissioned at least once per year from a qualified independent security firm; the first external engagement is being scheduled. The platform-wide OWASP Top 10 review was completed 2026-02-21. Pen-test reports are held by the Security Officer and findings are tracked in Linear under this policy.
• Internal white-box penetration testing is performed periodically by the Security function with engineering collaboration. Scope, timing, and rules of engagement are documented in advance.
• Responsible disclosure is continuously open at security@bioscopefoundry.com. A formal bug-bounty program is not currently offered.
• All testing performed against Foundry production systems requires explicit authorization in writing from the Security Officer. Internal testers are bound by the same access-control and minimum-necessary requirements as production engineers.

9. Records retention

Vulnerability findings, pen-test reports, exception records, and the related audit trail are retained for at least six years to align with HIPAA’s documentation retention requirement at 45 CFR § 164.316(b)(2). Records are stored in Linear and the Foundry document repository; access is restricted to the Security function and the relevant asset owners.

10. Roles & responsibilities

• Security Officer: owns this policy, the severity scale, exception approvals, and the external pen-test engagement.
• Engineering Lead: owns remediation throughput against SLA; arbitrates competing priorities in favor of security where Critical or High findings are open.
• Repository / system owners: receive findings via routing rules and are responsible for delivering fixes within SLA.
• All engineers: report suspected vulnerabilities through the Security project in Linear; never close a finding before the fix is in production.

11. 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.

12. Related policies

• Secure SDLC & Product Security
• Threat Detection & Prevention
• Configuration & Change Management
• Incident Response
• Vendor & Third-Party Risk
• HIPAA Notice & Business Associate Statement
• Framework crosswalk