From Infrastructure to Open Source: Lessons Learned Building 4 Security & Automation Tools

oleg-vdv — Fri, 24 Jul 2026 00:47:58 +0000

Coming from a strong sysadmin and infrastructure background, I spent years managing servers, networks, and keeping systems alive. Over time, I realized a fundamental truth: the most dangerous system risks are often the ones you don't even have visible inventory for.

That mindset naturally led me into the world of open source. I started building tools to solve real-world problems around API governance, edge safety, data integrity, and automation.

Here is what I’ve been building in public, what each project taught me, and why these areas matter today:

1. Governing LLM & API Traffic: AI-Gateway

As AI applications move to production, controlling model access, enforcing limits, and monitoring traffic becomes critical.

The Project: AI-Gateway — A lightweight proxy layer designed to secure, route, and manage API requests and policies for AI services.
Key Lesson: Security in the AI era isn't just about firewall ports; it's about context-aware policy management and dynamic traffic control.

2. Safety at the Edge: AffectGuard-HRI

Moving machine learning onto edge devices and microcontrollers opens up huge potential for robotics, but it introduces strict real-time safety constraints.

The Project: AffectGuard-HRI — An open-source framework tailored for human-robot interaction, focusing on real-time safety, intent tracking, and affective monitoring.
Key Lesson: Edge AI demands extreme efficiency. You can't rely on cloud latency when dealing with physical robotic hardware—safety loops must run reliably at the hardware level.

3. Verifiable Data & Audit Trails: ProofByte

In modern SecOps, logging isn't enough—you need verifiable proof of data integrity for compliance and auditing.

The Project: ProofByte — A lightweight tool aimed at data validation, cryptographic verification, and maintaining tamper-evident audit trails.
Key Lesson: Building trust in distributed workflows requires cryptographic validation at every step of the pipeline.

4. Modern Workflow Governance: AutoGov

Processes in enterprise environments often break down due to manual bottlenecks and fragmented oversight.

The Project: AutoGov — An automation and workflow governance engine built to streamline standard operating procedures and administrative checks.
Key Lesson: Good automation doesn't replace governance—it bakes governance into the infrastructure so compliance happens by default.

What’s Next?

Transitioning from maintaining infrastructure to building developer tools in public has been an incredible learning experience.

I’d love to hear from the community: What is your biggest pain point right now when securing edge devices or managing AI API endpoints?

Feel free to check out the repos, leave stars if you find them useful, or open issues/PRs! Let’s connect! 🚀

The post-quantum deadlines are closer than your roadmap thinks — so I built a CBOM scanner

oleg-vdv — Fri, 17 Jul 2026 00:55:53 +0000

Three regulatory clocks are already ticking:

US: EO 14412 / CNSA 2.0 requires post-quantum cryptography for new national-security acquisitions from 2027 — and explicitly names the "cryptographic bill of materials" (CBOM).
UK: NCSC wants full cryptographic discovery and a migration plan by 2028.
EU: member states start transitioning from the end of 2026.

Yet when an auditor asks the first, most basic question — "where exactly does your codebase use RSA?" — almost nobody can answer. Not because it's hard conceptually, but because nobody ever had a reason to keep an inventory of their cryptography. Now there's a reason.

What "harvest now, decrypt later" actually means

Even if a cryptographically relevant quantum computer is a decade away, traffic recorded today can be decrypted then. If your secrets have a shelf life of more than a few years (medical records, financial data, government contracts), classical key exchange is already a liability. That's the logic behind the deadlines — they don't wait for the quantum computer to exist.

One command, three artifacts

I wanted the discovery step to cost one command instead of one consulting engagement:

npx @proofbyte/pqc-radar scan . --cbom cbom.json --report report.md --sarif findings.sarif

This walks the repository and flags quantum-vulnerable cryptography — RSA, ECC/ECDH, DH, DSA, Curve25519, legacy hashes, weak TLS configs — across Java, Python, JavaScript/TypeScript, Go, C#, Rust, Ruby, PHP, C/C++ and nginx/Apache configs. Out come three artifacts:

cbom.json — a CycloneDX 1.6 CBOM: the machine-readable inventory the mandates ask for;
report.md — a human-readable report: every finding with file:line and its ML-KEM (FIPS 203) / ML-DSA (FIPS 204) migration target;
findings.sarif — SARIF 2.1.0, so findings land straight in GitHub code scanning.

It's fast enough to live in CI: hashicorp/vault (4,827 files) scans in about 9 seconds; a weekly corpus workflow re-scans five well-known OSS projects to catch regressions.

Checking live endpoints, not just code

Code is half the story — the other half is what your servers actually negotiate:

npx @proofbyte/pqc-radar scan-tls your-api.example.com github.com

One TLS handshake per host (no payload sent) reports the protocol, cipher, key-exchange group and certificate key — and whether the endpoint already speaks hybrid post-quantum key exchange (X25519+ML-KEM-768). One honesty detail I'm proud of: when the local TLS stack can't name the negotiated group (older OpenSSL builds can't name hybrid groups), the result is reported as inconclusive, not as a finding. Unknown ≠ vulnerable.

What the v0 honestly can't do

Detection is line-pattern based. That makes it fast, broad and dependency-free, but:

it will miss dynamically constructed crypto calls;
unusual code can false-positive;
absence of findings is not proof of absence — the report says so explicitly.

A deep AST engine (integrating PQCA CBOMkit, which covers Java and Python) is the next milestone. There's also a fun war story: the very first regression test caught the scanner's regexes matching their own source code — the fix was masking pattern literals with character-class tricks (RSA_generate_ke[y]), and a permanent guard test asserting the repo only ever flags its own fixtures.

Security posture

This is a tool you're supposed to run on code you can't share, so: fully offline (the scan command makes zero network calls), zero runtime dependencies, read-only, symlinks not followed. scan-tls is the single network feature and touches only endpoints you name. It's MIT-licensed — read the source rather than trusting this paragraph.

Try it

npx @proofbyte/pqc-radar scan .

GitHub: https://github.com/oleg-vdv/proofbyte (issues and PRs welcome — especially new language patterns with fixtures)
CI one-liner: uses: oleg-vdv/proofbyte@v1

I'd genuinely like to hear from anyone whose org has already been asked for a CBOM — by whom, and what format they accepted.

DEV Community: oleg-vdv