Tarik
Principal Security Engineer · Healthcare

Security engineering that developers actually use.

I work with developers, DevOps and infrastructure teams to secure systems, review vulnerabilities and check designs from a security perspective, then turn the answers into guardrails that scale.

Role
Principal Security Engineer
Works with
Developers, DevOps, infrastructure teams
Daily work
Vulnerability review, secure design review, hardening
Reads and writes
Python, Go, Bash
01

Technical skills

Eight areas of security work, each with the tools I reach for first. Open source where it is good enough, commercial where it earns its licence.

{{s.title}}

{{s.n}}

{{s.blurb}}

Open source
{{t.name}}
Commercial
{{t.name}}
02

Cultural hacks

Controls only work when people want to take part. This is how I socialize, gamify and entertain security into the way teams already work.

Socialize

Be a person before being a gatekeeper.

Open office hours. No agenda, no ticket. Anyone can bring a question, a worry or a half-finished design.

Security champions. One in every team, a network of peers rather than a police force.

Coffee before reviews. Trust built over lunch makes the hard review conversations easier.

Gamify

Make the secure path the fun path.

Internal CTFs. Challenges built from sanitised bug patterns in our own stack, so the skills transfer straight to daily work.

Leaderboards for fixes. Points for closing findings and helping others. We celebrate the fix and never name who introduced the bug.

Belt levels. Visible progress for security training, from white belt to champion.

Entertain

Teach through stories, not slide decks.

Live "how I would break this" demos. Fifteen minutes, one real weakness, one clear fix.

Breach whodunits. A public incident told as a detective story, with the lessons at the end.

A channel for fails and wins. Memes, near-misses and small victories, shared without blame.

03

Organizational things

How information flows in three directions: down to my team, up to leadership and across to peers.

Downward

My relationship with my team

Context over commands. I explain the why and the risk, then let people choose the how.

Blameless by default. Mistakes and incidents become learning, never blame.

Growth first. One-to-ones centre on careers and stretch work, and credit is given in public.

Protect focus. I absorb noise and politics so the team can do deep work.

Upward

What I report to my superiors

Top risks in business language. Impact, likelihood, owner and target date.

Trends, not raw counts. Coverage, time to remediate and the age of critical findings.

Compliance status. What is on track and what is at risk before the next audit.

Decisions I need. Budget, priorities and formal risk acceptances.

No surprises. Incidents and near-misses early, with what we know and what we do not.

Sideways

What I share with my peers

Lessons learned. Sanitised findings from incidents and design reviews.

Reusable assets. Guardrails, templates, playbooks and detection rules.

Early heads-up. New policies or deprecations that touch their roadmap.

Clear asks. Where I need their help and which dependencies I carry.

Stays inside
Open vulnerability details, personal data and anything under need-to-know.