title: CloudSlash - Execution Lifecycle Reference description: From credential to completed remediation, here is every step the engine takes: and why the order matters. A single cs scan or cs daemon cycle passes through ...

Execution Lifecycle¶

From credential to completed remediation, here is every step the engine takes: and why the order matters.

Overview¶

A single cs scan or cs daemon cycle passes through six ordered stages:

Credential Discovery → Plugin Bootstrap → Graph Construction → Analysis Pipeline → Verdict Assignment → Output / Remediation

Phase 1: Credential Discovery¶

CloudSlash resolves credentials using the standard provider chain for each cloud. The order of precedence is:

1. CLI flags (--region, --profile)
2. Environment variables (AWS_PROFILE, GOOGLE_APPLICATION_CREDENTIALS, etc.)
3. ~/.cloudslash/config.yaml cloud: block
4. Provider-native defaults (~/.aws/credentials, ~/.kube/config, etc.)

When no credentials are found for a provider, the engine logs a warning and skips that provider. It does not fail. This allows mixed environments where only some providers are configured.

Plugin Bootstrap¶

The daemon discovers plugins from ~/.cloudslash/plugins/ and launches each as a gRPC subprocess:

Engine → fork → cloudslash-plugin-aws (gRPC server on random port)
Engine → fork → cloudslash-plugin-gcp
Engine → fork → cloudslash-plugin-k8s

Each plugin implements the CloudProvider gRPC service:

service CloudProvider {
  rpc GetMetadata(MetadataRequest) returns (MetadataResponse);
  rpc Scan(ScanRequest) returns (stream ResourceChunk);
  rpc Remediate(RemediationRequest) returns (RemediationResponse);
}

Plugins stream ResourceChunk messages back to the engine as they discover resources. There is no buffer-and-return. Nodes appear in the graph as they arrive.

Phase 2¶

User Authorization (Devi)

As ResourceChunk messages arrive, Devi inserts them into the Universal Graph: an in-memory directed graph where:

• Nodes are cloud resources (EC2 instances, GKE clusters, RDS databases, K8s pods, …)
• Edges are typed relationships (AttachedTo, SecuredBy, FlowsTo, Contains, Grants)

Swarm AIMD Concurrency¶

Plugin RPCs run concurrently through the Swarm orchestrator. Worker count starts at NumCPU and adapts:

• Success → add one worker (additive increase)
• 429 Rate Limit → halve the pool (multiplicative decrease)

This maximizes API throughput without hardcoded delays.

Ghost Linking¶

After all plugins finish, the Ghost Linker runs a cross-provider pass. It compares CIDR blocks, ARNs, and resource IDs across all providers to discover edges that no individual plugin can see. For example, an AWS Transit Gateway route table entry pointing to a GCP VPC.

Analysis Pipeline¶

The graph passes through three parallel analyzers:

Heuristics (Devi)¶

Evaluates CEL rules against each node's property map. A node that matches a rule with severity >= 10 is marked is_waste = true and assigned a waste_reason.

# Example built-in heuristic
- name: idle_ec2
  expression: "node.type == 'aws_instance' && node.metrics.cpu_p99_7d < 2.0"
  severity: 10

Phase 4¶

State Reconciliation

Runs network reachability proofs on the graph using Dinic's Maximum Flow algorithm. Computes risk_score (0–100) for each node based on:

• Internet → Database reachability
• HMM-based spot instance termination probability
• API error rate correlation
• Blast radius depth

PolicyMesh (CEL Governance)¶

Evaluates all loaded CEL policy rules against each node. Violations influence the final verdict and can block s.a.u remediation.

Verdict Assignment¶

Each node receives a single verdict based on the pipeline results, evaluated in priority order:

Output / Remediation¶

The pipeline terminates differently depending on the interface:

Remediation Pipeline (s.a.u)¶

Flagged resources can be promoted through the remediation Kanban:

Flagged → Analyzed → Codegen → s.a.u Gate → Pending → Applied → Purged

Before any action executes, s.a.u validates:

1. TOCTOU guard: resource state hasn't changed since analysis
2. Blast radius: no downstream dependencies would break
3. Reversibility: a compensating rollback action exists
4. Policy gate: no enforcing CEL rule blocks the action

Every completed action is logged in the audit ledger and can be reverted with cs revert.

Summary¶

cs scan --region us-east-1 --format=sarif --fail-on=critical
         │
         ├─ Discover credentials (env vars → config.yaml → provider defaults)
         ├─ Bootstrap plugins (gRPC subprocesses)
         ├─ Stream resources → Devi Universal Graph (Swarm AIMD concurrency)
         ├─ Ghost Linker cross-provider edge discovery
         ├─ Heuristics + Oracle + PolicyMesh (parallel)
         ├─ Verdict assignment (priority cascade)
         └─ SARIF output → exit 1 if critical findings