Acuity Health: Part 2 - Zero Trust DevSecOps & NIST SSDF

In the evolving landscape of cloud-based healthcare services, traditional perimeter security becomes ineffective. Developers require swift access to software packages, continuous integration pipelines, and staging environments. Simultaneously, security teams must ensure the protection of electronic Protected Health Information (ePHI) from unsecured code or compromised dependencies.

To address these challenges, the integration of Zero Trust Architecture (ZTA) and the NIST Secure Software Development Framework (SP 800-218 v1.1) proves essential. This approach enables the embedding of security directly into the development infrastructure.

In the second part of the Acuity Health Security Architecture series, we delve into the methodologies for constructing isolated development landing zones, implementing ephemeral build pipelines, and securing the software supply chain. The Zero Trust Engineering Plane emphasizes the rigorous application of Zero Trust principles—Never Trust, Always Verify; Assume Breach; Least Privilege—to both developer workstations and build infrastructure, akin to the security measures applied to production databases.

In conventional setups, developer environments often share network routes with staging areas or internal database replicas. This configuration presents a significant risk: if a developer's workstation is breached through phishing or by using untrusted packages, attackers can laterally move within the core clinical networks.

The architectural framework comprises several key components:

1. **Logical Network Segmentation**: Development infrastructure resides in dedicated Azure DevTest Labs, segmented through Network Security Groups (NSGs). These development subnets have no routing connections to production Electronic Medical Record (EMR) databases or production telemetry systems.

2. **API Gateways as Policy Enforcement Points (PEPs)**: All traffic, both inbound and outbound, between internal tiers passes through API Gateways situated within a Demilitarized Zone (DMZ). Traffic is authenticated via mutual TLS (mTLS) and controlled by granular Role-Based Access Control (RBAC).

3. **Ephemeral Build Runners**: Build agents are stateless and single-use. These runners are provisioned inside isolated containers for the duration of a single commit job. They execute pre-build linting and scans, compile the artifacts, sign them cryptographically, and subsequently terminate. No persistent credentials or artifacts are retained on these runners.

Operationalizing the NIST SP 800-218 (Secure Software Development Framework) offers a structured approach to integrating AppSec within lean engineering teams. The framework is organized into four outcome-based pillars:

1. **Prepare the Organization (PO)**: Foster institutional security ownership through embedded AppSec Champions within feature squads. These champions review pull requests for security vulnerabilities and engage in monthly threat intelligence briefings. Training sessions focus on the OWASP Top 10 and API-specific vulnerabilities such as Broken Object Level Authorization (BOLA).

2. **Protect the Software (PS)**: Ensure pipeline integrity and supply chain security by employing cryptographic artifact signing using keys stored in an isolated Hardware Security Module (Azure Key Vault Managed HSM) through tools like Cosign or Notary. Additionally, produce a Software Bill of Materials (SBOM) in machine-readable formats such as SPDX or CycloneDX for every CI build, detailing direct and transitive dependencies.

3. **Produce Well-Secured Software (PW)**: Prioritize vulnerability elimination before deployment. Implement 15-minute mini-STRIDE threat modeling during backlog grooming sessions. Utilize standardized internal cryptographic SDKs, such as AES-256-GCM for at-rest encryption and TLS 1.3 for data in transit. Enforce context-aware authorization logic at the database layer.

4. **Respond to Vulnerabilities (RV)**: Establish a formal Vulnerability Disclosure Program (VDP) with RFC 9116 guidelines. Commit to a 48-hour remediation SLA for Critical CVEs. Post-incident, conduct root-cause analyses that feed directly into engineering backlog items.

The implementation of Security Champions within each development squad ensures that security becomes an integral part of the development process. Hand-on training, tailored to specific technological stacks, focuses on the OWASP Top 10 and API vulnerabilities. Cryptographic signing of binaries and container images using keys stored in an isolated Hardware Security Module (Azure Key Vault Managed HSM) via Cosign, combined with the automatic generation of Software Bills of Materials (SBOM) during CI builds, further fortifies the software supply chain.

Approved cryptographic libraries enforce AES-256-GCM for data at rest and TLS 1.3 for data in transit, while automated pre-commit linters prevent the introduction of unparameterized database queries, weak entropy sources, or hardcoded API secrets into the codebase. Finally, a clear Vulnerability Disclosure Policy (VDP) enables external ethical researchers to report vulnerabilities responsibly, ensuring rapid response and containment.