Building a Security Engineering Platform from Scratch

I’ve been thinking a lot about security tooling lately. Not the kind where you bolt on a scanner at the end and hope for the best, but something more integrated into how we actually build software.

So I’m starting to build a unified security engineering platform. This is very much a work in progress, but I wanted to share what I’m working on and why.

The Problem I’m Trying to Solve

Most teams I’ve worked with have security tools scattered everywhere. There’s one tool for scanning code, another for containers, something else for cloud infrastructure. Each one sends alerts to a different Slack channel, and nobody has a complete picture of what’s actually going on.

The bigger issue is that security feels like an obstacle course at the end of development rather than something woven into the process. Developers get told their code has problems right before deployment, when it’s most expensive to fix.

I think we can do better.

What I’m Building

I’ve been mapping out a platform that organizes security into five phases that mirror how software actually gets made. I put together a visual representation of the architecture that shows how these phases connect.

View the Live Platform Architecture

The five phases break down like this:

Strategy & Planning is where security should really start. I’m looking at threat modeling tools that help teams think through risks before writing any code. This is about making security decisions at the whiteboard, not in production.

Secure Development focuses on catching problems early, right on the developer’s machine. Think secret scanning and static analysis that runs locally, not just in CI. The goal is to give developers immediate feedback while they’re still in their IDE.

Automated Verification uses the CI/CD pipeline as an automated security reviewer. Instead of security being a manual gate, it becomes part of the automated checks every pull request goes through. This includes scanning source code, dependencies, and infrastructure as code.

Supply Chain Trust is about establishing what’s actually running in production. I want to generate SBOMs and sign container images so we have a clear chain of custody tracking exactly which version of what code is deployed where.

Active Defense uses runtime security, particularly eBPF-based observability, to detect attacks that traditional logging would miss entirely. This is about having real-time visibility into what’s actually happening in production.

Where I Am Now

Right now I’m in the early stages. I’ve been mapping out the architecture and thinking through how these different capabilities should connect to each other. The visualization I built helps me think about the flow and where the integration points need to be.

The next step is actually building out the integrations and testing whether this approach holds up in practice. I’m particularly interested in exploring AI-assisted remediation next. Instead of just telling developers what’s wrong, what if the platform could suggest fixes or even open pull requests with solutions? That feels like where this could get really useful.

Why Share This Now

Honestly, I’m sharing this partly to hold myself accountable and partly because I’m curious how other people are thinking about this problem. If you’re working on security tooling or dealing with similar challenges, I’d love to hear what’s working for you and what isn’t.

This is just the beginning, but I’m excited to see where it goes.