S Luis Meeting · Mission ControlSBC-AutoOps · security-buyer walkthrough
session 00:00 meeting in set date → 0%

The meeting is the security review.

CONFIRMED: Monday June 15, 11:00-11:30 AM EDT (17:00 CET). 30 minutes. Luis Rios + Philip. serverAuth EKU enforcement begins that same day. Philip's frame to Luis: "We are not after a yes. We want your honest take on where this is thin or wrong."

We read SBC configs before deploy and tell you exactly what will break. We never touch the SBC, never need the network, and your configs never leave your environment. Everything we claim is verifiable in the source.

Game plan: run the meeting, don't ride it.

Click a phase as you enter it. The timer keeps you honest against the 30-minute shape.

Meeting clock
00:00
Pre-flight (do these before the call)
The 30-minute shape — click the phase you're in

Honor the frame, then the problem

First beat: "Philip promised you we want the honest take, hold us to that." Then: every business call crosses an SBC; one misconfiguration and calls fail silently. serverAuth EKU enforcement begins TODAY, the day of this call; cert lifetimes hit 47 days by 2029. The migrations never stop.

2 min

Where the data goes — lead with it

Walk the #security contract panel on screen before he asks. Inbound: one signed channel. Outbound: nothing. Opt-in defined field by field. Zero outbound network.

3 min

Live demo

Broken walk → BLOCK → fixed → PASS. Then simulate, explain, fleet. Script on the Demo Runbook tab, verified green tonight.

10 min

Verify, don't trust

Build-from-source, SHA-256 manifest, SBOM, pip-audit in CI, cosign-signed images, the pinned key in plain Python.

5 min

The ask

Design partnership. One real, sanitized config per vendor. In exchange: a 2026-migration readiness audit across their whole mixed-vendor fleet, air-gapped, inside their environment.

5 min

Their questions

Security Q&A tab is loaded. If you don't know: "I'd rather check the source than guess" is on-brand.

5 min

Opening: win it before the demo.

The frame, the problem, and the two sentences that disarm a security reviewer.

The one-sentence frame (memorize)

We read SBC configs before deploy and tell you exactly what will break. We never touch the SBC, never need the network, and your configs never leave your environment. Everything we claim is verifiable in the source.

The problem, 2 minutes

  • Every business call crosses an SBC — the fragile, multi-vendor gateway between the network and the carrier.
  • Failure is silent. One-way audio, dead trunks, hours of repair, and you hear it from users, not a dashboard. You cannot monitor a call that is cryptographically blocked from ever starting.
  • Today, June 15: serverAuth-only EKU enforcement begins the day of this call. The root-CA hard deadline already passed in March; unpatched peers drop.
  • It never stops: cert lifetimes compress 398 → 200 → 100 → 47 days by 2029. ~8 renewals a year per SBC. Manual validation stops scaling. This is the cadence, not the climax.

The security-buyer disarm (say early)

  • Honor Philip's frame first: "Philip told you we are not after a yes, and he meant it. The most useful thing you can do today is tell us where this is thin or wrong." Critique invited up front beats critique extracted later.
  • "Before I show you anything, let me answer the question you're paid to ask: where does the data go?" Then walk the contract panel.
  • "Don't trust the image — build it from source on your side." There is no pre-built artifact we ask anyone to trust.
  • "The engine refuses to guess." Where a config format cannot prove a fact, domains stay silent and say verify out-of-band. A wrong verdict is the one thing a pre-deploy control cannot afford.
  • "It's ~4,700 lines with one dependency. Your team can read the whole trust path in an afternoon."

The data-flow contract, verbatim.

Mirror of the #security panel — what you walk on screen in phase 2. Every row maps to a source file.

INBOUND · one channelA signed rule bundle. Nothing else. Versioned, Ed25519-signed, verified before use against a publisher key pinned in source (rules/client.py), deliberately not environment-overridable. Compiled-in freshness floor refuses rollback; inbound reads capped at 8 MB. Configs never travel this channel. They can verify a bundle themselves: python -m sbc_validator.tools.fetch_ruleset checks the signature before writing a byte.

OUTBOUND · defaultNothing. No telemetry, no call-home, no update check. docker run --network none is the documented production mode: zero outbound network required to run.

OUTBOUND · opt-inAnonymized findings, only with --share-anon. Schema sbc-anon/1: check IDs, severities, vendor family, ruleset version, salted non-reversible org token. Excluded by construction: config text, locators, FQDNs, CN/SAN, IPs, file paths, free text. The allowlist is 32 lines in report/anonymize.py — offer to read it live.

RUNTIMEAir-gapped and unprivileged. Container drops to non-root (uid 10001). ~4,700 lines, 29 modules, one runtime dependency (cryptography); pcap reader, rule client and dashboard server are hand-rolled on the standard library.

contract as of 2026-06-10 · engine v0.16.4 · rules/client.py · report/anonymize.py · Dockerfile

Verify-don't-trust artifacts (phase 4)

  • Build from source: full tree + SHA-256 manifest (240 files). sha256sum -c SHA256SUMS, then docker build on their side. Nothing pre-built to trust.
  • SBOM: CycloneDX at docs/sbom-cyclonedx.json — the validator, cryptography, and its two transitive deps. That's the whole list.
  • pip-audit runs in CI on every push — the "audits clean" claim is continuously enforced, not a snapshot.
  • Images are cosign-signed (keyless Sigstore, from v0.16.2 — signed tonight, release green). Verify command is in docs/SECURITY.md.
  • Run modes if they ban Docker: plain pip install . on Python 3.10+; fully-offline wheel install (--no-index); rootless Podman runs the OCI image identically.

Demo runbook — verified green 2026-06-10, 22:50.

All 9 commands passed the dry run (172/172 tests). Copy buttons ready; check off as you execute live.

sbc-validator walk samples/walkthrough/sbc-teams-01-broken.ini
→ 5-stage walk, ends BLOCK + fix list
sbc-validator walk samples/walkthrough/sbc-teams-01-fixed.ini
PASS — ready for the 2026 CA migration
sbc-validator simulate samples/audiocodes_min.ini --ruleset rulesets/ms_direct_routing_2026-06.json
NO_CONNECT (dies at TLS handshake) + SIP ladder
sbc-validator explain samples/one_way_audio.pcap
→ ONE_WAY_AUDIO + domain-D fix line
sbc-validator fleet samples --ruleset rulesets/ms_direct_routing_2026-06.json
→ "7 of 13 SBCs ready" + verdict table
# or just type it into the scanner page on screen:
sip.pstnhub.microsoft.com
→ grade A, ms_reference verified. "We grade Microsoft against Microsoft's own requirements. Now let's look at yours."
sbc-validator serve --results results
→ http://127.0.0.1:8787 · console + /walk both 200 at dry run

requires dockerThe air-gap proof, if asked

docker build -t sbc-validator .
docker run --rm --network none -v "$PWD/samples:/work" sbc-validator \
  validate /work/audiocodes_teams_real.ini --ruleset rulesets/ms_direct_routing_2026-06.json
→ completes with NO network. The whole claim, falsified or proven in one command.

Fallback ladder if Docker misbehaves live (rehearsed, in order):

  • 1 · Your scrollback. You ran the proof pre-call; the output is already in the terminal. Scroll up: "ran it twenty minutes ago, here is the run."
  • 2 · CI, third-party verified. Open the v0.16.2 Release run on GitHub: the air-gapped smoke step runs --network none against the published image on every release. Stronger than a live run: it is not your machine.
  • 3 · The serve walkthrough. Real engine, locally, no containers: sbc-validator serve → Walkthrough tab runs the actual broken→fixed validation live.

"Can I run it on MY machine?" — the four paths, step by step

Every path starts the same way: send him ~/Desktop/SBC-Delivery/sbc-validator-0.16.4-src.tar.gz and quote the SHA-256 from DELIVERY-NOTE.md in the email body. Then whichever path matches his shop:

shasum -a 256 sbc-validator-0.16.4-src.tar.gz # compare to the hash in the email
tar -xzf sbc-validator-0.16.4-src.tar.gz && cd sbc-validator-0.16.4
shasum -a 256 -c SHA256SUMS # 106 files, every one against the manifest
python3 -m venv .venv && .venv/bin/pip install . # one dependency: cryptography
.venv/bin/sbc-validator demo
→ the full 7-SBC mixed-vendor showcase on his machine. Clean-machine verified 2026-06-11.
# on a connected box:
pip download . -d wheels/
# carry wheels/ across the gap, then on the isolated box:
pip install --no-index --find-links wheels/ sbc-autoops-validator
docker build -t sbc-validator . # or: podman build, identical
docker run --rm --network none sbc-validator demo
→ non-root (uid 10001), zero network. The air-gap claim, proven on his hardware.
# drop-in pipeline example ships at examples/ci/sbc-pre-deploy-gate.yml:
sbc-validator validate config.ini \
  --ruleset rulesets/ms_direct_routing_2026-06.json --fail-on review
→ non-zero exit blocks the PR before a non-compliant config reaches the change window.

SSOT answer if asked: all four paths write the identical audit artifact, results/<sbc>/<timestamp>.json, history-preserving. In containers mount it out (-v "$PWD:/work" ... --out /work/results); in CI upload results/ as the pipeline artifact. Every report (HTML, exec, fleet, compliance) is a rendering of those files.

Public-window bonus: once the repo is public he can skip the tarball entirely — git clone github.com/Dicoangelo/sbc-validator and run Step 0's manifest check against the clone.

Security reviewer Q&A — answer + proof, every time.

Click to expand. Each answer ends with the file that proves it; offering to open the file live is the power move.

Honest answers, pre-loaded.

The awkward ones. Answering these unprompted-fast is what builds trust with this profile.

"Was there ever a key in your repo?"

Yes: a dev-only throwaway signing key, committed early, rotated June 7 to an offline keypair, and the git history was rewritten this week so it is gone from every commit. The pinned verifier key never had its private half in the repo. If their tooling diff-audits the history, the rotation commit says exactly this.

Depth gaps, stated up front

  • Cisco / Ribbon / Oracle routing + security depth stays silent until validated against a real config for that vendor. That is the design-partner ask, not a hidden gap.
  • Metaswitch Perimeta: the adjacency-CLI export does not carry trust store, cert, or codec policy inline, so those domains stay silent and the report says verify out-of-band.
  • Per-config cipher matching and live probing stay silent until validated. The tool refuses to guess.

Hosted scanner concerns

  • Edge-only, unauthenticated — one outside-in TLS handshake against a public hostname.
  • SSRF-guarded and rate-limited (12/min/IP); refuses private, loopback, link-local, reserved ranges.
  • Stores grade + check IDs only, never hostnames. And it is optional — the product is the air-gapped validator.

"Who else runs it?"

Honest answer: you would be a design partner, first cohort. That is the deal — one sanitized config per vendor buys validated depth on your exact platforms, and you get the fleet audit. Early means leverage: your platforms become the best-covered ones.

The ask: two design partners.

Say it plainly, then stop talking.

We are partnering with one or two MSPs or enterprises running 50+ SBCs. We need one real, sanitized config per vendor: that is what turns routing and security checks live for that platform, the same path that made AudioCodes real.

In exchange: a 2026-migration readiness audit across your entire mixed-vendor fleet, run air-gapped inside your environment, before the next failure finds you.

Objection handling

  • "Sanitized how?" — Strip IPs, hostnames, secrets; we need the structure and parameter grammar, not identifiers. We can walk their engineer through it on a call.
  • "What do we risk?" — Nothing leaves their environment; the config goes to us once, sanitized, under whatever NDA they prefer. The engine itself never transmits.
  • "Why not just wait?" — The June EKU enforcement is days away and the 2027/2029 compressions are scheduled. Early partners shape which vendors get depth first.

Close + next steps

  • Agree the pilot shape on the call if possible: which vendors, how many boxes, who sanitizes.
  • Send same-day follow-up: SECURITY.md, the #security link, and the exact sanitization checklist.
  • If he needs internal review first: offer the screenshot-able panel + SBOM + SHA256SUMS as the review package.

Drill: fast answers win security meetings.

Random Q&A under the clock. Aim to land each answer inside 45 seconds, proof file included.

clock 45s passed 0 · failed 0 · skipped 0
Press Start. Questions are weighted toward the ones you've missed.

Luis intel — fill from Philip, then live on the call.

Everything auto-saves locally. Export at the bottom when the meeting ends.

Known going in (from Philip's intro, 2026-06-11)
  • Luis Rios. Works in mixed-vendor estates and owns the cybersecurity side of them. Philip: "that is exactly the read we want."
  • Pre-read he received: the site (from Philip), then your reply-all with the briefing PDF, deck PDF, all five site links, and the 6-file repo audit map. Repo public since June 11; assume he has read rules/client.py and SECURITY.md.
  • The frame he was given: "We are not after a yes on Monday. We want your honest take on where this is thin or wrong. Fifteen minutes of your experience beats any deck." Run the meeting inside that frame.
  • Still unknown (fill below): cloud vs on-prem, containers allowed or banned, formal vendor review process, estate vendors and box count.

Profile

Company / role / industry

SBC estate (vendors, box count)

Posture

Containers

Formal vendor review process?

Live notes

What he reacted to

Commitments / next steps

Questions I couldn't answer

The team — builder and domain, one product.

Two co-founders, two halves of the same claim: the engine is verifiable and the domain knowledge is lived.

ARCHITECT-OPERATOR
Dico Angelo
SBC-AutoOps • 2026
Dico Angelo
Founder, METAVENTIONS AI • Product & Engineering
CO-FOUNDERBUILDS THE ENGINE
5
Vendor Parsers
8
Validation Domains
172
Tests in CI
1
Runtime Dependency
Core abilities
Systems Architecture
AI & Agentic Systems
Partner Operations
Supply-Chain Security
Special abilities
METAVENTIONS AI Air-gapped by design Ed25519 + cosign pipeline AWS & Microsoft Accredited $800M deal-reg pipeline ops
DOMAIN AUTHORITY
Philip Drammeh
SBC-AutoOps • 2026
Philip Drammeh
AI Operations • Telecom Architecture • Ex-Microsoft, Ex-Ericsson
CO-FOUNDEROWNS THE DOMAIN
25+
Years Telecom & Cloud
2M+
Users Scaled
100+
Carrier Partners
60+
Markets
Core abilities
Telecom Architecture
AI Operations
Platform Scale
Carrier Ecosystem
Special abilities
Ex-Microsoft (Teams calling platform) Ex-Ericsson Published AI researcher 45% faster incident analysis AIOps advisory • drammeh.ai
What we've built — every figure verifiable in the repo
v0.16.4
Engine
5
Vendors, One Model
8
Validation Domains
172
Tests in CI
4
Run Paths
0
Outbound Network
1
Dependency
~7K
Lines of Python

Plus the proof layer: Ed25519-signed rule bundles against a source-pinned key, SHA-256 integrity manifest, CycloneDX SBOM, pip-audit in CI, cosign-signed releases, and a one-page data-flow contract at sbcvalidator.metaventionsai.com/#security.

Arsenal — every asset, one click.

Open these before screen-sharing.

Live surfaces

Proof files (open live if challenged)

  • ~/Desktop/SBC-Delivery/ — send-ready source tarball (328K, engine-only) + SHA-256 + paste-ready run instructions. If he asks "can I run it myself?": "I'll send it to you right now." Clean-machine verified this morning.
  • sbc_validator/rules/client.py — pinned key, freshness floor, verify-before-use
  • sbc_validator/report/anonymize.py — the 32-line allowlist
  • docs/SECURITY.md — the forwardable contract
  • docs/sbom-cyclonedx.json — runtime SBOM
  • SHA256SUMS + scripts/integrity-manifest.sh
  • Dockerfile — non-root, --network none doc

Numbers that must come out right

  • 172 tests in CI, three Python versions · 5 vendors, one model · 8 validation domains
  • ~4,700 lines, 29 modules, 1 runtime dependency · uid 10001 non-root
  • Cert lifetimes: 398 → 200 (Mar 2026) → 100 (2027) → 47 days (2029), ~8 renewals/yr
  • 7 required 2026 roots; the DigiCert G5 pair is the live trap · v0.16.2 image cosign-signed