The Security-as-Code Operating Model

## CLI-Native Security Across ServiceNow, Git, AWS, and Azure — An Enterprise Reference Architecture

Scott Gardner | ninja.ing | February 2026

## Preamble: Why This Exists

I wrote a post last week about running security from the CLI. Claude Code as cognition instrumentation. Policy as Rego. Detections as code. Compliance evidence generated by scripts, not scribes.

The response was predictable. Half the comments were "this is the future." The other half were "this would never work in my enterprise."

Both are right. And both miss the point.

The CLI workflow I described isn't a solo practitioner hack. It's the atomic unit of something much larger — an operating model where security artefacts are authored in a terminal, version-controlled in Git, validated in pipelines, enforced across multi-cloud estates, and governed through ServiceNow. Not as a concept. As a system.

This article defines that operating model.

Not a vendor pitch. Not a framework alignment exercise. A working architecture for how security-as-code operates at enterprise scale across AWS multi-account, Azure landing zones, ADO pipelines, and ServiceNow ITSM/GRC — with the CLI as the point of origin for every control, every detection, every policy, and every piece of evidence.

If it can't be expressed as code, policy, telemetry, and evidence, it becomes suspect. If it can't be continuously validated, it becomes theatre.

Let's make it run on rails.

## 1. The Operating Model — Conceptual Layer

The model has five layers. Each layer has a job. No layer does someone else's job.

Layer 1 — Authoring (The CLI)

Where security intent becomes artefact. The practitioner — the hacker head, the detection engineer, the policy author — sits in a terminal with Claude Code (or equivalent) and converts intent into executable output. This is where "Wang'n reality" happens. A concept enters the CLI as natural language. What exits is code: a Rego policy, a KQL detection, a Sigma rule, a Terraform module, a validation script, an architecture threat model.

Layer 2 — Version Control (Git)

Every artefact is committed. Every change is diffable. Every decision is traceable. Git is the system of record for security logic. Not Confluence. Not SharePoint. Not the CISO's memory. Git.

Layer 3 — Pipeline (CI/CD)

Artefacts are tested, validated, and deployed through automated pipelines. Azure DevOps. AWS CodePipeline. GitHub Actions. The pipeline is the enforcement point. If it doesn't pass the pipeline, it doesn't reach production. The pipeline is the new change advisory board — except it doesn't cancel meetings or take holidays.

Layer 4 — Runtime (Multi-Cloud Estate)

Policies enforce. Detections fire. Evidence generates. Telemetry flows. Across AWS accounts, Azure subscriptions, availability zones, regions, and domains. The artefacts authored in the CLI are now infrastructure, running continuously, validating continuously, producing evidence continuously.

Layer 5 — Governance (ServiceNow)

ServiceNow is the control plane for risk, compliance, change, and incident. Not the authoring tool. Not the enforcement point. The governance layer that consumes evidence, tracks exceptions, manages incidents, and provides the audit trail that keeps regulators calm and boards informed.

The critical insight: security logic flows down (CLI → Git → Pipeline → Runtime), and evidence flows up (Runtime → Pipeline → ServiceNow). These are two different flows. Most enterprises confuse them, which is why everything takes six months and nothing is validated.

## 2. The Git Architecture — Security Repos at Scale

### Repo Strategy

You need a deliberate repo structure. Not "one big repo for everything." Not "a repo per person." A structure that maps to control domains and deployment boundaries.

Recommended structure:

security-platform/

├── policies/ # OPA Rego, Sentinel, AWS SCP, Azure Policy

│ ├── container-policies/

│ ├── iam-policies/

│ ├── network-policies/

│ └── data-policies/

├── detections/ # KQL, Sigma, Splunk SPL, YARA

│ ├── credential-abuse/

│ ├── lateral-movement/

│ ├── exfiltration/

│ └── persistence/

├── compliance/ # Validation scripts, evidence generators

│ ├── cis-benchmarks/

│ ├── dora-controls/

│ ├── ncsc-caf/

│ └── custom-controls/

├── infrastructure/ # Terraform, CloudFormation, Bicep

│ ├── aws/

│ │ ├── org-scps/

│ │ ├── guardduty/

│ │ ├── securityhub/

│ │ └── config-rules/

│ ├── azure/

│ │ ├── policy-definitions/

│ │ ├── sentinel-rules/

│ │ ├── defender-config/

│ │ └── landing-zone-guardrails/

│ └── shared/

│ ├── secrets-management/

│ └── certificate-automation/

├── threat-models/ # Mermaid diagrams, structured decompositions

├── pentest/ # Scoped engagement configs, tooling

│ ├── recon-playbooks/

│ ├── kali-containers/

│ └── reports/

├── evidence/ # Generated evidence artefacts (CI output)

└── .pipelines/ # CI/CD definitions

├── azure-devops/

├── aws-codepipeline/

└── github-actions/

### Branching Model

Main — production-deployed security state. Protected. Requires PR approval + pipeline pass.

Feature branches — where the CLI work happens. feature/detect-kerberoasting, feature/policy-no-public-s3, feature/compliance-dora-art25.

Environment branches — dev, staging, prod map to deployment targets across cloud accounts.

### Who Commits What

This isn't a single-team model. The repo accepts PRs from:

- Security engineers authoring detections and policies from the CLI

- Platform engineers contributing Terraform modules and pipeline configs

- GRC engineers contributing compliance validation scripts

- Pen testers contributing engagement configs and findings-as-code

- Claude Code sessions generating initial artefacts that humans review and merge

Every commit is attributed. Every merge is approved. Every artefact is traceable to intent.

## 3. AWS Multi-Account Architecture

Enterprise AWS doesn't run in one account. It runs across dozens or hundreds, structured in AWS Organizations with SCPs, delegated admin, and account vending. Security-as-code must operate across this entire topology.

### The AWS Security Architecture

AWS Organization

├── Management Account (org root, SCPs, billing)

├── Security OU

│ ├── Security Tooling Account (SecurityHub, GuardDuty delegated admin, Config aggregator)

│ ├── Log Archive Account (CloudTrail, VPC Flow Logs, centralised S3)

│ └── Forensics Account (isolated, breakglass, IR tooling)

├── Infrastructure OU

│ ├── Network Hub Account (Transit Gateway, DNS, egress filtering)

│ └── Shared Services Account (AD, PKI, secrets manager)

├── Workload OUs (per domain / business unit)

│ ├── Domain-A-Dev Account

│ ├── Domain-A-Staging Account

│ ├── Domain-A-Prod Account

│ ├── Domain-B-Dev Account

│ └── ...etc

└── Sandbox OU (experiments, pen testing, isolated)

### How CLI-Authored Artefacts Deploy Across Accounts

Service Control Policies (SCPs) — authored as JSON in the CLI, committed to infrastructure/aws/org-scps/, deployed via pipeline to the Management Account. SCPs are the guardrails that no workload account can override. "No public S3 buckets" isn't a policy document. It's an SCP that physically prevents the action.

AWS Config Rules — custom rules authored in the CLI as Lambda functions or managed rule configurations. Deployed to the Security Tooling Account via delegated admin, evaluated across all member accounts. Non-compliant resources surface as Config findings, which flow to SecurityHub, which flow to the evidence pipeline, which flow to ServiceNow.

GuardDuty configurations — threat detection tuning authored in the CLI, deployed centrally. Suppression rules, custom threat lists, and S3 malware scanning configs are version-controlled, not console-clicked.

SecurityHub custom actions and automations — response playbooks authored as Step Functions or Lambda, triggered by SecurityHub findings, deployed across the estate via StackSets from the Security Tooling Account.

### Cross-Account Deployment Patter

CLI (author) → Git (commit) → Pipeline (validate + plan)

→ StackSets / Terraform workspaces (deploy to N accounts)

→ Config Rules evaluate → SecurityHub aggregates

→ EventBridge → Lambda → ServiceNow API (evidence + incidents)

Every AWS account gets the same controls. Every account produces evidence. The Security Tooling Account is the aggregation point. ServiceNow is the governance layer.

## 4. Azure + ADO Architecture

Azure runs on management groups, subscriptions, and Azure Policy. Azure DevOps (ADO) is the pipeline engine. The model maps directly.

### Azure Landing Zone Security

Azure Tenant

├── Root Management Group

│ ├── Platform MG

│ │ ├── Identity Sub (Azure AD, PIM, Conditional Access)

│ │ ├── Management Sub (Log Analytics, Sentinel, Defender for Cloud)

│ │ └── Connectivity Sub (Hub VNets, Firewall, DNS)

│ ├── Landing Zones MG

│ │ ├── Corp MG

│ │ │ ├── Domain-A-Dev Sub

│ │ │ ├── Domain-A-Prod Sub

│ │ │ └── ...etc

│ │ └── Online MG (public-facing workloads)

│ ├── Sandbox MG (isolated, pen testing)

│ └── Decommissioned MG

### Azure DevOps Pipeline Integration

ADO Repos mirror the Git structure above. ADO Pipelines validate and deploy.

Azure Policy Definitions — authored as JSON in the CLI, committed to infrastructure/azure/policy-definitions/. Pipeline deploys to the Root MG or scoped MGs using az policy definition create and az policy assignment create. Policies inherit downward. A deny policy at Root MG applies to every subscription.

Sentinel Analytics Rules — KQL detections authored in the CLI, committed to detections/, deployed to the Management Subscription's Sentinel workspace via ADO pipeline using az sentinel alert-rule create or Terraform azurerm_sentinel_alert_rule_scheduled.

Defender for Cloud configurations — security posture policies, regulatory compliance assignments, and auto-provisioning settings deployed as Bicep/Terraform, not clicked in the portal.

### ADO Pipeline — Security Artefact Lifecycle

```yaml

# .pipelines/azure-devops/security-deploy.yml

trigger:

branches:

include: [main]

paths:

include:

- policies/**

- detections/**

- compliance/**

- infrastructure/azure/**

stages:

- stage: Validate

jobs:

- job: PolicyLint

steps:

- script: opa check policies/ --strict

- script: python compliance/validate_all.py --dry-run

- stage: Test

jobs:

- job: DetectionTest

steps:

- script: python detections/test_runner.py --format junit

# Runs YAML test cases against detection logic

- stage: DeployDev

jobs:

- job: ApplyPolicies

steps:

- task: AzureCLI@2

inputs:

scriptType: bash

scriptLocation: inlineScript

inlineScript: |

az policy definition create --name $POLICY_NAME \

--rules @policies/$POLICY_FILE \

--management-group $DEV_MG

- stage: DeployProd

dependsOn: DeployDev

condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

jobs:

- job: ApplyPoliciesProd

environment: production # ADO environment with approval gate

steps:

- task: AzureCLI@2

inputs:

scriptType: bash

scriptLocation: inlineScript

inlineScript: |

az policy definition create --name $POLICY_NAME \

--rules @policies/$POLICY_FILE \

--management-group $ROOT_MG

The approval gate on the production environment is the human checkpoint. Not a meeting. Not a CAB. A named approver who reviews the diff and clicks approve — or doesn't.

## 5. ServiceNow Integration — Governance, Not Authoring

This is where most enterprises get it wrong. They try to use ServiceNow as the place where security happens. It isn't. ServiceNow is the place where security is governed.

### What ServiceNow Does in This Model

CMDB — Configuration items map to cloud accounts, subscriptions, workload domains. The CMDB is the topology that controls are deployed against.

Change Management — Pipeline deployments create change records automatically. The CI/CD pipeline calls the ServiceNow Table API or IntegrationHub to create a Standard Change (pre-approved for policy deploys that pass all validations) or a Normal Change (requiring CAB approval for infrastructure changes).

GRC / Integrated Risk Management (IRM) — Controls in ServiceNow map to artefacts in Git. Each control record contains a source_repo and artefact_path field. Evidence is not uploaded manually. The compliance pipeline POSTs evidence payloads to ServiceNow's GRC API: timestamp, control ID, pass/fail, artefact hash, pipeline run ID.

Security Incident Response (SIR) — SecurityHub findings, Sentinel incidents, and GuardDuty alerts flow into ServiceNow SIR via EventBridge → Lambda → ServiceNow API (AWS) or Logic Apps → ServiceNow connector (Azure). The incident record links to the detection rule in Git, the control it validates, and the remediation playbook — all traceable.

Vulnerability Response — Scan findings flow into ServiceNow VR. Remediation is tracked as a change, deployed via pipeline, and evidence is generated automatically when the control validates the fix.

### The Evidence Pipeline

This is the part that eliminates the seasonal audit ritual.

Runtime Control Executes

→ Produces machine-readable evidence (JSON)

→ Evidence pipeline POST to ServiceNow GRC API

→ Control record updated: last_validated, result, evidence_hash

→ Dashboard reflects continuous compliance posture

→ Auditor sees real-time evidence, not a PDF from six months ago

```

Example — CIS Benchmark validation:

return evidence

That script runs in pipeline. Across every AWS account. Every day. The evidence lands in ServiceNow without a human touching it. The auditor sees a live control posture, not a screenshot from last quarter.

## 6. Multi-AZ, Multi-Domain, Multi-Account Topology

Real enterprises don't have "an AWS account." They have domains. Domains have environments. Environments span availability zones and regions. The operating model must account for this topology.

### Domain Model

Domain = Business Unit or Product Line

└── Environment = Dev / Staging / Prod

└── Account (AWS) or Subscription (Azure)

└── Region

└── Availability Zone(s)

### How Controls Map to Domains

Not every domain gets the same controls. A payments domain has PCI controls. A marketing domain doesn't. The mapping lives in Git:

```yaml

# control-mappings/domain-payments.yml

domain: payments

regulatory_frameworks:

- PCI-DSS-4.0

- DORA

- UK-OpRes

controls:

- id: PCI-6.4.3

artefact: policies/container-policies/no-root-containers.rego

scope: all-environments

- id: PCI-11.3.1

artefact: pentest/recon-playbooks/external-asv-scan.yml

scope: prod-only

- id: DORA-Art25

artefact: compliance/dora-controls/ict-risk-reporting.py

scope: all-environments

The pipeline reads the domain mapping. Deploys the right controls to the right accounts. Generates evidence tagged to the right framework. ServiceNow receives evidence scoped to the correct domain, control, and regulation.

### Cross-Domain Aggregation

The Security Tooling Account (AWS) and Management Subscription (Azure) aggregate findings across all domains. This is where you get the enterprise-wide view:

- Which domains are compliant?

- Which controls are failing?

- Where are the telemetry gaps?

- Which detections haven't fired in 90 days (are they still valid)?

- Which policies have exceptions, and are those exceptions still justified?

That aggregation feeds ServiceNow dashboards, which feed board reports. The board sees a posture derived from running controls, not from a risk register that says "ongoing."

## 7. The DARPA Execution Layer — Missions, Not Roadmaps

I've written about the DARPA execution model before. Here's how it fits.

Each security domain runs missions, not roadmaps. A mission is time-boxed, outcome-measured, and killable.

Mission example: "Detect credential misuse in the payments domain in under 10 minutes."

The mission has:

- A 90-day time horizon

- A measurable outcome (detection latency, measured from pipeline telemetry)

- Explicit kill criteria (if detection latency hasn't improved by day 60, the approach is wrong — pivot or terminate)

- Artefacts in Git (detections, policies, test cases)

- Evidence in ServiceNow (detection firing metrics, false positive rates)

The mission owner has authority to choose tooling, author detections, and deploy — within the guardrails of the operating model (SCPs, policies, pipeline gates).

Missions that fail produce data. Data improves the next mission. This is not chaos. This is disciplined adaptability. Uncertainty at speed.

## 8. The Pen Test Loop — Autonomous with a Kill Switch

The pen test workflow runs inside the operating model, not outside it.

Architecture:

Every action logged. Every decision traceable. Every finding becomes a tracked vulnerability with a remediation pipeline. The pen test doesn't produce a PDF. It produces artefacts that feed directly into the same governance loop as everything else.

## 9. The Operating Model in One Sentence

Security intent is authored in a CLI, version-controlled in Git, validated and deployed through pipelines across multi-cloud estates, continuously generating machine-readable evidence that flows into ServiceNow for governance — turning security from a department into a property of the delivery system.

That's the bar.

The tools are here. The patterns are proven. Infrastructure-as-code did this for ops a decade ago. Policy-as-code did this for compliance three years ago. Detection-as-code is doing it for SecOps now.

The only thing missing is the operating model that ties them together across the real enterprise topology: multiple AWS accounts, multiple Azure subscriptions, multiple domains, multiple regulatory frameworks, and a ServiceNow instance that finally stops being a document store and starts being a governance engine fed by machines.

This is what I'm building. This is what I'm running. Not as a thought experiment. From the CLI. Every day.

Come build.

scottg/out

#ninjatheme #cybersecurity #securityascode #enterprisearchitecture #AWS #Azure #ServiceNow #DevSecOps #claudecode #CLI