Senior Software Engineer · Cybersecurity Specialist · Professional Enabler of Unnecessary Complexity

I've spent 15+ years building software, securing infrastructure, debugging questionable decisions, and occasionally discovering that the questionable decision was mine.

My background spans software engineering, cloud security, SIEM/XDR, infrastructure hardening, secure development, and compliance across finance, healthcare, and other environments where "it works on my machine" is not an acceptable incident report.

I've helped secure systems handling sensitive health data, worked on infrastructure supporting thousands of gaming terminals, built and audited data-centre environments, and trained technical teams to operate a Security Operations Centre.

In other words, I've seen what happens when software meets reality. Reality usually wins the first round.

• Security engineering: Threat modelling, vulnerability remediation, secure SDLC, SAST/DAST, and the occasional uncomfortable conversation about risk.
• Malware analysis: Investigating suspicious binaries and behaviour to understand what a sample does, how it operates, and what it might compromise.
• Firmware analysis: Looking beneath the software layer to examine embedded systems, firmware behaviour, and potential security weaknesses. The device says it's fine. The device has not been peer-reviewed.
• Bug bounty and vulnerability research: Hunting for security flaws, validating findings, and responsibly reporting vulnerabilities. Breaking things is considerably more useful when you can explain why they broke.
• Cloud and infrastructure: AWS, Linux, IAM, hardening, Docker, and making misconfigured infrastructure slightly less enthusiastic about being compromised.
• Detection and response: CrowdStrike Falcon SIEM/XDR, IOC automation, incident-response planning, and SOC operations.
• Software engineering: Python, Go, TypeScript, JavaScript, backend systems, APIs, and automation.
• Security and compliance: ISO 27001, GDPR, security assessments, and helping technical reality coexist with compliance requirements.

Not every security problem comes with a dashboard, a vendor, or a conveniently worded alert.

I also spend time on the more investigative side of security:

• Malware analysis: Understanding suspicious code, execution behaviour, and potential indicators of compromise.
• Firmware analysis: Investigating the software embedded in devices, where security assumptions can get particularly creative.
• Bug bounty: Researching vulnerabilities in authorised targets, validating security impact, and helping turn findings into actionable fixes.

The goal isn't to call everything a vulnerability. It's to understand what actually happens, demonstrate the risk, and produce evidence that survives contact with someone asking, "Can you reproduce that?"

Because apparently solving the original problem wasn't enough.

• ThorCloud — Cloud-security risk management. Because cloud infrastructure apparently needed another way to tell us what we already suspected.
• Falcon-IoC — Automating IOC updates for CrowdStrike Falcon XDR. Repetitive security work is still repetitive work, even when it wears a threat-intelligence badge.
• DMARC Report Analyzer — Making email authentication reports less painful to investigate. XML was clearly not punishment enough.

• AWS to LocalStack — Bringing AWS development closer to a local environment, where mistakes are cheaper and the blast radius is mostly your own afternoon.
• SASPy — Slots accounting system protocol based on Python for arm architecture.
• SDSavior — Prolonging SD card and SSD disk life
• Soil Disturbance Detector — Little script to compare satellite images (from different dates) in order to detect ground soil disturbance for potential burial sites..
• ExistentialEgg - You feed it, it stares back, both of you question reality..

Browse my repositories for the latest experiments, utilities, and other evidence that having a perfectly reasonable idea is not a prerequisite for writing code.

Engineering philosophy: Build ridiculous things if you must. Build them properly. Document the sharp edges. Test the failure paths. Then check the logs before blaming the network.

Languages and development

Security and infrastructure

These are tools I've worked with, not a claim that I have achieved spiritual enlightenment in every ecosystem. The documentation remains open in another tab, as nature intended.

I've spoken about digital self-defence and secure development at security events, including BSides RedRocks. I also wrote an Ubuntu Server Hardening Playbook, because apparently "please configure your server securely" is not sufficiently actionable documentation.

I enjoy sharing what I've learned, helping other engineers build better systems, and exploring the boundary between "this is a terrible idea" and "this is a terrible idea, but the implementation is excellent."

Book a meeting · Connect on LinkedIn

Security, software engineering, cloud infrastructure, open-source projects, or a genuinely absurd technical idea with a surprisingly good engineering rationale are all acceptable conversation starters.

Bring evidence. Bring logs. If you bring a PowerPoint, at least make it reproducible.

Built with curiosity, excessive attention to detail, and the persistent suspicion that the bug is somewhere between the keyboard and the architecture diagram.