Wesley Dean

DevSecOps Engineer, Author, and Mentor

I’m a technologist, author, and mentor who helps people and organizations move from complexity to clarity. Through consulting, writing, and workshops, I bridge the gap between technical and non-technical teams, translating risk into meaningful decisions and sustainable action. My work centers on leadership, connection, and disciplined execution, drawing on decades of experience to help teams build secure, reliable systems while strengthening trust, alignment, and shared understanding.

Picture of Wesley Dean wearing a black dress shirt

Latest 3 Posts ↓

View all posts →
Threat Modeling: A Structured Way to Ask What Could Go Wrong image

Threat Modeling: A Structured Way to Ask What Could Go Wrong

7 min read

Threat modeling is a fascinating concept: you review an application, look for opportunities for something to go wrong, and then document your findings. There are many frameworks, tools, and techniques for doing that. The common task is to examine what can go wrong from several perspectives.

The model I like most is STRIDE, which stands for:

  • S: Spoofing
  • T: Tampering
  • R: Repudiation
  • I: Information Disclosure
  • D: Denial of Service
  • E: Elevation of Privilege

Read More

template-bash, a starter for Bash engineering image

template-bash, a starter for Bash engineering

7 min read

Over the past several weeks, I have written about a few small Bash tools that grew out of larger projects: mktext for literal text substitution, bash-doxygen for source documentation, bashdeps for exact artifact materialization, and bashlog for predictable logging and explicit redaction.

Those tools each have intentionally narrow responsibilities. At some point, though, I also needed a place to answer a different question: what does a Bash project look like when these practices are assembled into one coherent starting point?

That is the role of template-bash.

template-bash is a private repository I maintain alongside Getting Started with Bash Engineering. It is a starter for maintainable, documented, tested, and releasable Bash projects, and it consolidates patterns that have been exercised across adrctl, bashdeps, Bootstrap, mktext, bashlog, and related work.

The GitHub repository itself is private, and I am not distributing repository access. I publish a versioned export of the starter as the Bash Engineering Starter Kit. That archive is available free to people who request it through the book’s companion-resource page.

Read More

bashlog, predictable logging with explicit redaction image

bashlog, predictable logging with explicit redaction

7 min read

There is a point in many shell projects where printf >&2 starts accumulating policy.

The first message is straightforward. Then there are severity levels, quiet and debug modes, timestamps, terminal colors, machine-readable output, tags, and the question that tends to arrive after the first sensitive value appears in a log: how do we make sure that value does not leave the process through the logging path?

I wanted a reusable answer to that problem, but I did not want a logging library that took over the application around it. I did not want traps, shell-option changes, hidden network behavior, automatic environment discovery, generic functions named info and error, or a transport stack pretending every Bash program needed to become a logging daemon.

That became bashlog, a sourceable pure-Bash logging library with a deliberately small runtime boundary.

The project is still marked pre-release as I write this, so I am describing the current architecture and public contract rather than implying a finished 1.0 API. The boundaries are already the part I find most interesting.

Read More

46 more posts can be found in the archive.