Forem: Aturo Phil

The Modern DevSecOps Engineering Stack (2026 Edition): From First Commit to Production

Aturo Phil — Sun, 24 May 2026 13:23:36 +0000

Here's a hard truth I learnt after watching a production database get wiped by a leaked .env file: DevSecOps doesn't start with a tool. It starts with a habit.

Most breaches happen because the fundamentals were loose — a secret committed to git, a code review that skimmed past an SQL injection, a dependency added without checking who maintains it.

In this series, we're going to build something real: a Notes API in Go that goes from git init all the way to Kubernetes. Every step gets a security layer. Every decision gets explained. And yes, you can clone it and break it yourself.

Before we write a single line of Go, we need to talk about how to configure your development environment to be more secure. Here's the thing: your IDE, your git config, your pre-commit hooks — these are your first security controls.

Git: More Than Version Control

Commit Signing

Git trusts whatever you tell it. Change your email, change your name, and the commit looks legitimate in history. In a team environment — or even working solo — that means your audit trail is only as strong as your ability to prove who actually wrote what.

Commit signing fixes this. It attaches a cryptographic signature to every commit, verified against your GPG key. Not optional for production codebases. Non-negotiable for compliance. And surprisingly easy to set up.

# Generate a GPG key (RSA 4096, no expiry for simplicity)
gpg --full-generate-key

# Tell git to use it
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true

# Verify any commit
git log --show-signature -1

Try this: Run git log --show-signature on your current project. If nothing shows up, your history is unverified — and in a security audit, unverified means untrusted.

Pre-Commit Hooks

Pre-commit hooks are your first automated line of defense. They run locally, before a commit ever reaches the remote, catching issues that are easy to miss when focusing on shipping features.

Here is what that looks like in practice:

#.pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.0  # check for latest
    hooks:
      - id: gitleaks

  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v5.0.0
    hooks:
      - id: detect-private-key
      - id: check-merge-conflict
      - id: trailing-whitespace

  - repo: https://github.com/dnephin/pre-commit-golang
    rev: v0.5.1
    hooks:
      - id: go-fmt
      - id: go-vet

Install and activate:

pip install pre-commit
pre-commit install
pre-commit run --all-files

What happens now: every git commit scans for hardcoded secrets, private keys, and common mistakes before the code leaves your machine. This will help you catch the secret and makes sure it never enters git history.

What we are building:

We'll build a production grade Notes API in Go, and secure it at every layer. Here is the architecture:

Auth service: JWT-based authentication with bcrypt password hashing.
Notes API: CRUD operations with strict ownership enforcement
Security controls: IDOR protection, SQL injection prevention, structured logging and more
Stack: Go, PostgreSQL, HashiCorp Vault, Docker, Kubernetes.

This is a real-world pattern in production systems, small enough to understand completely, comprehensive enough to demonstrate every DevSecOps concept we cover.

The project structure lives here, and every section of this series maps to a tagged commit so you can follow along exactly:
https://github.com/philaturo/secure-notes-api

Star it to track progress, clone it to break things, and open an issue if you spot something I missed. This is being built in the open — no polished final product, just real commits, real mistakes, and real fixes.

In part 2, we'll look at how to harden the CI/CD pipeline, least privilege, artifact signing and why a misconfigured .yml file is a security vulnerability. See you there !

ElixirConf EU 2026: Three Technical Shifts That Matter

Aturo Phil — Mon, 18 May 2026 09:54:44 +0000

Málaga hosted the ElixirConf EU 2026. Here's what changed.

1. Type Inference Arrives (No Annotations Required)

Elixir 1.20 introduces whole-program type inference. The compiler now understands function signatures, guard conditions, and map key domains without explicit type annotations.

What this means: A function performing arithmetic on map values now infers that the input must be a map containing numeric keys. Pattern matching across clauses carries type knowledge forward. Handle nil in one branch? Subsequent branches know the value cannot be nil.

The system also tracks map mutations through the Map module, emitting compile-time warnings when operations reference keys proven to be absent.

For teams: Fewer runtime errors. Earlier logic flaw detection. Testing effort shifts from defensive type checking to business logic validation.

Requires Erlang/OTP 27 or later.

2. DurableServer: State That Survives Node Failures

Chris McCord's keynote introduced DurableServer—a new abstraction for stateful processes that persist across node failures and support seamless state migration in distributed clusters.

The problem it solves: Traditional GenServer implementations tie process state to node lifecycle. Distributed applications struggle with process locality guarantees.

The solution: DurableServer integrates with pluggable storage backends. Process state lives independently of the node.

Complementary sessions demonstrated Kafka-backed architectures and Oban processing at scale. The combination enables architectures that maintain consistency without external coordination layers.

For teams: Redesign stateful components for resilience without rewriting application architecture.

3. Compilation Gets Faster (Up to 4x)

Elixir 1.20 delivers measurable compilation improvements through:

Lazy module loading
Parallel dependency resolution

Large codebases see build time reductions of up to four times in benchmark scenarios.

Tooling additions:

mix source for better visibility
Enhanced IEx debugging output
Type-aware autocomplete in IEx
Improved error messaging for undefined functions

For teams: Lower cognitive overhead when working with large, modular applications.

What This Means for You

Role	Implication
Teams evaluating Elixir	Enhanced type system reduces test coverage needs for edge cases
Existing Elixir projects	Upgrade to 1.20 for incremental type-aware development. Compiler detects redundant clauses and dead code, supporting refactoring with higher confidence
Engineering leadership	The "one monolith, many teams" pattern presented at Málaga shows Elixir's module isolation and supervision trees provide natural boundaries for team autonomy

One More Thing: AI Patterns

Multiple talks addressed AI integration. The BEAM's lightweight process model aligns naturally with asynchronous, stateful AI orchestration.

Two libraries worth noting:

Legion – Code execution by AI agents using pure Elixir
Arcana – Retrieval-augmented generation pipelines without external runtimes

Concurrent inference requests. Familiar supervision patterns. No additional orchestration layers.

Sources: ElixirConf EU 2026 announcements, Elixir 1.20 release candidate documentation, and community resources compiled on the Elixir Forum.