Acuity Health: Part 4 — CI/CD Quality Gates & ISO 27001 Risk

A security framework is only as good as its operational enforcement. Writing rigorous coding standards and drawing threat model diagrams provides little value if unvetted code can be merged into production without automated validation.

At the same time, security teams face a critical challenge: developer friction and alert fatigue. If an automated security pipeline floods engineers with hundreds of low-fidelity warnings or false positives, developers will find ways to bypass the checks.

To succeed, automated security gates must be actionable, deterministic, and tiered by severity. Furthermore, engineering risks must feed into an enterprise-wide risk management process, such as ISO/IEC 27001:2013, ensuring that technical debt is systematically quantified, assigned, and treated.

In this fourth installment of our Acuity Health Security Architecture series, we examine how to configure automated CI/CD quality gates and operationalize the 10-Step ISO 27001:2013 Risk Assessment Methodology.

The Tri-Factor DevSecOps Pipeline Engine

A mature DevSecOps pipeline integrates three distinct testing methodologies at separate stages of the build lifecycle:

flowchart TD
    subgraph CommitPhase ["1. Pre-Commit / Build Phase"]
        Code["Developer PR Submitted"]
        SAST["SAST (Static Analysis)
e.g., SonarQube / Semgrep
Scans raw source for syntax flaws"]
        SCA["SCA (Dependency Analysis)
e.g., Trivy / Snyk / Dependabot
Scans packages against CVE databases"]
    end

    subgraph Eval1 ["Pre-Build Gate Evaluation"]
        Gate1{"Critical / High Flaws Found?"}
    end

    subgraph DeployPhase ["2. Ephemeral Staging Deployment"]
        Deploy["Ephemeral AKS Staging Cluster"]
        DAST["DAST (Dynamic Analysis)
e.g., OWASP ZAP / StackHawk
Probes running APIs for auth bypass & BOLA"]
    end

    subgraph Eval2 ["Post-Deploy Gate Evaluation"]
        Gate2{"Runtime Violations Found?"}
    end

    subgraph OutputPhase ["3. Release or Escalation"]
        Prod["Promote to Production"]
        Jira["Auto-Generate Jira Security Tickets
Assign SLA Timer (48h / 14d / 30d)"]
        Block["Fail Build / Block PR Merge"]
    end

    Code --> SAST & SCA
    SAST & SCA --> Gate1
    Gate1 -- Yes: CVSS >= 7.0 --> Block
    Block --> Jira
    Gate1 -- No: CVSS < 7.0 --> Deploy
    Deploy --> DAST
    DAST --> Gate2
    Gate2 -- Yes: Critical DAST Finding --> Block
    Gate2 -- No: All Checks Clear --> Prod

1. Static Application Security Testing (SAST)

• Execution: Runs during the pre-compilation phase on every Pull Request.
• Target: Analyzes source code for insecure programming patterns, unparameterized database queries, missing error handlers, and hardcoded secrets.
• Optimization: Use tightly scoped rulesets (e.g., Semgrep custom rulesets or SonarQube Quality Profiles) to minimize false positives.

2. Software Composition Analysis (SCA)

• Execution: Scans project lockfiles during package resolution.
• Target: Cross-references third-party open-source dependencies against vulnerability databases (NVD, GitHub Advisory Database) and verifies licensing compliance.
• Output: Generates a standardized Software Bill of Materials (SBOM) for compliance audits.

3. Dynamic Application Security Testing (DAST)

• Execution: Deploys the build into an ephemeral staging environment and executes active security test suites against live HTTP/REST endpoints.
• Target: Detects runtime vulnerabilities that static analysis cannot see, including authentication token bypasses, TLS configuration weaknesses, and missing HTTP security headers.

Quality Gate Policy: Preventing Alert Fatigue

To maintain developer velocity while enforcing non-negotiable security baselines, teams must establish a tiered Quality Gate policy:

Operationalizing ISO/IEC 27001:2013 Risk Assessment

While automated pipelines catch code-level defects, enterprise security programs must evaluate broader systemic and operational risks. Acuity Health operationalizes risk governance through the 10-Step ISO/IEC 27001:2013 Risk Assessment Methodology.

graph LR
    S1["1. Define Framework"] --> S2["2. Identify Assets"]
    S2 --> S3["3. Identify Threats"]
    S3 --> S4["4. Identify Vulnerabilities"]
    S4 --> S5["5. Analyze Impact"]
    S5 --> S6["6. Determine Likelihood"]
    S6 --> S7["7. Calculate Risk Level"]
    S7 --> S8["8. Compare Thresholds"]
    S8 --> S9["9. Prioritize & Own"]
    S9 --> S10["10. Document & Treat"]

The 10 Iterative Steps Explained

1. Define the Risk Assessment Framework: Establish standardized scales for Likelihood (1–5) and Impact (1–5), aligning criteria with financial, clinical, and regulatory impact thresholds.
2. Identify Assets to Scope: Catalog all primary information assets, cloud repositories, EMR databases, telehealth microservices, and network interconnects.
3. Identify Threats: Enumerate active and passive threats (e.g., ransomware syndicates, insider negligence, third-party vendor outages, credential stuffing).
4. Identify Vulnerabilities: Discover structural, technical, or procedural weaknesses (e.g., unauthenticated API routes, misconfigured cloud storage, lack of immutable backups).
5. Analyze the Impact: Assess the consequences of compromise across clinical continuity, HIPAA breach notification costs, and patient safety.
6. Determine Likelihood: Quantify the statistical probability of occurrence based on attack telemetry, exploit availability, and existing control efficacy.
7. Calculate the Risk Level: Compute composite risk exposure: $$\text{Risk Level} = \text{Likelihood} \times \text{Impact}$$
8. Compare Risk Against Thresholds: Compare scores against organizational risk appetite:
   • Extreme Risk ($16–25$): Unacceptable; requires immediate executive escalation and emergency mitigation.
   • High Risk ($10–15$): Requires priority treatment plan within current sprint cycle.
   • Medium Risk ($5–9$): Managed through standard operational controls and monitoring.
   • Low Risk ($1–4$): Accepted with routine periodic review.
9. Prioritize and Own: Assign explicit accountability to designated Risk Owners who possess the operational authority and budget to manage the risk vector.
10. Document and Treat: Formulate a formal Risk Treatment Plan (RTP) selecting one of four treatment options:
    • Mitigate: Implement technical controls (e.g., deploy WAF, enforce mTLS).
    • Transfer: Shift financial liability via cyber insurance or vendor Business Associate Agreements (BAAs).
    • Accept: Formally acknowledge low-level residual risk within acceptable appetite thresholds.
    • Avoid: Re-architect systems to eliminate the risk vector entirely (e.g., deprecate high-risk legacy protocols).

Real-World Cloud Healthcare Risk Register Excerpt

Below is an excerpt demonstrating how technical software risks are evaluated, scored, and assigned within the master Risk Register:

Summary & Full Program Blueprint

Across this three-part series, we have outlined a complete, end-to-end framework for securing modern cloud software:

Access the Full Whitepaper

Download the complete engineering architecture document and formal academic citation on our Paper Landing Page.