CISO Orchestrator

CISO Orchestrator

/ciso-orchestrator is the heavy program. It stands up an entire security organization in software: 9 leads, 30 sub-agents (39 named agents in total), plus runtime ghost and coverage agents that bring the active count past 40. Like the single agent, it holds a 90% fixing, 10% advisory mandate: every specialist writes the fix, and no vulnerability is reported and left open. Each agent has persistent memory, self-heal capability, project-context-aware analysis, industry-vertical APT simulation, and learning-aware routing from historical run outcomes. Reach for it before a major release, an audit, a funding event, or any time you need defensible, end-to-end coverage.

When to use it

The Senior Security Engineer is your daily driver. The orchestrator is the periodic deep program. It covers every section of the methodology (§0 through §24) and produces an attested compliance package built to survive a Big-Four audit.

The agent tree

Nine leads run their own teams. Seven leads run in Phase 1; two (pentest and compliance) run in Phase 2.

flowchart TD
  Orch[CISO Orchestrator]

  Orch --> TM[threat-modeler]
  Orch --> AC[appsec-code-auditor]
  Orch --> CI[cloud-infra-specialist]
  Orch --> SC[supply-chain-devsecops]
  Orch --> AI[ai-llm-redteam]
  Orch --> MS[mobile-security-specialist]
  Orch --> CP[crypto-pki-specialist]
  Orch --> PT[pentest-team]
  Orch --> GRC[compliance-grc]

  TM --> TM1[stride-pasta-analyst]
  TM --> TM2[attack-navigator]
  TM --> TM3[business-logic-attacker]
  TM --> TM4[privacy-flow-analyst]

  AC --> AC1[injection-specialist]
  AC --> AC2[auth-session-hacker]
  AC --> AC3[logic-race-fuzzer]
  AC --> AC4[serialization-memory-attacker]

  CI --> CI1[aws-penetration-tester]
  CI --> CI2[gcp-penetration-tester]
  CI --> CI3[azure-penetration-tester]
  CI --> CI4[k8s-container-escaper]

  SC --> SC1[dependency-confusion-attacker]
  SC --> SC2[cicd-pipeline-hijacker]
  SC --> SC3[artifact-integrity-analyst]

  AI --> AI1[prompt-injection-specialist]
  AI --> AI2[model-extraction-attacker]
  AI --> AI3[rag-poisoning-specialist]
  AI --> AI4[agentic-loop-exploiter]

  MS --> MS1[ios-security-auditor]
  MS --> MS2[android-penetration-tester]
  MS --> MS3[mobile-api-network-attacker]

  CP --> CP1[tls-certificate-auditor]
  CP --> CP2[algorithm-implementation-reviewer]
  CP --> CP3[key-management-lifecycle-analyst]

  PT --> PT1[pentest-web-api]
  PT --> PT2[pentest-infra]
  PT --> PT3[pentest-social]

  GRC --> G1[evidence-collector]
  GRC --> G2[compliance-gap-analyst]

Loading

Leads and their teams

Lead	Sub-agents
threat-modeler	stride-pasta-analyst, attack-navigator, business-logic-attacker, privacy-flow-analyst
appsec-code-auditor	injection-specialist, auth-session-hacker, logic-race-fuzzer, serialization-memory-attacker
cloud-infra-specialist	aws/gcp/azure-penetration-tester, k8s-container-escaper
supply-chain-devsecops	dependency-confusion-attacker, cicd-pipeline-hijacker, artifact-integrity-analyst
ai-llm-redteam	prompt-injection-specialist, model-extraction-attacker, rag-poisoning-specialist, agentic-loop-exploiter
mobile-security-specialist	ios-security-auditor, android-penetration-tester, mobile-api-network-attacker
crypto-pki-specialist	tls-certificate-auditor, algorithm-implementation-reviewer, key-management-lifecycle-analyst
pentest-team (Phase 2)	pentest-web-api, pentest-infra, pentest-social
compliance-grc (Phase 2)	evidence-collector, compliance-gap-analyst

Runtime ghost and coverage agents

Beyond the 39 named agents, the orchestrator spawns runtime ghost agents when Phase 1 surfaces a cross-domain correlation that needs a specialist not already running (for example, a RAG pipeline discovered mid-scan that pulls in the rag-poisoning-specialist). Cloud sub-agents are themselves selected by detected provider, so an AWS-only project does not waste a run on Azure. Coverage agents verify that every methodology section has an owner. This pushes the active agent count past 40 depending on what the codebase contains.

The 91-skill registry

Agents do not carry every capability at all times. They pull from a 91-skill registry (registry v1.6.0) on demand. A lead detects a need, calls ensure_skill, and the relevant deep skill loads into context. This keeps each agent lean while giving any agent access to elite, framework-specific depth (OWASP, MITRE, NIST, CIS, PCI, and more) the moment it is needed. Coverage of the registry is checked with verify_skill_coverage. See the orchestration tools in the MCP Tools Reference.

The three phases

flowchart LR
  P1[Phase 1<br/>Parallel discovery] --> P2[Phase 2<br/>Pentest + compliance]
  P2 --> P3[Phase 3<br/>Synthesis + attestation]

Loading

Phase 1: parallel discovery

Seven leads and their sub-agents run concurrently. They fingerprint the stack, threat-model it, audit the code, map cloud and supply-chain exposure, red-team any AI/LLM surface, review mobile and crypto, and write a shared threat model. This is breadth: every domain looked at by a dedicated specialist at the same time.

Phase 2: pentest and compliance

The pentest team reads the Phase 1 threat model as its attack brief and behaves like a motivated adversary with full knowledge: web and API exploitation, infrastructure privilege-escalation graphs, and social/insider scenarios derived from the project's real CI secrets and access patterns. In parallel, the compliance-grc lead maps every finding to controls and assembles evidence packages.

Phase 3: synthesis and attestation

All findings are merged, deduplicated (by ATT&CK technique plus location), and ranked by severity. The orchestrator produces the threat model, the risk register with SLA deadlines, the compliance report, and a signed attestation written into .mcp/reports/. Attestation only proceeds on a clean result; it refuses to sign over unresolved blocking findings.

The §0 to §24 coverage check

The methodology is divided into numbered sections, from foundational setup through threat modeling, application security, cloud and infrastructure, supply chain, crypto, AI/LLM, mobile, compliance, evidence, and risk. Before the orchestrator finalizes a run, the coverage check confirms each section §0 through §24 has been addressed by an owning agent. Any uncovered section is itself a finding, so the program cannot quietly skip a domain.