Security-as-Code
Enterprise Operating Model
Capability-Driven Reference Architecture — CLI-Native Security Across Multi-Cloud, Git, CI/CD & ServiceNow
1. Executive Summary
This document defines a formal enterprise operating model for Security-as-Code: the practice of authoring, version-controlling, testing, deploying, and governing security controls as executable artefacts across multi-cloud estates.
The model is structured around capabilities, not technologies. Each capability is decomposed into functions, and each function is mapped to illustrative tooling that can be substituted without changing the model.
The architecture is CLI-native — security intent originates in the terminal, is version-controlled in Git, validated in pipelines, enforced at runtime, and governed through an enterprise service management layer.
GUIDING PRINCIPLE
If it cannot be expressed as code, policy, telemetry, and evidence, it becomes suspect. If it cannot be continuously validated, it becomes theatre.
2. Design Principles
Capabilities First, Technologies Second
Every element is defined as a capability: a business-meaningful function. Technologies are illustrative and substitutable. The model survives vendor substitution because the capability layer is stable.
CLI-Native Authoring
Security artefacts are authored in the terminal using AI-assisted tooling as cognition instrumentation. The CLI is the point of origin for every control, detection, policy, and evidence generator.
Git as System of Record
Git is the single source of truth for all security logic. Not Confluence. Not SharePoint. Not a GRC tool. Every artefact is committed, every change is diffable, every decision is traceable.
Evidence as Byproduct
Compliance evidence is generated automatically by controls operating in pipeline and at runtime. Evidence is machine-readable, timestamped, hashed, and delivered to the governance layer via API.
Security as a Property of Delivery
Security is not a department that reviews. It is a property embedded in infrastructure, pipelines, and runtime. Controls enforce continuously. Evidence generates continuously.
DARPA Execution Philosophy
Security initiatives are structured as time-boxed missions with explicit success and kill criteria, not perpetual roadmaps. Parallel bets are funded. Failure is treated as data.
Remediation as First-Class
Finding a problem is necessary but not sufficient. The operating model treats remediation orchestration as a first-class capability. The gap between finding and fix is where risk lives.
Exposure Management Foundation
You cannot remediate what you cannot see. Tenable One provides the exposure management foundation: continuous asset discovery, vulnerability assessment, attack path analysis, and risk-based prioritisation.
3. The Five-Layer Operating Model
The model is composed of five layers plus a remediation layer that bridges pipeline and runtime. Each layer has a defined responsibility. No layer performs another layer's function.
Convert security intent into executable artefacts via CLI
Store, version, branch, review, and approve artefacts
Validate, test, and deploy artefacts to target environments
Consume runtime findings, generate IaC fixes, simulate impact, trace root cause, validate effectiveness
Enforce policies, fire detections, generate telemetry across multi-cloud estate
Consume evidence, manage risk/compliance/change/incident, report to board
CRITICAL FLOW SEPARATION: Security logic flows downward (L1→L4). Evidence flows upward (L4→L5). The governance layer feeds identified gaps back to authoring as new missions. The remediation layer operates laterally: it consumes findings from runtime, generates code fixes that flow through pipeline for deployment, and updates governance with status.
4.1 Layer 1 — Security Authoring
The authoring layer converts human intent into machine-executable security artefacts. The practitioner operates from a CLI with AI-assisted tooling.
| Capability | Function | Illustrative Tooling |
|---|---|---|
| Policy Authoring | Author admission control, network, IAM, and data policies as code from natural language intent | OPA/Rego, AWS SCP, Azure Policy, Sentinel Policy, Kyverno |
| Detection Engineering | Author detection rules for SIEM, EDR, and cloud-native threat detection from scenario descriptions | KQL (Sentinel), Sigma, Splunk SPL, YARA, Snort/Suricata, GuardDuty |
| Infrastructure Security | Author secure infrastructure definitions including hardened baselines, network segmentation, and secrets management | Terraform, CloudFormation, Azure Bicep, Pulumi, Ansible |
| Compliance Scripting | Author validation scripts that test control objectives and produce machine-readable evidence | Python, Bash, PowerShell, InSpec, AWS Config custom rules, Azure Policy Guest Configuration |
| Threat Modelling | Generate architecture diagrams, trust boundary analysis, data flow decomposition, and ATT&CK technique mapping | Mermaid, Threagile, OWASP Threat Dragon, custom JSON/YAML |
| Penetration Test Authoring | Generate scoped recon playbooks, engagement configs, and tooling orchestration for controlled testing | Kali Linux, Nuclei templates, Python orchestration, Metasploit |
| AI-Assisted Generation | Accelerate artefact creation through LLM-assisted code generation, review, and iterative refinement in the terminal | Claude Code (CLI), GitHub Copilot, Cursor, Amazon Q Developer |
4.2 Layer 2 — Version Control & Collaboration
All security artefacts are version-controlled. The repository structure maps to control domains. Branching, review, and approval enforce quality and traceability.
| Capability | Function | Illustrative Tooling |
|---|---|---|
| Repository Management | Host, structure, and manage security artefact repositories with domain-aligned organisation | Git, GitHub, GitLab, Azure DevOps Repos, AWS CodeCommit |
| Branch & Merge Governance | Enforce branching models, require PR approval, prevent direct commits to protected branches | Branch protection rules, CODEOWNERS, required reviewers |
| Artefact Versioning | Tag and version security artefacts for release management and rollback capability | Git tags, semantic versioning, release branches |
| Secrets Prevention | Prevent credentials, keys, and tokens from being committed to repositories | git-secrets, truffleHog, Gitleaks, GitHub Advanced Security |
| Code Review & Approval | Ensure peer review of security logic before merge with domain-appropriate reviewers | Pull request workflows, CODEOWNERS, review templates |
| Audit Trail | Maintain immutable history of who authored, reviewed, and approved every artefact change | Git commit log, signed commits (GPG), PR audit trail |
4.3 Layer 3 — Pipeline & Deployment
The pipeline layer validates, tests, and deploys security artefacts. It is the enforcement point — the automated change advisory board. If an artefact does not pass the pipeline, it does not reach production.
| Capability | Function | Illustrative Tooling |
|---|---|---|
| Policy Validation | Lint and validate policy artefacts for syntax and logic correctness before deployment | OPA check/test, cfn-lint, Bicep linter, Terraform validate, Conftest |
| Detection Testing | Execute test cases against detection rules to verify correct firing and no false positives | Sigma test framework, KQL unit test harness, pytest |
| Infrastructure Plan & Validate | Generate and review infrastructure change plans before apply, including drift detection | Terraform plan, CloudFormation change sets, Bicep what-if |
| SAST | Scan authored code and IaC for vulnerabilities, misconfigurations, and insecure patterns | Checkov, tfsec, KICS, Trivy, Semgrep, SonarQube, Bandit |
| Artefact Signing & Provenance | Sign deployed artefacts to establish provenance and prevent tampering | Cosign (Sigstore), Notation, AWS Signer, in-toto |
| Environment Gating | Enforce approval gates between environments with human or automated approval | ADO Environments, GitHub Environments, CodePipeline approval |
| Multi-Target Deployment | Deploy artefacts across multiple cloud accounts, subscriptions, regions from a single pipeline run | Terraform workspaces, AWS StackSets, Azure MG deployments |
| Change Record Automation | Automatically create and update change records in governance layer when deployments execute | ServiceNow Table API, IntegrationHub, custom webhooks |
| Evidence Generation | Execute compliance validation scripts in pipeline and POST machine-readable evidence to governance | Custom Python/Bash, InSpec, AWS Config, ServiceNow GRC API |
| Remediation Orchestration | Consume runtime findings, normalise, prioritise, generate IaC fixes, simulate impact, trace root cause | ZEST Security (Agentic AI), Wiz, Sentinel, Terraform, Bicep, CFN |
| Remediation Validation | Validate that deployed fixes resolved the original finding, update governance records | ZEST Security, ServiceNow VR status update, evidence pipeline |
4.4 Layer 4 — Runtime
4.4.1 AWS Multi-Account Capabilities
| Capability | Function | Illustrative Tooling |
|---|---|---|
| Organisation Guardrails | Enforce preventive controls across all accounts via service control policies | AWS SCPs, AWS Organizations, Control Tower guardrails |
| Configuration Compliance | Continuously evaluate resource configurations against rules and report non-compliance | AWS Config Rules, Config Conformance Packs, Config Aggregator |
| Threat Detection | Detect malicious activity, anomalous behaviour, and known-bad indicators across all accounts | Amazon GuardDuty, custom threat lists, S3/EKS/Lambda protection |
| Findings Aggregation | Centralise security findings from all accounts into a single delegated admin account | AWS SecurityHub, custom actions, cross-account EventBridge |
| Centralised Logging | Collect and retain CloudTrail, VPC Flow Logs, DNS logs in an immutable archive | CloudTrail org trail, S3 Log Archive, CloudWatch Logs, Athena |
| Automated Response | Execute response playbooks triggered by security findings without human intervention | Step Functions, Lambda, EventBridge, SecurityHub custom actions |
| Secrets & Key Management | Manage, rotate, and audit cryptographic keys and application secrets across all accounts | AWS KMS, Secrets Manager, Parameter Store |
| Identity & Access Governance | Enforce least-privilege, session controls, and federation across all accounts | IAM Identity Center, IAM Access Analyzer, Permission Boundaries |
| Exposure Assessment | Continuously discover, assess, and prioritise vulnerabilities across all AWS accounts | Tenable One (VM, Cloud Security CNAPP, Identity Exposure), Nessus |
4.4.2 Azure Multi-Subscription Capabilities
| Capability | Function | Illustrative Tooling |
|---|---|---|
| MG Policy Enforcement | Enforce preventive and audit policies across all subscriptions via management group inheritance | Azure Policy, Policy Initiatives, Blueprints, Landing Zone |
| Security Posture Mgmt | Continuously assess workload security posture against benchmarks and regulatory standards | Defender for Cloud (CSPM), Regulatory Compliance, Secure Score |
| Threat Detection & Analytics | Detect threats using analytics rules, ML, and fusion across identity, cloud, and endpoint signals | Microsoft Sentinel, Analytics Rules (KQL), Fusion, UEBA |
| Centralised Log Analytics | Aggregate and query logs from all subscriptions in a dedicated workspace | Log Analytics Workspace, Diagnostic Settings, Azure Monitor |
| Automated Response (SOAR) | Execute automated response playbooks triggered by Sentinel incidents | Sentinel Automation Rules, Logic Apps, Azure Functions |
| Identity & Conditional Access | Enforce identity security posture including MFA, conditional access, PIM, and access reviews | Entra ID, Conditional Access (as code), PIM, Identity Protection |
| Secrets & Certificate Mgmt | Manage application secrets, certificates, and keys with access policies and rotation | Azure Key Vault, access policies, certificate auto-renewal |
| Network Security | Enforce network segmentation, egress filtering, and DDoS protection | Azure Firewall, NSG flow rules, DDoS Protection, Private Link |
| Exposure Assessment | Continuously assess vulnerabilities across all Azure subscriptions with unified risk scoring | Tenable One (VM, Cloud CNAPP, Identity Exposure for Entra ID) |
4.4.3 Cross-Cloud & Domain Capabilities
| Capability | Function | Illustrative Tooling |
|---|---|---|
| Multi-Cloud Policy Normalisation | Apply consistent policy intent across AWS and Azure from a single authored source | OPA/Rego, Terraform, custom policy transpilation |
| Unified Threat Visibility | Correlate threat signals across AWS and Azure into a single detection surface | Microsoft Sentinel, SIEM federation, Ninja Signal, custom correlation |
| Unified Exposure Management | Single risk-scored view of all exposures across IT, cloud, OT, IoT, containers, web apps, and identity | Tenable One (300+ integrations, AI attack path, Lumin scoring) |
| Domain-Scoped Control Mapping | Map controls to business domains with regulatory framework alignment per domain | YAML domain mapping files in Git, ServiceNow CMDB taxonomy |
| Cross-Cloud Remediation | Normalise findings from AWS and Azure, generate cloud-specific IaC fixes, validate effectiveness | ZEST Security (multi-cloud), native AWS/Azure/TF/Bicep/CFN |
4.5 Layer 5 — Governance & Service Management
The governance layer consumes evidence produced by the runtime and pipeline layers. It does not author security logic. It does not enforce controls. It governs.
| Capability | Function | Illustrative Tooling |
|---|---|---|
| CMDB | Map cloud accounts, subscriptions, workload domains as CIs enriched with Tenable One exposure data | ServiceNow CMDB, CSDM, Tenable One Service Graph Connector |
| Change Management | Create, approve, and track change records for security artefact deployments | ServiceNow Change Mgmt, IntegrationHub, Standard Change templates |
| Risk & Compliance (GRC) | Map controls to frameworks (DORA, CAF, PCI, CIS), link to Git, receive continuous evidence | ServiceNow IRM/GRC, Continuous Compliance, custom API integration |
| Security Incident Response | Receive incidents from cloud-native detections, manage investigation and response workflows | ServiceNow SIR, bi-directional Sentinel/SecurityHub integration |
| Vulnerability Management | Receive findings from Tenable One, track remediation with IaC fix linkage, validate closure | ServiceNow VR, Tenable One VR Integration, ZEST Security |
| Continuous Evidence & Audit | Provide real-time compliance posture from running controls, replace manual evidence collection | ServiceNow GRC API, custom evidence pipeline, framework-scoped views |
| Board & Executive Reporting | Generate posture reports, risk summaries, and compliance dashboards from live data | ServiceNow Performance Analytics, Power BI, custom dashboards |
| Feedback Loop | Identify control gaps, failed detections, new patterns and route as new missions to authoring | ServiceNow workflow triggers, Jira, custom webhooks, mission board |
4.3.1 Remediation Orchestration — ZEST Security
The remediation gap is the space between “finding identified” and “finding fixed.” Every CNAPP, CSPM, and vulnerability scanner excels at the former. None close the latter. ZEST Security closes this gap using multi-agent AI that operates at the intersection of Layers 3, 4, and 5.
| ZEST Agent | Function | Integration |
|---|---|---|
| Data Fabric Agent | Integrates, normalises, enriches, and deduplicates findings from multiple sources into a unified risk view | Ingests from Wiz, Sentinel, SecurityHub, Defender for Cloud |
| Risk Prioritisation | Prioritises based on exploitability, reachability, business criticality, and remediation effort | Feeds ServiceNow VR with contextualised findings. Reduces noise by up to 90%. |
| Impact Simulator | Simulates patches, updates, and IaC fixes to find highest-impact resolution paths | Identifies 'one fix, many findings' opportunities across accounts. |
| IaC Fix Generation | Generates ready-to-deploy Terraform, CloudFormation, Bicep, Pulumi, and ARM code fixes | Fixes committed to Git (L2), validated in pipeline (L3), deployed (L4). |
| Root Cause Tracing | Traces runtime findings back to the specific lines of IaC code that introduced them | DevOps receives exact file, line, and generated remediation. |
| Remediation Validation | Validates that deployed fixes resolved the original finding | Updates ServiceNow VR. Evidence generated. Audit trail complete. |
| Mitigation Path Analysis | When no patch available, identifies existing controls that already mitigate the risk | Reduces false positives where mitigating controls exist. |
10. Maturity Model
Controls configured manually in consoles. Evidence is screenshots. Change is verbal. Compliance is seasonal. No version control.
Some controls are scripted. Scripts in shared drives or wikis. No CI/CD. No testing. Limited traceability. Ticket-based change.
Security artefacts are in Git. PR review exists. Pipeline validation is emerging but inconsistent. Evidence partially automated.
All artefacts pass through CI/CD. Policy validation, detection testing, SAST are mandatory gates. Change records auto-created. Evidence flows to ServiceNow via API.
Controls execute and generate evidence continuously at runtime. Compliance posture is real-time. Feedback loop active. ZEST generates IaC fixes. MTTR drops from weeks to days.
AI-assisted authoring accelerates artefact creation. Detection rules self-tune. Policy drift auto-remediated. ZEST remediation operates at machine speed. The model learns faster than the adversary.
9. Roles & Responsibilities
| Role | Layer | Responsibilities |
|---|---|---|
| Security Platform Engineer | L1, L3 | Authors secure IaC, pipeline configurations, golden paths, and paved roads. |
| Detection Engineer | L1, L3 | Authors detection rules, test cases, and response playbooks. Owns detection-as-code lifecycle. |
| Policy Engineer | L1, L3 | Authors OPA/Rego, SCPs, Azure Policy, and admission control artefacts. |
| Technical GRC Engineer | L1, L5 | Authors compliance validation scripts. Maps controls to frameworks. Manages evidence pipeline. |
| Identity Engineer | L1, L4 | Authors IAM policies, Conditional Access rules, PIM configurations as code. |
| Penetration Tester | L1, L4 | Authors and executes scoped pen test engagements within the operating model. |
| Remediation Engineer | L3-L4 | Manages ZEST remediation platform. Reviews AI-generated IaC fixes. Owns MTTR. |
| Exposure Management Analyst | L4, L5 | Manages Tenable One platform. Owns asset discovery completeness and scan coverage. |
| Security Architect | L1 (all) | Designs the operating model, defines domain-control mappings, owns cross-layer coherence. |
| CISO / Security Leadership | L5 | Owns the operating model. Sets mission portfolio. Reports posture to the board. |
8. Execution Model — Missions, Not Roadmaps
Each security initiative is structured as a time-boxed mission with explicit outcomes, not a perpetual roadmap item. The DARPA model funds competing hypotheses. Parallel missions can test different approaches to the same problem. The one that produces better evidence wins. Failure is data, not disgrace.
A specific, measurable security outcome
Detect credential stuffing within 5 minutes across all prod accounts
Fixed duration with explicit end date
90 days
Measurable threshold for mission success
Detection latency < 5 mins, FP rate < 2%, coverage = all prod
Conditions for early termination
If latency has not improved by day 60, pivot or terminate
Security-as-code outputs the mission produces
3 Sigma rules, 2 KQL queries, 1 Config Rule, 1 evidence generator
Single accountable individual with authority
Detection Engineering Lead, with authority over tooling and deployment
13. Closing Statement
This operating model is not a theory. It is a working architecture derived from practice — from building security artefacts in a CLI, shipping them through pipelines, enforcing them across multi-cloud estates, remediating findings at machine speed, and governing them through ServiceNow.
The terminal is the new SOC. The prompt is the new runbook. The artefact is the new evidence. The code is the control. The remediation is automated.
scottg/out
© 2026 Scott Gardner · ninja.ing · DRAFT — COMMERCIAL IN CONFIDENCE