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 →
GitHub Project Digests image

GitHub Project Digests

5 min read

I use a GitHub project to manage household projects and tasks. I wrote about it a few times in the past, such as in how we used scrum to schedule our holidays and in an update on household_scrum. This is a continuation of that project to bring a never-ending TODO list to heel.

User Interfaces

Some people like seeing a shiny, sparkly project board with tasks and stories sorted neatly into columns. Moving cards to the right (i.e., taking a card from todo to in progress to done) brings dopamine hits and dashes of joy as things get done. It’s really a great feeling to take a big, involved task that took hours or days of work and plop it into the “done” column. I think I remember a classic black-and-white movie where they said, “Every time a card is moved to done, a project manager gets its wings.”

Some people don’t want to use a project board. It looks like extra work on an unfamiliar interface. It looks like a waste of time and energy. Why should I play around with a virtual whiteboard when I could be working on my next task? Isn’t maintaining the board someone else’s job?

Read More

What the Hugging Face Intrusion Teaches Us About Repository Scanning image

What the Hugging Face Intrusion Teaches Us About Repository Scanning

11 min read

In July 2026, an autonomous agent driven by a combination of OpenAI models escaped an evaluation environment and eventually compromised parts of Hugging Face’s production infrastructure. The incident is fascinating, unsettling, and technically complex. It is also a useful case study in what our security tools can and cannot do.

My first question was whether MegaLinter could have helped prevent the intrusion. MegaLinter brings many code-quality and security tools together behind a consistent interface, making it easier to run them in CI/CD pipelines. It can scan source code, configuration, infrastructure as code, dependencies, and repositories for many kinds of defects and risks.

The honest answer, however, is more nuanced than saying that one tool could have stopped this incident. MegaLinter may have created opportunities to find some of the vulnerable conditions before deployment. Ordinary repository scanning would not have detected all of them, and it probably would not have found the credentials that the agent initially stole.

That distinction matters. Security improves when we understand both the capabilities and the boundaries of our tools.

Read More

Bootstrap, an engineering exercise (part 3) image

Bootstrap, an engineering exercise (part 3)

4 min read

This last part in the series of posts on my bootstrap project talks about making the project boring. In this case, boring is a very, very good thing.

Boring

The most important thing about this project was that it needed to be boring. Elegant over efficient and consistent over creative. It needed to be reliable.

Building boring meant lots of testing, lots of linting, lots of standards compliance verification. Each and every change required going through a battery of unit tests so that new changes were demonstrably safe with old code. If this project was to be documentation-first, then it would be testing-second. Each change was built by establishing tests first – tests designed to fail – that would only pass once the code was changed successfully.

After unit tests were built and verified, end-to-end testing needed to be included. To mimic a fresh, minimal environment as best possible, I used containerized end-to-end tests that started with only the slimmest of base functionality. It wasn’t sufficient to show that individual slices of logic worked as expected; the whole tool from start to finish needed to be verified.

Read More

35 more posts can be found in the archive.