Most security careers begin in security. Mine started two layers below that — writing application code, then operating the infrastructure that ran it.

That trajectory shapes how I approach every engagement today. I've shipped features under deadline, paged at 3am for failing services, and tuned the Linux kernels that production runs on. Security isn't an abstract concern when you've been the engineer responsible for the system staying up.

What follows is the journey — four disciplines, in the order I lived them, and what each one contributed to the way I do security work now.

LAYER 01 · FOUNDATION

Full Stack Engineer.

// where it started

Building software was my first profession and my first love. Frontend, backend, databases, APIs — the full vertical from user click to data persistence and back. I spent years writing the code that other people would later try to break.

Touching every layer of an application meant learning how data actually flows, where trust boundaries live, and how feature pressure shapes architecture decisions. It also meant learning what shortcuts engineers take when shipping deadlines collide with security ideals — because I took those shortcuts myself.

TOOLING ERA
PHP Go Python JavaScript VueJS REST APIs SQL Postgresql
// WHAT THIS TAUGHT ME ABOUT SECURITY

Most vulnerabilities aren't introduced by careless engineers — they're introduced by good engineers under pressure. Security advice that doesn't account for how software actually gets shipped will be ignored.

LAYER 02 · DELIVERY

DevOps Engineer.

// where code meets production

Then I became the one shipping it. CI/CD pipelines, build systems, deployment automation, infrastructure-as-code. I went from writing the features to making sure they could be delivered safely, repeatably, and at speed.

DevOps work taught me that the pipeline is the trust boundary. Every artifact, every credential, every secret in a build environment is part of the production attack surface. A signed binary is only as trustworthy as the system that signed it.

TOOLING ERA
GIT GitLab CI Github / GitHub Actions Jenkins ArgoCD Ansible Terraform
// WHAT THIS TAUGHT ME ABOUT SECURITY

Supply chain security isn't a separate domain — it's the underlying assumption everything else depends on. If your pipeline is compromised, your signing keys, scanners, and policies are theater.

LAYER 03 · OPERATIONS

Linux & SRE.

// where the system actually runs

From there I went deeper — into the kernel, the network stack, the filesystem. Linux administration, reliability engineering, observability. Running systems at scale and being on the hook when they failed at 3am.

SRE work changes how you think about every system. You learn that reliability and security are the same discipline viewed from different angles — both are about understanding failure modes, blast radius, and the operational realities of recovery. You learn that operability is a security property, because systems no one can debug are systems no one can defend.

TOOLING ERA
Ubuntu Server RHEL Kubernetes/Openshift systemd NFS HAProxy PAM CRI-O Docker
// WHAT THIS TAUGHT ME ABOUT SECURITY

A security control that breaks production at 3am will be disabled by Wednesday. Defensive engineering only works if it survives contact with on-call reality.

LAYER 04 · CURRENT

Cybersecurity Engineer.

// where everything converges

All of that became the foundation for security work. Threat modeling on systems I've shipped. Hardening clusters I've operated. Auditing pipelines I've built. Reading code from the inside of a developer's brain, infrastructure from the inside of an SRE's runbook.

Security at the cloud-native layer touches every other discipline at once — application logic, pipeline integrity, container runtime, kernel boundaries, network policy, identity. It's a domain that rewards people who've actually lived in those layers. Everything else is reading a map of a country you've never visited.

TOOLING ERA
PAM LUKS Kubernetes security OPA Gatekeeper MAC/DAC SELinux seccomp iptables/firewalld Vault Istio
// WHAT THIS LEADS TO

Security consulting grounded in twenty years of building, shipping, and operating what's being secured. Not advice from outside the system — engineering from inside it.

Four disciplines.
One perspective.

Banks InfoSec exists because security work is better when the person doing it has actually shipped the kind of system being secured. Every recommendation reflects what it costs to implement, what it changes about engineering velocity, and what tradeoffs were realistic in production.

That's the practice. That's the difference.

See what I offer
[ NEXT STEP ]

Have a stack that needs
this perspective?

Initial calls are free · No NDA required · Replies within 24h
Start an engagement