Skip to main content

AWS Demo — Talk Track (Nimbus Cloud)

Audience: AWS cloud security engineer, SRE manager, or CISO on a 20-minute call. Tenant: nimbus-cloud — display name "Nimbus Cloud (AWS)" in the UI dropdown. Source: live AWS scan of Nimbus Cloud Lab 1 (account 087380083467, region us-east-2) via sv0-aws scan from sv0-connectors/integrations/aws/.

Note (2026-04-19): The earlier synthetic seed tenant demo-aws (from scripts/seed-demo-aws.ts) was retired because the seed script produced entities and findings but zero authority paths — a GRANTS vs HAS_PERMISSION_SET mismatch with the path materializer. Tracked in the follow-up issue; post-demo cleanup. For 2026-04-21 the demo runs against live-scan data on nimbus-cloud (slug was demo-nimbus at that date; renamed 2026-05-19 per SecurityV0/sv0-platform#1203).

The demo tells four canonical governance stories. Everything else in the UI is supporting evidence. Do not walk path inventory — lead the tour from the Overview ranking.

Setup (60 seconds)​

  1. Open /overview with tenant header nimbus-cloud (display: "Nimbus Cloud (AWS)").
  2. Frame the environment: "Nimbus runs customer support, ops automation, and analytics on AWS. Organic growth — the cloud footprint expanded faster than the access model was tightened."
  3. Point to the Strategic Context card. This is the posture-level read: which cluster matters most, why now.

Story 1 — "The ops agent can reboot any server"​

Why first: destructive authority on the production fleet, actively exercised. Highest real blast radius in the seed.

Where: Overview → Dangerous Blast Radius cluster → nimbus-ops-monitor (Bedrock agent) → nimbus-ops-remediation-lambda.

Line: "This AI agent can reboot any EC2 instance and run arbitrary shell commands through SSM. Wildcard resource scope. It has executed in the last 30 days."

Evidence to click into:

  • Authority path shows ec2:RebootInstances * and ssm:SendCommand *
  • Execution count > 0 in the last 30 days
  • Team-owned but no individual accountable owner

Remediation framing: scope the IAM policy to specific instance tags; require change-management approval for destructive actions.

Story 2 — "A departed contractor's Lambda can still exfiltrate customer PII"​

Why: the "orphan you forgot about" risk. Ownership collapsed five months ago; authority survived.

Where: Overview → Orphaned Sensitive + Dormant External clusters → nimbus-customer-data-export → nimbus-data-export-lambda.

Line: "Kevin Davis built this Lambda and left the company five months ago. Nobody inherited ownership. The function still has read access to the nimbus-customer-data table and an egress path to an external vendor endpoint — and it has been dormant for 5 months, which means the authority is standing, not exercised."

Evidence to click into:

  • orphaned_sensitive finding on the Lambda (no owner)
  • dormant_external finding on the egress path (0 executions in 30d, last run ~5 months ago)
  • PII classification on the target DynamoDB table

Remediation framing: disable the Lambda or reassign ownership through your ticketing system; re-enable only with a new approval.

Story 3 — "The support Lambda holds Salesforce credentials it does not need"​

Why: the permission-to-exercised-authority gap. Active workload, but half its credential footprint is never touched. This is the story you tell from the authority-path evidence directly — it does not currently fold into a dedicated cluster.

Where: Authority Paths → filter on nimbus-create-support-ticket → open the two USES paths (→ cred-servicenow and → cred-salesforce).

Line: "The support Lambda legitimately uses ServiceNow to file tickets — that's its job. It also holds credentials for Salesforce, and the 30-day execution evidence shows it never touches them. The authority is standing. If someone compromises this Lambda, they inherit both credentials, not just the one the job actually needs."

Evidence to click into:

  • Authority paths from the Lambda to both credential stores (both present in the current seed)
  • The workload itself is non-dormant — the support Lambda shows 8 invocations over the last ~20 days at the workload level
  • Both credential-bound paths read path-level execution count 0 in the current seed, because the seeded CloudTrail-style evidence is keyed to Lambda/workflow resources, not to Secrets Manager credentials

Remediation framing: remove the Salesforce secret from the Lambda's IAM role; re-attach only if a new use case appears.

How to narrate honestly: deliver this story from the authority graph plus application context — "this Lambda files ServiceNow tickets; Salesforce is not part of its job" — rather than from a path-level execution delta. The UI cannot currently show a clean Salesforce-vs-ServiceNow execution asymmetry, because path-specific execution evidence on Secrets Manager destinations is not seeded (and, on real tenants, not yet wired through CloudTrail Phase 2 — sv0-connectors #66). Say this out loud if asked; the point of the story is the excess authority, not the observed execution gap.

Known limitation: this story does not currently map to a dedicated risk cluster. Both credentials are seeded at baseline so scope_drift does not fire; the parent workload is active so dormant_authority does not fire at the workload level; and no finding exists today for "credential held but never exercised." sv0-platform #415 tracks the dedicated unused_credential_holdings cluster, a new unused_credential_grant finding type, and a seed fix (move the Salesforce USES edge from sync 1 to sync 2) so the drift variant of the story becomes clusterable after next sprint.

Story 4 — "A vendor can read the entire account without ExternalId or MFA"​

Why: cross-account trust misuse — the highest-leverage real-world incident pattern, and the one AWS SREs immediately recognize.

Where: Overview → (cross-account authority) → nimbus-vendor-audit-access role.

Line: "Seven months ago, an auditor was granted a cross-account role with AWS-managed ReadOnlyAccess across the entire account. The trust policy does not require ExternalId and does not require MFA. Today, anyone who can assume that role reads every resource — including Secrets Manager metadata."

Evidence to click into:

  • Cross-account trust policy (no sts:ExternalId, no aws:MultiFactorAuthPresent condition)
  • Role age (7 months)
  • Authority breadth (ReadOnlyAccess covers every service)

Remediation framing: add an ExternalId condition and MFA condition to the trust policy; scope ReadOnlyAccess down to the specific services the vendor reviews.

Known limitation to acknowledge if asked: a dedicated trust-policy-violation evaluator rule is on the post-demo roadmap. The story is narratable today via the role's authority breadth and cross-account edge; the dedicated rule will elevate it as a first-class finding.

Closing read (60 seconds)​

Return to /overview. "Four stories, not thirteen paths. The product decides what matters; the operator decides what to fix first." Then hand off to Q&A.

What to avoid​

  • Don't walk the Authority Paths table top-to-bottom — it inverts the point of the demo.
  • Don't use the word "likely" when showing execution evidence. The seed has deterministic counts.
  • Don't describe findings as "LLM egress" when the egress category is credential_store — that was the April-10 bug and it's fixed (#414). If a screen still says that, refresh the tenant.
  • Don't promise multi-account support; the synthetic tenant is single-account by design. Multi-account org scan is tracked in sv0-connectors #57.

Known gaps for the customer call (be ready to speak to)​

GapStatusPost-demo path
CloudTrail execution evidence on real accountsPhase 1 spike landed (sv0-connectors #66); Phase 2 wires it into the CLIW1.3 close-out
Path-level execution evidence on credential destinationsNot seeded; not yet wired (CloudTrail Phase 2 covers the connector side)sv0-connectors #66
Multi-account org scanConfig-ready, executor not shippedsv0-connectors #57
Dedicated unused_credential_holdings clusterNarratable from authority graph + application context today (no cluster surface, no path-level evidence)sv0-platform #415
Trust-policy and iam:PassRole evaluatorsDetected through authority breadth todayNext sprint
AWS-native remediation vocabulary (ARN/action specifics)Generic platform language todayNext sprint

References​

  • Canonical stories: docs/plans/2026-04-part-1-sprint/2026-04-10-sergey-feedback-on-aws-demo-product-gaps.md §Core feedback 1
  • Live scan: sv0-connectors/integrations/aws/ — sv0-aws scan --all --regions us-east-2 --tenant-id nimbus-cloud --platform-url https://app.securityv0.com --submit (AWS SSO profile sv0-demo-labs-1-IF-AdministratorAccess — profile name reflects the AWS account, which retains its sv0-demo-lab-1 name)
  • Synthetic seed reference (currently broken, post-demo fix): sv0-platform/scripts/seed-demo-aws.ts
  • AWS integration guide: docs/integrations/aws/index.md
  • Org-mode bootstrap: docs/integrations/aws/org-mode-bootstrap.md