I studied cybersecurity at Fanshawe College before I wrote my first
pipeline. That order matters more than it sounds like it should: I entered
the workforce already thinking about attack surface, access control and
failure modes, and it shows up in the defaults I reach for. Least privilege
in every IAM policy. Network topology that starts from what
shouldn't be reachable. Trivy gating the build rather than just
flagging it.
IT support and QA at Keel Digital is where that training met real production
systems. I built JMeter suites against rate limiting, RBAC and authorization
boundaries, added Nessus scanning to the Compose stack for monthly
compliance scans, and found a critical vulnerability in a registration API
before it shipped. That stretch taught me how APIs actually behave under
pressure and where security assumptions quietly fall apart once tested.
DevOps took it further. Knowing the traffic patterns and service
dependencies from the QA side shaped how I build pipelines, how I scoped
the bare-metal migration, and how I designed our SIEM's log ingestion.
I've since contributed to a FedRAMP Moderate authorization (300+ NIST
SP 800-53 controls, third-party assessment, continuous monitoring), which
is about as unforgiving a proving ground as compliance work gets.
The cybersecurity-to-QA-to-DevOps path means fewer blind spots. I'm looking
for DevOps or DevSecOps work where that combination counts, somewhere the
security and compliance requirements are real rather than aspirational.