guy@secdev.uk

Rust Security Code Review Guide

Sat, 04 Apr 2026 00:00:00 +0000

1. Introduction

I put this guide together as a structured approach to security-focused code review for Rust applications. Whether you’re just starting to identify security vulnerabilities in Rust code or you’re an experienced developer looking for a language-specific checklist, I’ve tried to make it useful at both levels.

Rust’s ownership model, borrow checker, and type system prevent entire classes of bugs, use-after-free, null pointer dereferences, and data races in safe code. However, what I found when I started reviewing Rust codebases is that unsafe blocks, third-party crate choices, and application-level logic errors still introduce serious vulnerabilities. What follows covers manual review strategies, common anti-patterns, recommended tooling, and vulnerability patterns organised by class, with cross-references to the intentionally vulnerable examples in this project.

The New Shape of the Engineering Team

Mon, 30 Mar 2026 00:00:00 +0000

If AI can handle the boilerplate, the scaffolding, and a growing portion of routine implementation, what does that mean for how we compose engineering teams? It’s a question I’ve been turning over for a while now, and the answers I keep arriving at are uncomfortable.

The optimistic version is that AI frees engineers to focus on higher-value work, system design, problem framing, user understanding, architectural thinking. The pessimistic version is that it eliminates the entry-level work that junior engineers have traditionally used to learn the craft. The realistic version is probably somewhere in between, and navigating it well is one of the most important challenges facing technical leaders right now.

Vintage Adventures - MOS 6502 - Part 2

Sat, 28 Mar 2026 00:00:00 +0000

In Part 1 we covered the MOS 6502’s architecture, walked through its instruction set, and decoded a small test program by hand. That gave us the basic structure of a CPU emulator:

while running:
    opcode = memory[PC]
    instruction = decode(opcode)
    instruction.execute(operands)
    PC += instruction.length

The pseudocode is clean, but there are obvious pieces missing. We need to define the decode function, implement the execution logic for each instruction, and emulate both the memory and the registers. Time to turn that sketch into real code.

Rethinking Developer Productivity in the Age of AI Assistants

Mon, 23 Mar 2026 00:00:00 +0000

Lines of code per day was always a terrible productivity metric. With AI coding assistants, it’s become an absurd one. An engineer with Copilot or a similar tool can generate code at a pace that would have been unimaginable five years ago. If you’re measuring productivity by volume, every engineer just got a 3x raise. If you’re measuring it by value delivered, the picture is more complicated.

The more I’ve explored how AI assistants change engineering workflows, the more I’ve realised that the productivity conversation needs a fundamental reset. We’re not just doing the same work faster, we’re changing what the work is.

Vintage Adventures - MOS 6502 - Part 1

Sat, 21 Mar 2026 00:00:00 +0000

This next set of posts are a bit of a distraction from security themes articles, and we’ll explore some vintage computer hardware.

The MOS 6502 is a classic CPU that drove the home computer revolution in the late 1970s and early 1980s. Along with the Zilog Z80, it brought computing to the masses. The 6502 powered some of the most iconic machines of the era, the Apple II, the Commodore 64, the Atari 2600, and the British-built BBC Micro, among others. It even found its way into the original Nintendo Entertainment System (as the Ricoh 2A03, a modified 6502).

The AI Literacy Gap: Why Your Leadership Team Needs to Catch Up

Mon, 16 Mar 2026 00:00:00 +0000

With the emergance of AI/GenAI, I felt that I needed to think, and write, about the impact of AI/GenAI on technology leadership. The next series of articles will be exporing this topic. As an emerging topic, these articles may well be shorter, and I will try and publish them weekly when possible.

Most engineering leadership teams I talk to have a wide spread of AI understanding. On one end, you’ve got the enthusiasts, they’ve built agents, they use AI coding assistants daily, they can explain transformer architectures over a pint. On the other end, you’ve got leaders who haven’t meaningfully engaged with any of it. They’ve read the headlines, they’ve sat through a vendor demo, and they’re quietly hoping this is a hype cycle that will pass.

Memory Safety Without Rust: Defensive C and C++ Patterns

Sat, 14 Mar 2026 00:00:00 +0000

I hear “just rewrite it in Rust” a lot these days, and while Rust’s ownership model genuinely does eliminate entire classes of memory safety bugs at compile time, that advice ignores reality. The vast majority of systems code – operating systems, embedded firmware, database engines, network stacks – is written in C and C++ and will remain so for decades. Rewriting is not always an option. So I wanted to dig into the defensive patterns, compiler features, and runtime tools that bring memory safety closer to C and C++ codebases without a language migration. What I found is that while none of these approaches match Rust’s compile-time guarantees, the combination of them makes a real difference.

Rust Learning Guide - Anti-Patterns

Wed, 11 Mar 2026 00:00:00 +0000

Overview

The antipatterns.rs module Source Code File demonstrates 15 common Rust mistakes and their correct solutions. I put this together because I noticed the same patterns coming up, especially from developers (myself included) fighting the borrow checker instead of working with it.

Anti-Patterns Covered

1. Unnecessary .clone() Everywhere

❌ Cloning to avoid borrow checker
✅ Use references (&T) instead

2. Using .unwrap() in Production

❌ Crashes program on error
✅ Return Result<T, E> and handle gracefully

3. Returning References to Local Variables

❌ Dangling references (won’t compile)
✅ Return owned data or use ‘static lifetime

4. Using String When &str Would Work

❌ Forces caller to own String
✅ Accept &str - works with both

5. Ignoring Compiler Warnings

❌ Unused mut, unused variables
✅ Listen to the compiler

6. Using Indices Instead of Iterators

❌ C-style loops can panic
✅ Use iterators - safer and clearer

7. Manually Implementing What Traits Provide

❌ Manual equality checks
✅ #[derive(PartialEq, Debug, Clone)]

8. Using Vec When Array Would Work

❌ Heap allocation for fixed-size data
✅ Use arrays [T; N] for stack allocation

9. Nested match/if let Instead of Combinators

❌ Deeply nested matching
✅ Use .map(), .filter(), .and_then()

10. Using Mutex When Not Needed

❌ Mutex in single-threaded code
✅ Just use regular variables

11. Collecting Iterator Just to Iterate Again

❌ Unnecessary intermediate collection
✅ Chain iterators directly

12. Using Deref Coercion as Inheritance

❌ Simulating inheritance with Deref
✅ Use composition explicitly

13. Panicking in Library Code

❌ panic!() crashes caller’s program
✅ Return Result and let caller decide

14. Using format! When to_string() Works

❌ Overkill for simple conversions
✅ Use .to_string() for clarity

15. Implementing Default Manually

❌ Manual new() constructor
✅ Implement Default trait

Key Principle

Work WITH Rust’s ownership system, not against it.

Deserialization Attacks: From Pickle to ObjectInputStream

Sat, 28 Feb 2026 00:00:00 +0000

Deserialization vulnerabilities are some of the scariest bugs in application security, because when they’re exploitable, it’s almost always remote code execution. The core problem is that an application reconstructs objects from untrusted data without validating what types are being instantiated. In languages with powerful serialization mechanisms – Python’s pickle, Java’s ObjectInputStream, PHP’s unserialize – an attacker can craft serialized payloads that execute arbitrary code during the deserialization process itself. The more I researched how these attacks work across languages, the more I appreciated how a single API call can turn into a full server compromise.

The Anti-Patterns That Kill Teams

Mon, 23 Feb 2026 00:00:00 +0000

Most team dysfunction isn’t unique. It follows recognisable patterns that repeat across organisations, industries, and decades. The good news is that if you can name the pattern, you’re halfway to fixing it. The bad news is that most leaders don’t recognise the patterns until the damage is well advanced.

Osmani catalogues these anti-patterns extensively, and I’ve encountered most of them across my career. Here are the ones that I’ve seen do the most damage, organised by where they originate.

CORS Misconfiguration: The Open Door You Didn't Know About

Sat, 14 Feb 2026 00:00:00 +0000

CORS misconfiguration is one of those vulnerabilities that keeps coming up because most developers don’t fully understand what CORS actually does. It’s the browser mechanism that controls which websites can make requests to your API. When it’s configured correctly, it prevents malicious sites from stealing data through a victim’s browser. When it’s misconfigured, and this happens constantly based on public bug bounty reports, it effectively disables the Same-Origin Policy, letting any website read authenticated responses from your API. What makes CORS misconfigurations particularly interesting to study is that they’re invisible to users, silent in server logs, and trivial to exploit.

Rust Learning Guide - Core Concepts Explained

Fri, 06 Feb 2026 00:00:00 +0000

I put this guide together to explain each Rust concept demonstrated in the example programs, with comparisons to C and Java. The more I dug into Rust’s design decisions, the more I appreciated how much thought went into making safety guarantees that don’t cost you performance. Here’s what I found.

Supporting Code Examples

1. OWNERSHIP SYSTEM

What it is: Rust’s core memory management system. Every value has a single owner, and when the owner goes out of scope, the value is dropped (freed). This was the concept that took the longest to click for me, but once it did, everything else fell into place.

Culture Is What You Do When Things Go Wrong

Mon, 02 Feb 2026 00:00:00 +0000

Every company I’ve worked at had values written down somewhere. Integrity. Innovation. Collaboration. Respect. They were on the website, in the onboarding deck, sometimes literally on the walls. And in most cases, they told you almost nothing about what it was actually like to work there.

Culture isn’t what you say you value. It’s what you do, especially when things go wrong. Ines Sombra puts it perfectly: “Culture is what happens when what we want to believe about ourselves is challenged. Culture is what we do when we get things wrong, when we witness a violation of trust, or when we stay silent when an inappropriate comment is said in our presence.”

XXE Attacks: XML Parsing Gone Wrong

Sat, 31 Jan 2026 00:00:00 +0000

XML External Entity injection is one of those vulnerabilities that fascinated me the more I dug into it. The core issue is that the XML spec supports external entities, a feature that lets XML documents pull in content from external sources, and most parsers enable this by default. When an app parses untrusted XML without disabling that feature, an attacker can read arbitrary files off the server, perform SSRF, and sometimes even get remote code execution. What surprised me most when researching this was how straightforward the exploitation is compared to how long these bugs survive in production, the attack payloads are simple, but the parser defaults are so permissive that developers often have no idea the risk exists.

Secrets in Source Code: Finding and Eliminating Hardcoded Credentials

Sat, 17 Jan 2026 00:00:00 +0000

Hardcoded credentials are one of the most common and most preventable vulnerability classes out there. API keys, database passwords, encryption keys, and service tokens embedded directly in source code end up in version control, build artifacts, container images, and log files. Once a secret reaches a Git repository, it persists in the history even after the offending line is deleted. When I started researching how often this happens in practice, the numbers were staggering, public reports of leaked credentials on GitHub alone run into the millions per year. In this post I’ll cover the patterns that lead to hardcoded secrets, the tools that detect them, and the architecture changes that eliminate them for good.

Scaling Your Team Without Breaking What Works

Mon, 12 Jan 2026 00:00:00 +0000

I lived through this at a growth start-up where the engineering team tripled in under two years. At fifteen people, we were fast, aligned, and effective. Everyone knew what everyone else was working on. Decisions happened in hallway conversations. The culture was strong because it was small enough to be transmitted through proximity.

At forty-five people, almost none of that was true. Communication had broken down. New hires didn’t understand the culture because nobody had time to transmit it. Decisions that used to take minutes now took weeks because the number of stakeholders had multiplied. We were bigger, but we weren’t better, and for a painful period, we were actively worse.

Go Learning Guide

Tue, 06 Jan 2026 00:00:00 +0000

A structured learning guide for developers coming from Java, C, or Python who want to learn Go. I put this together because when I started learning Go myself, I kept wishing for a resource that mapped Go’s idioms back to languages I already knew. Github Repo of Code Examples

Introduction to Go

Go (also called Golang) was created at Google in 2009 by Robert Griesemer, Rob Pike, and Ken Thompson. It was designed to address the challenges of building large-scale, concurrent software systems while keeping the language simple and productive.

String Formatting and Security: A Cross-Language Minefield

Sat, 03 Jan 2026 00:00:00 +0000

String formatting is one of those operations that’s everywhere, and it’s more dangerous than most developers realise when user input gets involved. Every language provides multiple ways to build strings from dynamic data, and each mechanism carries different security implications. From C’s printf family, where a format string bug can read and write arbitrary memory, to Python’s f-strings that can execute attribute lookups, the attack surface is broader than most people think. I wanted to map out the full landscape across languages, and what I found was that each mechanism breaks down in its own unique and sometimes surprising way.

Running Effective Retrospectives (and Actually Following Up)

Mon, 22 Dec 2025 00:00:00 +0000

Retrospectives should be the engine of continuous improvement. In practice, they’re often the meeting everyone tolerates but nobody values, a ritual performed out of obligation rather than conviction, producing sticky notes that get photographed and forgotten.

I’ve run hundreds of retrospectives over the years, and I’ve wasted more of them than I’d like to admit. The ones that worked had a few things in common. The ones that didn’t were all failing in the same ways.

SAST Tools Compared: What They Catch and What They Miss

Sat, 20 Dec 2025 00:00:00 +0000

Static Application Security Testing (SAST) tools are the first line of automated defence against vulnerabilities in source code. They analyse code without executing it, looking for patterns that match known vulnerability classes. But here’s the thing, no single tool catches everything, and the differences between tools in detection capability, false positive rates, and language support are significant. I wanted to understand exactly where the gaps are, so I spent time running these tools against intentionally vulnerable code and comparing their output. This post is my honest assessment of what they actually catch, what they miss, and where manual review has to pick up the slack.

The Art of the Subtle Bug: Nuanced Vulnerabilities That Evade Review

Sat, 06 Dec 2025 00:00:00 +0000

The vulnerabilities that cause real breaches are rarely the textbook examples. They’re the ones that survive multiple rounds of code review, pass SAST scans, and sit in production for years. The more I researched these nuanced bugs, the more I realised what makes them dangerous: they exploit assumptions reviewers make about language behaviour, framework internals, or data flow boundaries. This post dissects the patterns that make a vulnerability subtle and walks through real examples that show why even experienced reviewers still miss them.

Designing Good Process (Without Becoming a Bureaucracy)

Mon, 01 Dec 2025 00:00:00 +0000

Engineers hate process. Or rather, engineers hate bad process, and most process they encounter is bad. It’s imposed from above without understanding the problem it’s meant to solve. It adds overhead without adding value. It treats every situation the same regardless of risk or complexity. No wonder the word “process” makes people flinch.

But the absence of process isn’t freedom, it’s chaos. Having worked in both process-light start-ups and process-heavy corporates, I’ve seen both failure modes up close. The start-up where nobody knew how deployments worked because there was no documented process. The corporate where deploying a one-line change required three approvals and a change advisory board meeting. Neither extreme serves the team.

JavaScript Security: Prototype Pollution to Supply Chain Attacks

Sat, 22 Nov 2025 00:00:00 +0000

JavaScript is the one language I can never escape, it’s on both sides of the web. In the browser it handles user interaction and DOM manipulation, and on the server Node.js powers APIs, microservices, and build tools. This dual nature creates an attack surface that’s uniquely challenging to secure. Browser-side JavaScript faces XSS, DOM clobbering, and postMessage abuse. Server-side JavaScript faces prototype pollution, dependency confusion, ReDoS, and the vast npm ecosystem where a single malicious package can compromise thousands of applications. In this post, I want to walk through the JavaScript-specific anti-patterns that keep coming up, from the prototype chain manipulation that poisons every object in the runtime to the regex that freezes your server.

Outcomes Over Outputs: Measuring What Matters

Mon, 10 Nov 2025 00:00:00 +0000

Early in my career, I inherited a team with a beautiful dashboard. Every metric was green. Velocity was up. Story points completed per sprint were trending in the right direction. Code coverage was above the target. Release frequency was on schedule. By every measure on that dashboard, the team was performing brilliantly.

The product they were building had almost no users.

That was my introduction to what Osmani calls the watermelon effect, metrics that look green on the surface but are red underneath. The team was producing outputs at an impressive rate. They just weren’t producing outcomes that mattered.

C++ Security: Smart Pointers Aren't Always Smart Enough

Sat, 08 Nov 2025 00:00:00 +0000

The more I dug into C++ codebases, the more I noticed a recurring assumption: developers who think that switching to smart pointers and STL containers means they’re safe from memory bugs. C++ adds RAII, smart pointers, containers, and type-safe abstractions on top of C’s manual memory model, and these features genuinely eliminate many of C’s most common vulnerabilities, std::string prevents buffer overflows, std::unique_ptr prevents memory leaks, and std::vector provides bounds-checked access via .at(). But C++ also introduces new attack surfaces that turn out to be even trickier to spot: dangling references from moved-from objects, iterator invalidation, implicit conversions in template code, and the false sense of security that comes from using “safe” abstractions incorrectly. In this post, I want to cover the C++-specific anti-patterns that survive code review because they look correct to developers who trust the standard library.

C Security: Manual Memory Management and Its Consequences

Sat, 25 Oct 2025 00:00:00 +0000

C gives you direct control over memory allocation, pointer arithmetic, and hardware interaction. I respect that. But that control comes with absolutely no safety net: no bounds checking, no garbage collection, no type safety beyond what you enforce manually. Every buffer overflow, use-after-free, double-free, format string vulnerability, and null pointer dereference in C is a direct consequence of this design. C remains the language of operating systems, embedded systems, and performance-critical libraries, so its security pitfalls affect every layer of the software stack. When I started digging into the patterns behind C vulnerabilities, the same shapes kept appearing, from the textbook strcpy overflow to the subtle integer promotion that bypasses a bounds check. Let me walk through them.

Python Security Code Review Guide

Wed, 22 Oct 2025 00:00:00 +0000

1. Introduction

I put this guide together as a structured approach to security-focused code review for Python applications. Whether you’re just starting to identify security vulnerabilities in Python code or you’re an experienced developer looking for a language-specific checklist, I’ve tried to make it useful at both levels.

Python’s dynamic typing, rich standard library, and extensive third-party ecosystem make it enormously productive, but the more I reviewed Python codebases, the more I realised these same qualities introduce security pitfalls that static analysis alone cannot always catch. What follows covers manual review strategies, common anti-patterns, recommended tooling, and vulnerability patterns organised by class, with cross-references to the intentionally vulnerable examples in this project.

The Case for Team Stability

Mon, 20 Oct 2025 00:00:00 +0000

There’s a persistent belief in engineering organisations that moving people between teams is healthy, it spreads knowledge, prevents silos, and keeps things fresh. I understand the appeal. I’ve also watched it destroy team effectiveness more times than I can count.

The research is clear, and my experience confirms it: stable teams outperform shuffled ones. Not by a little, by a lot. And the reasons are rooted in how humans actually build trust and develop working relationships, not in how org charts look on a slide.

Rust Security: When unsafe Breaks the Promise

Sat, 11 Oct 2025 00:00:00 +0000

I love Rust. I genuinely do. Its ownership system, borrow checker, and type system wipe out entire classes of vulnerabilities at compile time, use-after-free, double-free, data races, null pointer dereferences, buffer overflows. But here’s the thing: Rust gives you an escape hatch called unsafe, and when it’s used incorrectly, it reintroduces every single vulnerability that Rust was designed to prevent. The more I dug into real-world Rust codebases, the more I found this happening. Beyond unsafe, Rust has its own quirky set of security pitfalls: integer overflow behaviour that differs between debug and release builds, FFI boundaries that trust C code unconditionally, and logic errors that the type system simply cannot catch. In this post, I want to walk through the Rust-specific anti-patterns that break the safety promise.

Onboarding That Goes Beyond Setting Up a Dev Environment

Mon, 29 Sep 2025 00:00:00 +0000

At one company I joined, my onboarding consisted of a laptop, a Confluence page titled “Getting Started,” and a Slack message saying “let us know if you need anything.” At another, I had a structured first week with an assigned buddy, a schedule of introductions, and a 30/60/90-day plan. The difference in how quickly I became effective was enormous, and it had almost nothing to do with the technical setup.

Go Security: Goroutines, Error Handling, and Hidden Bugs

Sat, 27 Sep 2025 00:00:00 +0000

Go’s simplicity is its greatest strength and, I’d argue, its most dangerous security property. The language has no exceptions, no generics-based abstractions (until recently), and no implicit behaviour, everything is explicit. But that explicitness creates its own class of vulnerabilities: unchecked errors that silently skip security validation, goroutine races on shared state, HTTP client defaults that follow redirects into internal networks, and string handling patterns that bypass input validation. In this post, I want to walk through the Go-specific anti-patterns that lead to security vulnerabilities, from the error that nobody checked to the goroutine that corrupted the authentication cache. The more I dug into Go’s security landscape, the more I realised these bugs are subtle precisely because the language feels so straightforward.

Java Security: From Spring Boot Misconfigs to Deserialization

Sat, 13 Sep 2025 00:00:00 +0000

Java has this reputation for being “safe” because of its type system, managed memory, and mature ecosystem. The more I’ve dug into Java security, the more I think that reputation is misleading, and honestly, a bit dangerous. Java’s security pitfalls aren’t about buffer overflows or memory corruption. They’re about the language’s powerful runtime features: deserialization, reflection, JNDI lookups, expression languages, and the Spring framework’s convention-over-configuration philosophy that silently enables dangerous defaults. In this post I want to walk through the Java-specific anti-patterns that lead to remote code execution, data leaks, and authentication bypasses, from the classic ObjectInputStream gadget chain to the Spring Boot actuator endpoint that can expose entire environments.

Hiring for Values, Abilities, Then Skills

Mon, 08 Sep 2025 00:00:00 +0000

Most engineering interviews are backwards. We spend the majority of our time evaluating technical skills, the thing that’s easiest to teach and quickest to develop, and almost no time evaluating values and abilities, which are much harder to change and far more predictive of long-term success.

I’ve made this mistake myself, repeatedly. I’ve hired brilliant engineers who turned out to be terrible collaborators. I’ve passed on candidates who weren’t the strongest technically but would have been exactly what the team needed. The more I’ve hired across start-ups and corporates, the more convinced I’ve become that we need to flip the order.

Python Security Pitfalls Every Developer Should Know

Sat, 30 Aug 2025 00:00:00 +0000

I’ve spent a lot of time reviewing Python codebases, and the language’s readability and rapid development cycle are exactly what make it dangerous. Python is the default choice for web services, data pipelines, and automation scripts, and that same ease of use hides security pitfalls that experienced developers walk into regularly. The language’s dynamic nature, runtime evaluation, duck typing, implicit conversions, and powerful serialization, creates attack surfaces that simply don’t exist in statically typed languages. In this post, I want to cover the Python-specific anti-patterns that lead to real vulnerabilities, from the well-known pickle deserialization trap to the subtle template injection that can survive code review.

What Actually Makes an Engineering Team Effective

Mon, 18 Aug 2025 00:00:00 +0000

I spent the early part of my career believing that team effectiveness was mostly about talent. Get the best engineers, give them interesting problems, and get out of the way. It’s an appealing theory, and it’s wrong, or at least, it’s missing the most important part.

Google’s Project Aristotle studied 180 teams and ran 35 statistical models to find what made some teams effective and others not. The finding that surprised everyone, including Google, was that who was on the team mattered far less than how the team worked together. Individual talent, seniority, even team size, none of these were the primary drivers.

Race Conditions

Sat, 16 Aug 2025 00:00:00 +0000

Race conditions (CWE-362) are, in my opinion, the most insidious class of security bugs you’ll encounter. They occur when the behaviour of a program depends on the relative timing of concurrent operations, and at least one of those operations modifies shared state. The window between a check and a subsequent use of the checked value, the classic time-of-check to time-of-use (TOCTOU) pattern, is the most exploited form, but races also show up in counter increments, balance updates, session management, and file operations. What makes race conditions uniquely dangerous is their non-determinism: the bug may not manifest in thousands of test runs, then appear under production load when two requests arrive within microseconds of each other. I want to walk through race conditions in Python, Go, Java, and Rust, from the obvious unprotected counter to the subtle channel-based ordering assumption that passes every test but fails under contention.

Integer Overflow

Sat, 02 Aug 2025 00:00:00 +0000

Integer overflow (CWE-190) is one of those bugs that I find endlessly fascinating because of how quietly destructive it is. It happens when an arithmetic operation produces a value that exceeds the maximum (or falls below the minimum) representable value for the integer type. In C and C++, signed integer overflow is undefined behaviour, the compiler is free to assume it never happens, and optimizations built on that assumption can eliminate bounds checks entirely. Unsigned overflow wraps around silently. Go and Java define overflow as wrapping (two’s complement), which prevents undefined behaviour but still produces incorrect results that lead to security vulnerabilities: undersized allocations, bypassed length checks, and negative indices into arrays. Rust panics on overflow in debug mode but wraps in release mode by default, creating a gap between testing and production behaviour that caught me off guard when I first started digging into Rust’s safety guarantees. I want to walk through integer overflow across C, C++, Rust, Go, and Java, from the textbook multiplication overflow to the subtle cast truncation that can survive expert review.

The Accidental Manager: Leading When You Didn't Plan To

Mon, 28 Jul 2025 00:00:00 +0000

Not every manager chose to be one. Sometimes the team grows around you and suddenly you’re the most senior person. Sometimes your manager leaves and someone needs to fill the gap. Sometimes the company is too small to hire a dedicated manager, and you’re the engineer who seems most capable of doing it alongside your technical work.

However it happens, you find yourself managing people without ever having made a deliberate decision to pursue management. And the question you’re left with is: now what?

Null Pointer Dereference

Sat, 19 Jul 2025 00:00:00 +0000

Null pointer dereference (CWE-476) is one of those bugs that shows up across every language, and the more I researched it for this post, the more I was struck by how much damage it can do depending on context. The consequences vary dramatically: C programs crash with a segfault (or worse, the kernel maps page zero and an attacker gets code execution), C++ invokes undefined behaviour that the compiler may optimise into literally anything, Go panics with a nil pointer dereference that kills the goroutine or the whole program, and Java throws a NullPointerException that can crash the app or leak stack traces to an attacker. MITRE ranks CWE-476 consistently in the top 25 most dangerous software weaknesses, and digging into the CVE data, that ranking is well deserved. I want to walk through C, C++, Go, and Java here, from the obvious unchecked malloc return to the subtle nil interface trap in Go and the conditional path where null silently propagates through multiple function calls.

Java Security Code Review Guide

Wed, 09 Jul 2025 00:00:00 +0000

1. Introduction

I put this guide together as a structured approach to security-focused code review for Java applications. Whether you’re just starting to identify security vulnerabilities in Java code or you’re an experienced developer looking for a language-specific checklist, I’ve tried to make it useful at both levels.

Java’s strong type system, managed memory, and mature ecosystem offer many safety guarantees, but the more I researched Java security, the more I realised the language and its frameworks still expose developers to a wide range of pitfalls including injection, deserialisation, reflection abuse, JNDI injection, and misconfigured XML parsers. What follows covers manual review strategies, common anti-patterns, recommended tooling, and vulnerability patterns organised by class, with cross-references to the intentionally vulnerable examples in this project.

When You Miss Writing Code

Mon, 07 Jul 2025 00:00:00 +0000

There’s a particular kind of melancholy that hits engineering managers around the six-month mark. You’re in your fourth meeting of the day, you’ve just spent an hour on a spreadsheet, and you glance over at your team, heads down, headphones on, deep in the flow state you remember so well. And you think: I miss that.

I still feel it. After all these years, there are days when I’d trade every meeting on my calendar for four uninterrupted hours with a codebase and a problem to solve. The feeling doesn’t go away. But understanding it, what it actually is, and what to do with it, makes it manageable.

Use After Free

Sat, 05 Jul 2025 00:00:00 +0000

Use-after-free (CWE-416) is one of those bug classes that I wanted to understand deeply because it keeps showing up at the root of high-profile exploits. It occurs when a program continues to use a pointer after the memory it references has been freed. The freed memory may be reallocated for a different purpose, and the dangling pointer now reads or writes data that belongs to a completely different object. Attackers exploit this by controlling what gets allocated into the freed slot, replacing a data buffer with a crafted object that contains a function pointer, then triggering the dangling pointer to call through it. Reading through CVE databases, use-after-free is at the root of hundreds of browser exploits, kernel privilege escalations, and server compromises. This post covers C and C++, from the obvious free-then-use to the subtle shared-pointer aliasing and callback registration patterns that can evade expert review.

Out-of-Bounds Writes

Sat, 21 Jun 2025 00:00:00 +0000

Out-of-bounds writes (CWE-787) are the single most dangerous class of memory corruption vulnerabilities on the SANS/CWE Top 25, and they’ve held that position for years. The reason is clear once you dig into the mechanics: writing past the end of a buffer can overwrite return addresses, function pointers, vtable entries, and adjacent heap metadata, giving attackers arbitrary code execution. Unlike higher-level languages where the runtime catches array index violations, C and C++ silently corrupt memory, and the consequences may not manifest until thousands of instructions later. Even Rust, with its ownership model, is vulnerable when unsafe blocks bypass the borrow checker. In this post I’ll dissect out-of-bounds writes in C, C++, and Rust, from the classic strcpy overflow to the subtle off-by-one in pointer arithmetic that can survive expert review.

Finding Your Leadership Style

Mon, 16 Jun 2025 00:00:00 +0000

For years, I tried to lead like other people. I’d read about a leader I admired, adopt their approach, and wonder why it felt forced. It took me longer than I’d like to admit to realise that leadership style isn’t something you copy, it’s something you discover through practice, reflection, and a fair amount of getting it wrong.

The good news is that there’s no single correct way to lead an engineering team. The bad news is that your natural style, whatever it is, won’t be sufficient for every situation. The best leaders I’ve worked with aren’t the ones with the most charismatic style, they’re the ones who can shift between styles depending on what the moment requires.

SSRF

Sat, 07 Jun 2025 00:00:00 +0000

Server-Side Request Forgery is one of those vulnerability classes that I’ve grown to respect more and more the deeper I dig into it. The idea is simple, you trick a server into making HTTP requests to destinations you choose, turning it into your personal proxy. It can reach internal services, cloud metadata endpoints, and private networks that you’d never touch directly from the outside. OWASP gave SSRF its own category (A10) in 2021, and reading through the rationale, it was overdue. The case studies are striking, a single SSRF against http://169.254.169.254/ on AWS can leak IAM credentials and compromise an entire account. In this post, I’ll walk through Python, Java, Go, and JavaScript examples, from the textbook URL-in-a-parameter to the subtle redirect-chain and DNS rebinding variants that make SSRF so hard to defend against.

The Trap of Doing Two Jobs

Mon, 26 May 2025 00:00:00 +0000

I’ve fallen into this trap more than once. You get promoted, you take on the new responsibilities, and you keep doing the old ones too. Not because anyone asked you to, but because the old work is familiar, you’re good at it, and there’s a voice in your head saying “if I don’t do this, it won’t get done right.”

That voice is wrong. Or rather, it might be right in the short term, but it’s catastrophically wrong in the medium term. Doing two jobs doesn’t make you indispensable, it makes you a bottleneck, and it prevents your team from growing into the space you’re supposed to have vacated.

Logging Failures

Sat, 24 May 2025 00:00:00 +0000

When I started researching logging failures for this post, I expected to find dramatic exploit chains. Instead, what I found was something more unsettling, the absence of evidence. The most frustrating thing about incident response isn’t finding a sophisticated exploit; it’s opening the log aggregator and finding nothing. No entries, no breadcrumbs, no evidence that anything happened at all. That’s CWE-778 (Insufficient Logging), and it’s the backbone of OWASP A09: Security Logging and Monitoring Failures. This isn’t a crash or a data leak in the traditional sense; it’s the absence of evidence. When your incident response team can’t investigate what was never recorded, the attacker wins by default. In this post, I’m going to walk through logging failures across Python, Java, and Go, from the obvious missing-log-statement to the subtle cases where logging exists but captures the wrong data, at the wrong level, or silently drops events under load.

Integrity Failures

Sat, 10 May 2025 00:00:00 +0000

Integrity failures happen when an application trusts data or code that hasn’t been verified, and they can lead to some of the most devastating compromises out there. OWASP A08 covers two patterns I find particularly fascinating: unsafe deserialization (CWE-502), where untrusted data is fed into a deserializer that can execute arbitrary code, and inclusion of functionality from untrusted sources (CWE-829), where the application loads and runs code from URLs, plugins, or scripts without integrity checks. Both patterns share a root cause, the application assumes that incoming data or code is benign. In this post I’ll walk through Python, Java, JavaScript, and Go, from the textbook pickle.loads() to the subtle VM sandbox escapes that can survive expert review.

Managing Former Peers

Mon, 05 May 2025 00:00:00 +0000

There’s a particular kind of awkwardness that comes with being promoted above people you used to sit next to as equals. Yesterday you were peers, debating technical approaches over coffee. Today you’re their boss, responsible for their performance reviews, their career development, and potentially their continued employment. The relationship has fundamentally changed, and pretending otherwise is the worst thing you can do.

I’ve been on both sides of this, promoted above peers, and managed by someone who used to be my equal. Neither side is comfortable, and both require deliberate effort to navigate well.

Authentication Failures

Sat, 26 Apr 2025 00:00:00 +0000

Authentication is the front door of every application, and OWASP A07 documents how often that door is left unlocked. When I started digging into authentication failures, I realised they go far beyond weak passwords, they encompass hardcoded credentials compiled into binaries, brute-force attacks with no rate limiting, password hashes that can be reversed in seconds, and reset flows that hand tokens directly to attackers. These patterns show up in production regularly, sometimes in the same application. This post covers three CWEs across Python, Java, Go, and Rust: CWE-798 (Use of Hard-Coded Credentials), CWE-287 (Improper Authentication), and CWE-307 (Improper Restriction of Excessive Authentication Attempts).

Your First 90 Days as an Engineering Leader

Mon, 14 Apr 2025 00:00:00 +0000

The first 90 days in a new leadership role are simultaneously the most important and the most disorienting period of your tenure. Everything feels urgent. Everyone has opinions about what you should focus on. And the temptation to prove yourself by making immediate changes is almost irresistible.

Having started new leadership roles at both start-ups and large corporates, I can tell you that the single most valuable thing you can do in those first 90 days is slow down. Not because urgency isn’t real, but because acting on incomplete understanding almost always creates more problems than it solves.

Vulnerable Components

Sat, 12 Apr 2025 00:00:00 +0000

Your application is only as secure as its least-maintained dependency, and this is one of those lessons that really sinks in once you start digging into dependency trees. OWASP A06 (Vulnerable and Outdated Components) covers the reality that most modern applications are more dependency code than application code, and a single outdated library can undermine every security measure you’ve built. CWE-1104 captures this: the use of unmaintained third-party components with known vulnerabilities. In this post I’ll walk through real dependency chains in Python, Java, and JavaScript, from the Log4Shell-level disasters that make headlines to the subtle version pins that quietly accumulate CVEs while nobody’s watching.

Security Misconfiguration

Sat, 29 Mar 2025 00:00:00 +0000

Security misconfiguration is the vulnerability class that really drove home for me why secure defaults matter more than secure documentation. OWASP A05 covers the gap between what a framework can do securely and how developers actually configure it. Debug mode left on in production. CORS wide open. XML parsers that resolve external entities. Settings endpoints with no authentication. These aren’t coding mistakes, they’re configuration mistakes, and they show up everywhere. In this post I’ll walk through Python, Java, Go, and JavaScript examples covering CWE-16 (Improper Configuration) and CWE-611 (XML External Entity Processing), from the flags that any reviewer would catch to the subtle combinations that can survive months in production.

C++ Security Code Review Guide

Mon, 24 Mar 2025 00:00:00 +0000

1. Introduction

I put this guide together as a structured approach to security-focused code review for C++ applications. Whether you’re just starting to identify security vulnerabilities in C++ code or you’re an experienced developer looking for a language-specific checklist, I’ve tried to make it useful at both levels.

C++ inherits many of C’s low-level risks, manual memory management, pointer arithmetic, and the absence of bounds checking, while adding its own layer of complexity through classes, templates, smart pointers, the STL, RAII, and operator overloading. What I find fascinating about C++ security is the duality: when used correctly, features like std::unique_ptr, std::vector, and RAII can eliminate entire vulnerability classes. When misused, they create subtle bugs that are harder to spot than their C equivalents, dangling references from moved-from objects, use-after-free through raw pointer aliases to smart-pointer-managed memory, iterator invalidation, and implicit conversions in template code. What follows covers manual review strategies, common anti-patterns, recommended tooling, and vulnerability patterns organised by class, with cross-references to the intentionally vulnerable examples in this project.

Learning to Delegate (and Why It Feels So Wrong)

Mon, 24 Mar 2025 00:00:00 +0000

Early in my management career, I had a team of six engineers and I was still the person who knew the most about every part of the system. When something urgent came up, I’d fix it myself. When a design decision needed making, I’d make it. When a PR needed reviewing, I’d review it. I was efficient, responsive, and completely unsustainable.

It took a holiday, a proper two-week break where I was genuinely unreachable, for me to see the problem. The team didn’t fall apart while I was away. But they didn’t move forward either. They’d been waiting for me on three separate decisions, and nobody felt empowered to make them without my input. I’d created a team that was dependent on me, and I’d done it by being “helpful.”

Insecure Design

Sat, 15 Mar 2025 00:00:00 +0000

Insecure design is the vulnerability class that fascinates me the most, because no amount of perfect implementation can fix it. It lives in the architecture, the data flow, the decisions made before anyone wrote a line of code. OWASP A04 captures something that shows up again and again in real-world applications: systems that are insecure by design, not because of a coding mistake, but because the system was never designed to be secure in the first place. In this post, I want to focus on two of the most common manifestations: verbose error messages that leak internal details (CWE-209) and insufficiently protected credentials (CWE-522). I’ll walk through Python, Java, and JavaScript examples that range from the immediately obvious to the patterns that, from what I’ve seen in code reviews, can survive months without being caught.

Staying Technical as You Move Up

Mon, 03 Mar 2025 00:00:00 +0000

When I moved into my first management role, a more senior leader told me: “You’ll stop writing code within six months.” He said it like it was inevitable, a law of nature. I took it as a challenge. Twenty-five years later, I still write code. Not as much as I used to, and not the same kind, but I’ve never fully let go. And I think that’s been one of the most important decisions of my career.

Cryptographic Failures That Pass Code Review

Sat, 01 Mar 2025 00:00:00 +0000

Cryptographic code is uniquely dangerous, and it’s one of the areas I find most challenging to review. The reason is simple: it can be completely wrong and still appear to work perfectly. A broken hash function still produces a hash. A weak cipher still encrypts and decrypts. A predictable random number generator still generates numbers. The application runs, tests pass, and the vulnerability sits quietly until an attacker exploits it. In this post, I want to walk through the cryptographic failures that routinely survive code review across Python, Java, Go, and Rust, from the obvious use of MD5 to the subtle misuse of otherwise strong primitives.

Broken Access Control

Sat, 15 Feb 2025 00:00:00 +0000

Broken access control sits at the top of the OWASP Top 10 for good reason, and it’s the vulnerability class I find most fascinating to research. It’s the most common serious vulnerability in modern web applications, and it’s almost entirely a logic problem, no amount of input sanitization or encryption fixes it. The application simply fails to verify that the authenticated user is authorized to perform the requested action on the requested resource. In this post, I want to walk through the patterns that show up across Python, Java, and Go, from the IDOR that any pentester would find in minutes to the subtle authorization gaps that can survive months of code review.

What Nobody Tells You About Being a Tech Lead

Mon, 10 Feb 2025 00:00:00 +0000

The tech lead role is one of the most misunderstood positions in engineering. It’s not a title, it’s a set of responsibilities. It’s not a promotion, it’s a lateral move into a fundamentally different kind of work. And it’s where most engineers first discover whether they enjoy leadership, or whether they’d rather stay deep in the code.

I’ve been a tech lead multiple times across my career, and I still think it’s the hardest role in engineering. Not because the problems are the most complex technically, but because you’re pulled in three directions simultaneously and nobody tells you how to balance them.

C Security Code Review Guide

Tue, 04 Feb 2025 00:00:00 +0000

1. Introduction

I put this guide together as a structured approach to security-focused code review for C applications. Whether you’re just starting to identify security vulnerabilities in C code or you’re an experienced developer looking for a language-specific checklist, I’ve tried to make it useful at both levels.

C’s manual memory management, lack of bounds checking, direct pointer arithmetic, and minimal runtime safety make it uniquely prone to entire classes of vulnerabilities that higher-level languages prevent by design. The more I dug into C codebases, the more I appreciated just how many ways things can go wrong, buffer overflows, use-after-free, null pointer dereferences, integer overflows, and format string attacks are all first-class concerns. What follows covers manual review strategies, common anti-patterns, recommended tooling, and vulnerability patterns organised by class, with cross-references to the intentionally vulnerable examples in this project.

XSS Is Not Just a JavaScript Problem

Sat, 01 Feb 2025 00:00:00 +0000

Cross-site scripting gets framed as a front-end problem a lot, something that happens in JavaScript and gets fixed with JavaScript. But the more I dug into this, the clearer it became that XSS vulnerabilities almost always originate on the server side, in whatever language is generating the HTML. I’ve found XSS in Python templates, Java JSPs, Go’s html/template misuse, Rust web frameworks, and server-rendered JavaScript. The language you write your backend in determines which XSS patterns you’ll run into and which ones will sneak past your review.

The Identity Crisis of Becoming a Manager

Mon, 20 Jan 2025 00:00:00 +0000

The day I officially became a manager, I still wrote code. The day after that, I still wrote code. For weeks, I kept writing code, attending the same standups, reviewing the same PRs, and fitting “management stuff” into the gaps. It took me an embarrassingly long time to realise that I hadn’t actually changed what I was doing. I’d just added a new title to the old job.

That’s the trap, and nearly everyone falls into it.

Command Injection Beyond os.system

Sat, 18 Jan 2025 00:00:00 +0000

When most developers hear “command injection,” they think of os.system() in Python or Runtime.exec() in Java. Those are the textbook examples, and most teams know to avoid them. But the more I researched this topic, the more I realised that command injection surfaces through dozens of less obvious APIs across every language, subprocess pipes, shell expansions, backtick operators, and even seemingly safe exec functions that become dangerous with the wrong arguments. This is one of my favourite vulnerability classes to dig into because the attack surface is so much wider than people realise. Let me walk you through command injection patterns across seven languages, from the obvious to the genuinely subtle.

SQL Injection Across Languages

Sat, 04 Jan 2025 00:00:00 +0000

SQL injection is one of those vulnerability classes that refuses to go away, no matter how much the industry talks about it. I’ve been digging into how it manifests across different languages, Python, Java, Go, and JavaScript, and the root cause is always the same: untrusted input reaches a SQL query without proper parameterization. But the way developers introduce it varies wildly depending on the framework, ORM, and idioms of each language. In this post, I want to walk through real examples across these four languages, showing both the obvious patterns that any reviewer would catch and the subtle ones that slip through code review more often than you’d expect.

The Loneliness of Technical Leadership (and What to Do About It)

Mon, 30 Dec 2024 00:00:00 +0000

Nobody warns you about this part. You get promoted, you take on more responsibility, you start leading people, and somewhere along the way, you realise you have fewer people you can be genuinely honest with. The higher you go, the smaller that circle gets.

I’ve felt this at different points across my career, at a start-up where I was the only technical leader, and at a large corporate where I was surrounded by peers but couldn’t always be candid about what was going wrong. The loneliness of leadership isn’t about being physically alone. It’s about the growing gap between what you’re carrying and who you can share it with.

Building Diverse Teams That Actually Work

Mon, 09 Dec 2024 00:00:00 +0000

This is one of those topics where I’ve watched the conversation evolve significantly over the course of my career. Twenty-five years ago, “diversity” in tech largely meant making sure the team photo didn’t look entirely homogeneous. The bar was low, and most of us, myself included, didn’t think critically enough about what we were missing. The more I’ve researched this topic and reflected on my own experience leading teams of different shapes and sizes, the more I’ve come to believe that diversity isn’t just the right thing to do. It’s the thing that makes teams actually work better. But only if you pair it with genuine inclusion. Without that, it’s just optics.

How to Have Difficult Conversations

Mon, 18 Nov 2024 00:00:00 +0000

There’s a particular kind of dread that settles in the night before you know you have to have a difficult conversation. You rehearse it in the shower. You draft opening lines in your head while making coffee. You tell yourself it’ll be fine, and then you spend the rest of the morning hoping the other person calls in sick.

I’ve been having difficult conversations as a manager for a long time now, and I want to be honest about something: they don’t get easier. What changes is that you get better at having them. You learn to sit with the discomfort rather than rushing through it. You learn that the conversation you’re dreading is almost never as bad as the one you’ve been having with yourself about it.

Communication Is a Craft, Not a Soft Skill

Mon, 28 Oct 2024 00:00:00 +0000

For most of my career as an IC, the code did the talking. If the system worked, the message was clear. If the tests passed, the argument was won. Communication meant writing commit messages, maybe the occasional design document, and turning up to stand-up with something coherent to say.

Then I moved into leadership, and I discovered something uncomfortable: the thing I’d spent the least time deliberately practising was suddenly the thing I needed to be best at. Not architecture. Not debugging. Communication.

JavaScript Security Code Review Guide

Wed, 09 Oct 2024 00:00:00 +0000

1. Introduction

I put this guide together as a structured approach to security-focused code review for JavaScript and Node.js applications. Whether you’re just starting to identify security vulnerabilities in JavaScript code or you’re an experienced developer looking for a language-specific checklist, I’ve tried to make it useful at both levels.

JavaScript’s dynamic typing, prototype-based inheritance, single-threaded event loop with async concurrency, and the vast npm ecosystem make it enormously productive, but the more I dug into JavaScript security, the more I realised these same qualities introduce security pitfalls that static analysis alone cannot always catch. What follows covers manual review strategies, common anti-patterns, recommended tooling, and vulnerability patterns organised by class, with cross-references to the intentionally vulnerable examples in this project.

The Brilliant Jerk Problem

Mon, 07 Oct 2024 00:00:00 +0000

There’s a conversation that every engineering leader has at some point. It usually starts with something like: “Yeah, they’re difficult, but they’re the only person who understands the billing system.” Or: “I know people find them hard to work with, but their output is incredible.” You nod along, because you’ve probably said something similar yourself. I certainly have.

The brilliant jerk problem is one of those leadership challenges that feels genuinely hard the first time you face it, and blindingly obvious in hindsight. Someone on your team produces exceptional technical work, maybe they’re the fastest coder, the one who understands the gnarliest parts of the system, the person who can debug anything. But they also make people feel small. They dismiss ideas with contempt. They create an atmosphere where others are afraid to speak up, ask questions, or challenge anything.

Managing Conflict Without Avoiding It

Mon, 16 Sep 2024 00:00:00 +0000

I used to think I was good at managing conflict. What I was actually good at was avoiding it.

Early in my management career, I’d watch two engineers disagree about an architectural approach and my instinct was to smooth things over. Find the middle ground. Suggest we “take it offline.” Anything to get past the uncomfortable moment and back to something that felt like progress. I told myself I was being diplomatic. In reality, I was being a coward, and I was making things worse.

Trust as a Leadership Currency

Mon, 26 Aug 2024 00:00:00 +0000

Early in my management career, I inherited a team that had been through a rough patch. Their previous lead had been technically brilliant but unpredictable, generous with praise one week, dismissive the next. Decisions were made behind closed doors and communicated as faits accomplis. By the time I arrived, the team had learned a very rational behaviour: keep your head down, don’t volunteer ideas, and never be the one to deliver bad news.

Giving Feedback That Actually Lands

Mon, 05 Aug 2024 00:00:00 +0000

There’s a moment I remember clearly from early in my management career. I’d prepared what I thought was a really well-structured piece of feedback for someone on my team. I’d thought about the situation, the behaviour, the impact, the whole lot. I delivered it calmly, clearly, and with good intentions. And it landed like a brick through a window.

The person shut down. They nodded politely, said “okay, thanks,” and I could see the shutters come down behind their eyes. Whatever I’d intended to communicate, what they’d received was something entirely different. That gap, between intending to give helpful feedback and having it actually received that way, is enormous. And I’ve learned the hard way, more than once, that closing it takes far more than just getting your words right.

The Art of the One-on-One: Beyond Status Updates

Mon, 15 Jul 2024 00:00:00 +0000

In the first article in this series, I wrote about psychological safety, the foundation that makes everything else in leadership possible. If there’s one place where that foundation gets tested every single week, it’s the one-on-one.

I’ll be honest: my early one-on-ones were terrible. I’d sit down with a report, open Jira, and essentially run a standup for two people. “How’s the migration going? Any blockers? Cool, see you next week.” I thought I was being efficient. What I was actually doing was wasting the most valuable recurring meeting on my calendar, and probably theirs too.

Why Psychological Safety Is the Foundation Everything Else Sits On

Mon, 24 Jun 2024 00:00:00 +0000

You can have the best engineers, the clearest roadmap, and the most elegant architecture in the world, and none of it will matter if your team doesn’t feel safe enough to speak up when something’s wrong.

I’ve been leading engineering teams for over two decades now, across start-ups and large corporates, and if there’s one thing I keep coming back to, it’s this: the teams that performed best weren’t the ones with the most talent. They were the ones where people felt safe enough to be honest. Safe enough to say “I don’t understand this,” or “I think we’re making a mistake,” or “I need help.”

Mon, 01 Jan 0001 00:00:00 +0000

Source Code

Like most engineers, I write more code than I make public. Source code relating to articles on this site is publicly available on GitHub , along with some earlier projects.

Mon, 01 Jan 0001 00:00:00 +0000

About Me

I’m a technology professional with over 25 years’ experience as both a software engineer, and technology leader. Over the years I’ve led technology teams ranging in size from a handful of engineers, to entire technology functions comprising of teams of teams.

Over the last decade I’ve had a big focus on security, specifically application/product security. Since 2021, I’ve been leading application security teams at AWS & Amazon.

I hope you enjoy these articles.

Mon, 01 Jan 0001 00:00:00 +0000