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.
Click a phase as you enter it. The timer keeps you honest against the 30-minute shape.
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.
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.
Broken walk → BLOCK → fixed → PASS. Then simulate, explain, fleet. Script on the Demo Runbook tab, verified green tonight.
Build-from-source, SHA-256 manifest, SBOM, pip-audit in CI, cosign-signed images, the pinned key in plain Python.
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.
Security Q&A tab is loaded. If you don't know: "I'd rather check the source than guess" is on-brand.
The frame, the problem, and the two sentences that disarm a security reviewer.
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.
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
All 9 commands passed the dry run (172/172 tests). Copy buttons ready; check off as you execute live.
Fallback ladder if Docker misbehaves live (rehearsed, in order):
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:
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.
Click to expand. Each answer ends with the file that proves it; offering to open the file live is the power move.
The awkward ones. Answering these unprompted-fast is what builds trust with this profile.
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.
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.
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.
Random Q&A under the clock. Aim to land each answer inside 45 seconds, proof file included.
Everything auto-saves locally. Export at the bottom when the meeting ends.
Company / role / industry
SBC estate (vendors, box count)
Posture
Containers
Formal vendor review process?
What he reacted to
Commitments / next steps
Questions I couldn't answer
Two co-founders, two halves of the same claim: the engine is verifiable and the domain knowledge is lived.
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.
Open these before screen-sharing.