DEV Community: Benjamin Tetteh

Your AI Writes Code Fast. Here’s How to Check It Before Shipping

Benjamin Tetteh — Sat, 23 May 2026 14:55:54 +0000

A beginner-friendly guide to building an automated security pipeline with GitHub Actions — from zero, in under an hour.

Here is a scenario that plays out constantly in the world of AI-assisted development.

You build something. It works. You are excited. It is late. You run through a mental checklist — or most of it — and you push to production. Three items got checked. Two did not. You tell yourself you will fix it tomorrow.

Tomorrow, you are already building the next thing.

This is not a discipline problem. This is a systems problem. Checklists depend on human memory and human energy, and both of those fail under shipping pressure. Automation does not forget. It does not get tired. It does not skip the last two items because it is midnight and the feature finally works.

That is the entire argument for automated security gates. Not that you are careless — but that no human is perfectly consistent, and consistency is exactly what security requires.

If you read the first article in this series about vibe coding and security, you saw the Moltbook breach — a weekend-built app that exposed 1.5 million API tokens and 35,000 emails because a few security defaults were never configured. The checklist at the end of that article is a good start. This article is about making that checklist run automatically, every single time you push code, without you having to think about it.

One of the tools that makes this possible is GitHub Actions.

What Is GitHub Actions, Really?

If you have a GitHub repository — a place where your code lives online — GitHub Actions is a system that lets you run automatic tasks whenever something happens in that repository.

Something happens could mean:

You push new code
You open a pull request
You merge into your main branch
You create a new release

When that trigger fires, GitHub spins up a temporary computer in the cloud, runs whatever instructions you give it, and reports back whether everything passed or failed. You do not manage that computer. You do not pay for it beyond GitHub's free tier limits. It just runs.

Those instructions live in a file called a workflow — a plain text file written in a format called YAML that lives inside your repository at .github/workflows/. You can have as many workflow files as you want, each doing different things.

Here is the simplest possible workflow to make this concrete:

# .github/workflows/hello.yml
name: My First Workflow

on:
  push:              # Run this whenever code is pushed
    branches: [main]

jobs:
  say-hello:
    runs-on: ubuntu-latest    # Use a fresh Linux computer

    steps:
      - name: Print a message
        run: echo "Code was pushed. The pipeline is running."

That is it. A name, a trigger, a machine to run on, and steps to execute. Everything we build in this article follows exactly that same structure — we are just swapping echo "hello" for real security tools.

Why This Matters More for Vibe Coders

Traditional developers have something vibe coders are still building: years of conditioned habits. The reflex to check for exposed secrets before pushing. The instinct to verify that a new endpoint requires authentication. The muscle memory of running a linter before committing.

Those habits took years to form. AI-assisted development is compressing timelines so fast that many people are shipping production apps before those habits exist.

Automated security gates close that gap. They are not a replacement for understanding security — but they are a safety net that catches common mistakes before they reach production. Think of it less like a replacement for a trained developer and more like spell-check. Spell-check does not make you a better writer, but it catches the embarrassing errors while you focus on the ideas.

The goal of this article is to give you a working security pipeline by the end. Not a theoretical one. An actual .yml file you can drop into any project today.

How to Set It Up: From Zero

You need two things before anything else:

A GitHub repository. If your project is not on GitHub yet, create a free account at github.com and push your code there. GitHub has a beginner guide for this if you have never done it.

A .github/workflows/ folder in your repository. You can create this directly on GitHub by clicking "Add file" inside your repository, or in your code editor locally. GitHub Actions picks up any .yml file inside that folder automatically.

That is genuinely all the setup required. No servers, no accounts, no credit cards.

Building the Pipeline: Layer by Layer

We are going to build one workflow file that runs three security checks in sequence. Each check catches a different category of problem. You can start with just one and add the others when you are ready — the pipeline is modular by design.

Here is the full picture of what we are building:

On every push to main:
│
├── Step 1: Gitleaks — scan for exposed secrets and API keys
├── Step 2: Semgrep — scan for insecure code patterns  
└── Step 3: Snyk or CodeQL — scan for vulnerable dependencies

Each scan catches a different category of problem — secrets, insecure code patterns, and vulnerable dependencies. If any one fails, GitHub stops the pipeline before the code reaches production. You get an email, a red badge on your repository, and a detailed report showing exactly what was found and where.

The diagram below maps how the pieces connect. Think of it as your security assembly line — every push goes through it automatically, without you having to remember to run anything manually.

Let's build each layer.

Step 1: Catching Exposed Secrets with Gitleaks

Gitleaks scans your codebase for anything that looks like a secret — API keys, database passwords, tokens, private keys. It knows the patterns for hundreds of services: AWS, OpenAI, Stripe, Supabase, GitHub itself.

This is the Moltbook failure in automated form. If Gitleaks had been running on that repository, the exposed Supabase key would have been flagged before the first commit ever reached production.

Create a file at .github/workflows/security.yml and add this:

name: Security Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  secret-scan:
    name: Scan for Exposed Secrets
    runs-on: ubuntu-latest

    steps:
      # Step 1: Download your code onto the pipeline machine
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0    # Scan the full git history, not just the latest commit

      # Step 2: Run Gitleaks
      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # GitHub provides this automatically

What this does in plain English: Every time you push to main or open a pull request, GitHub downloads your code onto a fresh machine and runs Gitleaks across every file and every commit in your history. If it finds anything that looks like a secret, the pipeline fails and you get a detailed report showing exactly which file and which line contains the problem.

The fetch-depth: 0 line is important — without it, Gitleaks only scans your most recent commit. With it, it scans your entire history, which catches secrets that were committed weeks ago and never removed.

Step 2: Catching Insecure Code Patterns with Semgrep

Gitleaks catches secrets. Semgrep catches insecure patterns — things like SQL queries that trust user input directly, authentication checks that can be bypassed, or configuration values that should never be public.

Semgrep has a free tier and a library of pre-written rules maintained by security researchers. You do not need to write the rules yourself. You just point it at a ruleset and it does the work.

Add this job to the same security.yml file, underneath the secret-scan job:

  code-scan:
    name: Scan for Insecure Code Patterns
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets
            p/javascript
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

What this does in plain English: Semgrep reads through your code looking for patterns that security researchers have identified as dangerous. The p/security-audit ruleset covers common vulnerabilities. The p/javascript ruleset adds JavaScript and TypeScript-specific checks. If your project uses Python, swap p/javascript for p/python. If it uses both, list both.

To get your SEMGREP_APP_TOKEN, create a free account at semgrep.dev, go to Settings, and copy your token. Then in your GitHub repository, go to Settings → Secrets and Variables → Actions → New Repository Secret, and paste it there as SEMGREP_APP_TOKEN. GitHub stores it encrypted and injects it into the pipeline automatically — your token never appears in your code.

Step 3: Catching Vulnerable Dependencies

Your app almost certainly uses packages written by other people — React, Express, Axios, whichever libraries your AI reached for. Those packages sometimes contain known security vulnerabilities. You did not write the vulnerability, but if it is in your app, it is your problem.

You have two solid options here depending on your comfort level.

Option A: Snyk (beginner-friendly, generous free tier)

Snyk is built for accessibility. It has a VS Code extension, a web dashboard, and a GitHub integration that makes setup straightforward. Add this job to your workflow:

  dependency-scan-snyk:
    name: Scan Dependencies with Snyk
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high  # Only fail on high and critical issues

Get your SNYK_TOKEN by creating a free account at snyk.io, going to Account Settings, and copying your Auth Token. Add it to GitHub Secrets the same way you added the Semgrep token.

Option B: CodeQL (built into GitHub, no extra account needed)

CodeQL is GitHub's own static analysis engine. It is more powerful than Snyk for code-level analysis, slightly more complex to configure, but requires no external account. Replace the Snyk job with this:

  dependency-scan-codeql:
    name: Scan with CodeQL
    runs-on: ubuntu-latest
    permissions:
      security-events: write

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v3
        with:
          languages: javascript  # Change to python, ruby, etc. if needed

      - name: Perform Analysis
        uses: github/codeql-action/analyze@v3

Results from CodeQL appear directly in your GitHub repository under the Security tab — no external dashboard needed.

Which should you choose? Start with Snyk if you want immediate, readable results in plain English. Move to CodeQL when you want deeper analysis integrated directly into GitHub. There is no wrong answer — running either is infinitely better than running neither.

The Complete Pipeline

Here is the full security.yml file with all three jobs combined. Drop this into .github/workflows/security.yml in any project and your automated security gate is live:

name: Security Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  secret-scan:
    name: Scan for Exposed Secrets
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  code-scan:
    name: Scan for Insecure Code Patterns
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets
            p/javascript
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

  dependency-scan:
    name: Scan Dependencies
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

Three jobs. Three categories of risk. All running automatically on every push.

Reading the Results

When a pipeline run completes, GitHub shows you one of two things:

Green checkmarks — all scans passed. You are clear to merge or deploy.

A red X — something was found. Click into the failed job, read the output, and it will tell you exactly what was flagged, in which file, and often why it is a problem.

Do not treat a red X as a failure. Treat it as the system working. The pipeline caught something before it reached production — which is precisely what it is there to do.

One Thing to Do Right Now

If setting up all three jobs at once feels like too much, start with just Gitleaks. Create the .github/workflows/security.yml file with only the secret-scan job. Push it to your repository. Watch it run.

Once you have seen a pipeline run — green or red — the rest becomes much less intimidating. The structure is always the same: trigger, machine, steps. You are just swapping in different tools.

Security automation is not a one-time setup. It is a habit that compounds. Every project you start from now on gets the pipeline from day one. Every collaborator who opens a pull request gets their code scanned automatically. Every push gets checked before it ships.

That is what consistency looks like when you remove the human from the loop.

Where This Fits in Your Stack

This pipeline covers the code layer — what is in your repository. Combined with the platform-level defaults from the previous article — RLS enabled, rate limiting on, secrets in the right environment variables — you now have security running at two levels simultaneously:

Before the code ships → GitHub Actions catches it in the pipeline
After the code ships → Platform defaults limit the damage if something slips through

Neither layer is perfect on its own. Together they cover the vast majority of the failures that appear in real-world breaches — including the ones that made Moltbook a case study.

You did not need a Computer Science degree to set this up. You needed a .github/workflows/ folder and about an hour.

The next article in this series covers something slightly different: what to do when the AI itself is part of your pipeline — and the new attack surface that creates.

Found this useful? Share it with someone who just shipped their first repo. The best time to add a security pipeline is before the first breach. The second best time is right now.

The Hidden Layer Every AI Developer Must Learn

Benjamin Tetteh — Fri, 22 May 2026 12:22:52 +0000

Late January 2026. A developer ships a social network over a weekend. No traditional code written — just prompts, a vision, and an AI that turned ideas into a working product in days. The platform goes viral. Andrej Karpathy, OpenAI co-founder, calls it "the most incredible sci-fi takeoff-adjacent thing I have seen recently."

Then a security researcher opens the browser's developer tools.
Within minutes, they find an API key sitting in plain JavaScript — visible to anyone who knows how to press F12. They use it to query the production database. No login required. No special tools. Just a simple command and a coffee.

What comes back: 1.5 million API authentication tokens. 35,000 email addresses. Thousands of private messages. The entire platform — every agent, every credential, every conversation — sitting wide open.

The platform was called Moltbook. The fix, when it came, took two SQL statements.

This is not a story about a bad developer. It is a story about a gap that AI does not fill automatically — and what you can do about it before you ship.

The Illusion That Catches Everyone

A few years ago, building software required crossing a painful barrier. You had to learn syntax, frameworks, databases, APIs, Git, deployment — and break things repeatedly along the way. For most people outside tech, software engineering felt like a locked room with a very small door.

Then AI arrived.

Now someone with little traditional programming experience can build a SaaS app over a weekend, connect a database to a frontend, integrate payments, and deploy an API — all from prompts. That shift is extraordinary, and I think it is genuinely amazing. I am a vibe coder too. I understand the excitement of watching an idea move from imagination to a working product faster than ever before.

But there is a dangerous illusion forming around AI-generated software: If the app works, people assume it's safe. Those are not the same thing.

A beautifully designed application can still expose private user data, leak API keys, allow unauthorized access, and accidentally disable database protections — all while the UI looks polished and the login flow works perfectly. Security problems live underneath visible functionality. That is exactly what happened with Moltbook.

What AI Gets Right, and What It Quietly Skips

AI is very good at helping you build the happy path — the feature works, the button responds, the API returns data, the page renders. That part is genuinely impressive.
Security lives in the unhappy paths:

What if someone queries your database without logging in?
What if an attacker manipulates a request from the browser?
What if your API keys are visible in the page source?
What if someone calls your registration endpoint ten thousand times in a loop?

Experienced developers ask these questions automatically. Not because they are smarter — but because they built the habit slowly, over years of debugging painful issues, reading post-mortems, and making mistakes in lower-stakes environments.

AI compresses the implementation timeline dramatically. It does not compress the experience required to ask the right security questions. That gap is where breaches happen.

And to be clear: this is not only a beginner problem. Even experienced developers can become overconfident when AI accelerates output speed. Because AI-generated code often looks extremely convincing. The explanations sound confident. The architecture appears plausible. The feature functions correctly.

But plausible code is not the same as safe code.

The Moltbook Breakdown: What Actually Went Wrong

Moltbook was built on Supabase — a popular, well-documented backend service that is excellent for fast development. Supabase is designed to work with a public API key exposed on the client side. That is intentional and not, by itself, a security failure.

The security failure is what you configure that key to be able to do.

Supabase ships with a feature called Row-Level Security — a database setting that ensures users can only access their own data. It is not enabled by default. You have to turn it on. And if you are vibe coding and the AI generates a working backend without you asking about security, there is a good chance that step never comes up.

At Moltbook, it didn't.

The result: anyone with basic technical knowledge could query the entire production database — every user's credentials, private messages, and authentication tokens — using the key sitting in plain sight on the website. Write access was also open, meaning an attacker could have edited any post on the platform without logging in.

The founder's public statement captured the situation honestly: "I didn't write a single line of code for Moltbook. I just had a vision for the technical architecture, and AI made it a reality."

The AI made a working platform. It did not make a secure one.

It Is Not Just Moltbook

Six months before Moltbook, security researchers at Wiz found a critical vulnerability in Base44 — a vibe coding platform used by actual enterprises to build internal HR systems, customer databases, and knowledge bases containing sensitive employee data.

The flaw was shockingly simple: two API endpoints for registering and verifying users required no authentication whatsoever. Using only a value visible in the app's public URL, a researcher could create a verified account inside any private enterprise application on the platform — bypassing SSO and every other access control entirely.

Here is the detail that changes the conversation: Base44 builders did not write that vulnerable endpoint. The platform did. Individual developers had no visibility into the flaw. This is the second dimension of vibe coding security risk that almost nobody talks about. The first is what AI generates when you prompt it. The second is what the platform you are building on introduces independently of your code.

Both matter. Both can be addressed.

Security in Plain English

One reason security feels intimidating is because the terminology sounds abstract and technical. Most of it isn't. Here is a plain-English translation of the concepts that come up most often:

Term	What It Actually Means
Authentication	Verifying who someone is
Authorization	Deciding what they are allowed to access
API Key	A secret password your app uses to talk to another service
Row-Level Security	Preventing users from reading other users' data in your database
Rate Limiting	Stopping someone from making thousands of requests in a loop
Secret Scanning	Automatically detecting exposed passwords or keys in your code
Least Privilege	Only giving a system the minimum access it actually needs
Input Validation	Making sure users can't send dangerous or unexpected data

Security is not magic. Most of the time it is about reducing obvious mistakes, limiting damage when mistakes happen, and protecting user trust. That's it.

The Five Things AI Consistently Misses

These are the patterns that show up repeatedly in AI-generated code — not as exotic edge cases, but as defaults. Each one comes with a practical fix.

1. API Keys Exposed in Client-Side Code
When you ask AI to connect your app to an external service, it will often put the credentials directly in the frontend code. Frontend code is public. Anyone can open the browser's developer tools and find it. Automated scanners crawl the web looking for exactly this.

The fix: Run Gitleaks before you push code. It scans for secrets and blocks the commit if it finds any. GitHub's built-in secret scanning does the same thing automatically on public repositories — no setup required.

2. Row-Level Security Not Enabled
This is the Moltbook failure. AI can generate a complete Supabase schema without ever enabling RLS, because RLS requires understanding your data access model — who should see what — and AI often skips that reasoning unless you ask for it explicitly.

The fix: In your Supabase dashboard, check that RLS is enabled on every table containing user data. Then write policies that define exactly who can access each row. The Supabase documentation has a beginner-friendly walkthrough that takes about twenty minutes.

-- Enable RLS on a table
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;

-- Users can only read their own records
CREATE POLICY "owner_only"
ON agents FOR SELECT
USING (auth.uid() = owner_id);

3. API Endpoints With No Authentication
AI generates routes that respond to requests. Whether it adds authentication to those routes depends on whether you asked — and whether the AI remembered your earlier requirements by the time it got to that file.

The fix: Go through every API route and ask: what happens if someone calls this without logging in? Tools like Bearer scan your codebase and flag unprotected routes for free. Better still, apply authentication at the middleware layer so every route is protected by default.

4. Secrets on the Wrong Side of the App
Many AI tools know not to hardcode secrets and will suggest environment variables. What they sometimes miss is the difference between variables available to the client (public) and variables available only to the server (private).

In Next.js, any variable prefixed with NEXT_PUBLIC_ is bundled into the client JavaScript and visible to everyone. Your OpenAI API key, Stripe secret key, and database credentials should never have that prefix.

The fix: Search your project for NEXT_PUBLIC_ and verify that nothing sensitive uses it. Server-only secrets get no prefix. Public configuration values — like your Supabase URL — can use the prefix safely, but only if RLS is properly configured.

5. No Rate Limiting
AI generates endpoints that respond to requests. It does not add rate limiting unless you ask. This means your registration endpoint, login endpoint, and data endpoints will accept unlimited requests from anyone.

At Moltbook, this allowed a single bot to create 500,000 fake accounts. The same pattern can be used to exhaust your API quota overnight and run up a bill that ends your project.

The fix: If you are on Vercel, enable rate limiting in your project's security settings — it takes five minutes and requires no code. For Supabase, the same option exists under Project Settings. Do this before you go public.

The Mistake Almost Everyone Makes: "I'll Secure It Later"

This mindset is understandable. When you are learning, shipping feels difficult enough already. Security can feel like an advanced topic for a future version of yourself.

The problem is that insecure architecture hardens very quickly. Once real users arrive, technical debt compounds, insecure patterns spread through the codebase, and leaked secrets cannot be unexposed. The Moltbook breach did not happen because the founder planned to fix security later. It happened because the platform went viral before that moment came.

Security is not a decorative layer added at the end. It is part of the design. That does not mean you need perfection before you launch. It means security awareness needs to begin at the same time as everything else.

Your Security Stack, Kept Simple

You do not need to become a security engineer. You need a short checklist and the discipline to run it.

Start here — these take under an hour total:

GitHub Secret Scanning — enabled by default on public repos, catches exposed keys automatically
Gitleaks — run it locally before pushing; blocks commits containing secrets
Supabase RLS — enable it on every table in your dashboard; follow the docs walkthrough
Vercel Rate Limiting — enable it in your project settings before going public
Snyk free tier — scans your dependencies for known vulnerabilities; integrates with VS Code

When your project gets more serious:

Semgrep — static analysis that catches insecure code patterns in CI
CodeQL — deeper analysis integrated into your GitHub pull request workflow
Pre-commit hooks — stop dangerous commits before they leave your machine

Think of these tools as an automated second opinion. If AI is your fast-moving junior developer, security tooling is your automated reviewer. That combination is far safer than relying on intuition alone — especially when moving quickly.

One More Thing: Ask Your AI

One of the most underused techniques in vibe coding security is simply prompting for it. Before you ship any feature that touches user data, try this:

"Review this code for security issues. Check whether any credentials are exposed in client-side code, whether database tables have Row-Level Security enabled, whether API endpoints require authentication, and whether there is rate limiting on registration and data endpoints."

AI is quite capable of security review when asked explicitly. The problem is that it does not apply that review automatically. Make it a habit to ask. It takes thirty seconds and it will catch things.

A Fair Hearing for the Critics

The people arguing against vibe coding are not wrong. They are pointing at a real pattern: AI generates working code that skips assumptions a trained developer would never skip. Moltbook and Base44 are valid evidence of that.

But the conclusion — that people without traditional coding backgrounds should not build things — does not follow. What the evidence actually shows is that vibe coding without security awareness is dangerous. That is a different claim, and it has a different solution.

The Wiz Research team — the same team that found both breaches — put it clearly: the opportunity is not to slow down vibe coding but to elevate it. AI tools that generate Supabase backends can enable RLS by default. Deployment platforms can scan for exposed credentials automatically. The infrastructure for secure-by-default vibe coding exists. It just is not the default yet.

Until it is, the gap has to be filled by builders who know what to check — and who check it.

Before You Ship

[ ] No API keys or secrets in frontend code
[ ] Gitleaks run before pushing to the repository
[ ] Row-Level Security enabled on every database table with user data
[ ] Every API endpoint requires authentication, or is explicitly marked public
[ ] Rate limiting enabled on registration and data endpoints
[ ] NEXT_PUBLIC_ prefix checked — nothing sensitive uses it
[ ] Snyk or equivalent scanned your dependencies
[ ] Asked AI to review your code specifically for security issues
[ ] Opened the browser dev tools and checked what a stranger can see

AI is making software creation more accessible than ever. More people building means more innovation, more creativity, more diverse voices entering technology. That is a genuinely good thing.

But software engineering has always been more than generating working code. There is a layer underneath every application — trust, security, permissions, responsibility — that still belongs to the person who shipped it.

You do not need to learn everything before you build. You just need to know the layer exists, and make a habit of checking it.

The checklist is above. The tools are free. The rest is discipline. The future of software may be AI-assisted. But responsibility is still human.

Found this useful? Share it with someone who just shipped their first AI-built app. The person who needs it most is usually the one who doesn't know they need it yet.

Building My First AWS VPC and EC2 Environment with Terraform: A Beginner-Friendly Guide for Career Changers

Benjamin Tetteh — Fri, 08 May 2026 20:47:37 +0000

Not long ago, terms like “VPC,” “subnet,” and “Terraform” would have made my eyes glaze over. While my background wasn’t originally rooted in cloud engineering, I’ve always been fascinated by how modern infrastructure is designed, automated, and scaled behind the scenes.

Now, partway through my DevOps journey, I’ve gone from simply reading about cloud infrastructure to actually building it, using Terraform to provision a fully functional AWS network entirely through code.

If you're reading this while sitting at a career crossroads — maybe you're a teacher, an accountant, a customer service rep, or anyone wondering "can I really break into tech?" I want this post to be your proof that yes, you absolutely can.

Before we touch any code...

Let's understand why everything exists. Tools make a lot more sense that way. Think of it like building a neighbourhood. Imagine you're a city planner given a plot of land. Your job is to:

Draw the boundary of the land — this is your VPC (Virtual Private Cloud). It defines your space in AWS. Nothing gets in or out unless you say so.

Divide the land into zones — some areas are public (like a shopping street anyone can visit) and some are private (like a gated estate — no outsiders allowed).

Build a gate to the outside world — this is the Internet Gateway (IGW). The single controlled entrance between your network and the internet.

Set the traffic rules — Route Tables tell your network traffic exactly where to go, like road signs.

Construct buildings inside the neighbourhood — these are your EC2 instances, the virtual servers that actually run applications and services.

Hire security guards for the buildings — these are your Security Groups, which act like firewalls controlling who can access your servers and through which doors (ports).

💡 Why Terraform instead of clicking around in AWS?
Clicking in the AWS console is slow, hard to repeat, and easy to mess up. Terraform lets you write your infrastructure as code — describe what you want, run one command, and it builds everything consistently every time. This is called Infrastructure as Code (IaC) and employers actively look for this skill.

The project structure

terraform-vpc/
├── main.tf       # The blueprint — everything to build
├── variables.tf  # The settings — values we can change
└── outputs.tf    # The receipt — shows what got created

Think of main.tf as the architect's drawing, variables.tf as the customizable options, and outputs.tf as the summary report after construction is done.

Step 1: Setting up Terraform — the provider block

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.region
}

The first block tells Terraform: "We're working with AWS, and we want version 5 of the AWS plugin." That plugin is called a provider — think of it as an adapter that lets Terraform talk to AWS.

The second block specifies which AWS region to build in. A region is a physical location with Amazon data centres — us-east-1 is Northern Virginia, USA.

Notice var.region? That means: "look up the value of region in my variables file."

Step 2: Creating the VPC — your cloud neighbourhood

resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr_block
  tags = {
    Name = "main-vpc"
  }
}

The cidr_block defines the total size of your network. 10.0.0.0/16 gives us room for up to 65,536 addresses — a big plot of land!

tags are just labels to help you find your resources in the AWS console. Always tag. Your future self will thank you.

Step 3: Internet Gateway — the front gate

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "main-igw"
  }
}

Without this, your VPC is sealed off — like a neighbourhood with no road to the outside world. Notice vpc_id = aws_vpc.main.id? Terraform links resources like this. It figures out the build order automatically.

Step 4: Subnets — carving the zones

# Public subnet (the shopping street)
resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = var.public_subnet_cidr_block
  map_public_ip_on_launch = true # Automatically assign public IPs to instances launched in this subnet
  tags = {
    Name = "main-public-subnet"
  }
}

# Private subnet (the gated estate)
resource "aws_subnet" "private" {
  vpc_id     = aws_vpc.main.id
  cidr_block = var.private_subnet_cidr_block
  tags = {
    Name = "main-private-subnet"
  }
}

We're carving our big VPC into zones. The public subnet (10.0.1.0/24) is for resources that need internet access, like web servers. The private subnet (10.0.2.0/24) is for sensitive things like databases — no direct internet access. The /24 gives each subnet 256 addresses.

map_public_ip_on_launch = true For resources inside a subnet to actually receive public internet access, instances launched there need public IP addresses. Without a public IP, an EC2 instance cannot be reached from the internet, even if everything else is configured correctly.

Step 5: Route tables — the traffic signs

# Public route table + association + internet route
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "main-public-rt" }
}
resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}
resource "aws_route" "public_igw" {
  route_table_id         = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.main.id
}

# Private route table + association (no internet route)
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "main-private-rt" }
}
resource "aws_route_table_association" "private" {
  subnet_id      = aws_subnet.private.id
  route_table_id = aws_route_table.private.id
}

The key line is destination_cidr_block = "0.0.0.0/0" pointing to the IGW. 0.0.0.0/0 means "any address on the internet" — this is what makes the public subnet actually public.

The private subnet gets its own route table but no internet route — isolated by design. The associations are the connectors that glue each table to its subnet.

Step 6: Security groups - for the public subnet

resource "aws_security_group" "public_sg" {
  name        = "public-sg"
  description = "Allow SSH and HTTP access"
  vpc_id      = aws_vpc.main.id

  # Allow SSH access from anywhere
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow HTTP access from anywhere
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow all outbound traffic
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "main-public-sg"
  }
}

A Security Group is basically a firewall attached to your EC2 instance. It decides who can enter, which ports are open, what type of traffic is allowed.

This Security Group allows:

SSH access (port 22)
HTTP web traffic (port 80)

cidr_blocks = ["0.0.0.0/0"] means “Allow traffic from anywhere on the internet.”

Step 7: Create EC2 instance in the public subnet

resource "aws_instance" "public_ec2" {
  ami             = var.ami_id
  instance_type   = var.instance_type
  subnet_id       = aws_subnet.public.id # This places the EC2 inside the public subnet
  security_groups = [aws_security_group.public_sg.id]
  tags = {
    Name = "terraform-public-ec2"
  }
}

ami = var.ami_id An AMI (Amazon Machine Image) is essentially a template for the operating system. Think of it like installing Windows or Linux onto a new computer. I used an Amazon Linux AMI for this project.

instance_type = var.instance_type This defines the size and power of the virtual server. I used t3.micro (referenced in the variables.tf file) which is lightweight and great for learning purposes.

subnet_id = aws_subnet.public.id This places the EC2 instance inside the public subnet we created earlier.

Then security_groups = [aws_security_group.public_sg.id] attaches the firewall rules to the server.

Step 8: Variables — the settings file

variable "region" {
  type        = string
  description = "AWS region to deploy resources in"
  default     = "us-east-1"
}

variable "vpc_cidr_block" {
  type        = string
  description = "CIDR block for the VPC"
  default     = "10.0.0.0/16"
}

variable "public_subnet_cidr_block" {
  type        = string
  description = "CIDR block for the public subnet"
  default     = "10.0.1.0/24"
}

variable "private_subnet_cidr_block" {
  type        = string
  description = "CIDR block for the private subnet"
  default     = "10.0.2.0/24"
}

variable "ami_id" {
  type        = string
  description = "AMI ID for the EC2 instance"
  default     = "ami-0c94855ba95c71c99"
}

variable "instance_type" {
  type        = string
  description = "Instance type for the EC2 instance"
  default     = "t3.micro"
}

Instead of hardcoding values everywhere, I used variables for region, subnet CIDRs, AMI ID, instance type. This makes the infrastructure easier to modify and reuse later.

For instance, instead of repeating "us-east-1" everywhere, we define it once in variables. Want to deploy to a different region? Change it in one place, not everywhere. Clean, reusable, professional.

Step 9: Outputs — the receipt

# output the VPC id
output "vpc_id" {
  value = aws_vpc.main.id
}

# output the public subnet id
output "public_subnet_id" {
  value = aws_subnet.public.id
}

# output the private subnet id
output "private_subnet_id" {
  value = aws_subnet.private.id
}

# EC2 Public IP
output "ec2_public_ip" {
  value = aws_instance.public_ec2.public_ip
}

# EC2 Instance ID
output "ec2_instance_id" {
  value = aws_instance.public_ec2.id
}

After Terraform finishes, outputs are printed in your terminal — like a receipt. Instead of logging into AWS to find your VPC ID, Public IP, EC2 Instance ID, Terraform just hands it to you. That means you can immediately locate the server, connect to it and verify the deployment worked, without manually digging through the AWS console.

Deploying the infrastructure

Once everything was configured, I used the standard Terraform workflow:

terraform init     # Download the AWS provider and initialize Terraform
terraform fmt      # Format the code neatly
terraform validate # Check for configuration errors
terraform plan     # Preview what Terraform will create
terraform apply    # Provision the infrastructure

And when you're done experimenting:

terraform destroy  # Tear everything down to avoid unnecessary AWS charges

The full architecture

Challenges I faced

Like every beginner, I made mistakes:

Using quotes incorrectly around variables inside main.tf which broke my configuration
Confusion around route tables and associations
Understanding how IGW actually connects to subnets
Debugging Terraform errors for the first time

But each error helped me understand Terraform and AWS networking better.

What's next?

I plan to explore:

Connecting to the EC2 instance via SSH
Installing NGINX and hosting a simple webpage
Terraform modules
Remote state management with S3
CI/CD pipelines with GitHub Actions
Docker and container deployment I'm still learning and still building. Follow along!

Enhancing Cybersecurity in Healthcare: A NIST Cybersecurity Framework Assessment

Benjamin Tetteh — Sat, 08 Mar 2025 19:10:57 +0000

Cybersecurity threats are an ever-growing concern, especially in industries handling sensitive data like healthcare. To address these risks, I conducted a NIST Cybersecurity Framework (CSF) Assessment for a fictional mid-sized healthcare provider, MediHealth Solutions Inc., as part of my cybersecurity portfolio.

Project Overview
The goal of this assessment was to evaluate MediHealth’s security posture, identify vulnerabilities, and recommend remediation strategies in alignment with NIST CSF and HIPAA requirements. The assessment covered key cybersecurity domains, including identifying assets, implementing protective measures, detecting threats, responding to incidents, and ensuring recovery.

Key Findings
One of the major findings was the presence of legacy system risks. The organization relied on an outdated Electronic Health Records (EHR) system, increasing its exposure to unpatched vulnerabilities. To mitigate this risk, I recommended system upgrades and the deployment of automated patch management. Another critical issue was human factors in cybersecurity. A phishing simulation revealed that 30% of employees fell for phishing attempts, highlighting the need for increased awareness. I proposed a cybersecurity training program using platforms like KnowBe4 and GoPhish to educate employees on recognizing and avoiding phishing attacks.

Additionally, I identified the absence of an Incident Response Plan (IRP) to handle ransomware and data breaches. Without a structured IRP, the organization risked delayed responses to security incidents. To address this, I developed a comprehensive IRP based on NIST SP 800-61 Rev. 2, outlining clear response procedures and implementing quarterly tabletop exercises to ensure readiness. Weak access controls were another major concern, as critical systems lacked Multi-Factor Authentication (MFA) and Role-Based Access Controls (RBAC). Enforcing MFA for all high-risk accounts and restricting access based on user roles significantly improved the security posture. Furthermore, the lack of centralized monitoring meant that the organization had no Security Information and Event Management (SIEM) system to detect and analyze threats in real-time. To remedy this, I recommended deploying SIEM tools such as Splunk or ELK Stack, along with Intrusion Detection Systems (IDS/IPS) to enhance threat detection and mitigation capabilities.

Relevance to My Cybersecurity Journey
As a self-motivated cybersecurity enthusiast, this project was instrumental in refining my skills in risk assessment, incident response, compliance, and security control implementation. Conducting this assessment independently showcased my ability to analyze real-world cybersecurity threats, design security solutions, and align them with industry standards. This hands-on experience reinforced my understanding of security governance, risk management, and compliance (GRC), which are crucial skills for cybersecurity professionals. It also highlights my capability to work autonomously, proactively learn, and apply best practices in enterprise security.

This project provided invaluable experience in conducting enterprise-wide cybersecurity assessments, aligning security controls with compliance frameworks, and implementing actionable security improvements. It reinforced the importance of a structured approach to risk management, proactive threat detection, and continuous cybersecurity awareness training. Cybersecurity is a constantly evolving field that requires a mix of technical expertise and risk-based decision-making. This NIST assessment has been a valuable addition to my cybersecurity portfolio, demonstrating my ability to analyze security gaps and implement industry-standard security measures.

📌 Check out the full assessment here.

💬 Let’s discuss! Have you worked with the NIST Cybersecurity Framework before? How do you approach security risk assessments in your projects?

From Data Breach to Insight: Exploring the Intersection of Cybersecurity and Communication

Benjamin Tetteh — Sat, 08 Mar 2025 18:22:00 +0000

I recently received an email notifying me of a data breach at a major public service provider in London that I rely on. Before this, I never truly considered that I could be directly impacted by a breach, even though they’re frequently reported in the media. With incidents like these becoming increasingly common, it was unsettling to think that my personal data may have been compromised. However, the service provider has been proactive, sending follow-up emails in the weeks following the initial notification, outlining the incident and their remediation efforts. As a communications professional, I found their response reassuring.

Data breaches are becoming so frequent that they’re starting to feel like notifications from my telecom provider—constant, annoying, and impossible to ignore.

Coincidentally, I’d been enrolled in the Google Cybersecurity Certificate course. My initial foray into cybersecurity was driven by the assumption that I would be diving into a highly technical world—one filled with firewalls, encryption, and endless lines of code, likely while wearing a hoodie in a dark room. While I certainly encountered that (minus the hoodie), what piqued my interest was discovering how crucial communication is within the cybersecurity landscape.

In today's hyper-connected world, cybersecurity has become one of the most critical aspects of every organization's operational strategy. It’s not just about protecting sensitive data or ensuring business continuity; it’s also about building and maintaining trust with customers. I’ve come to realize that cybersecurity is more than just a technical responsibility; it’s also a communications challenge.

The Intersection
Why? Because no matter how sophisticated an organization's defenses are, human error remains one of the most significant risks. This is where effective communication plays a pivotal role. While studying incident response plans, I realized that when a data breach occurs, it’s not just the IT team scrambling behind the scenes to secure systems and data. The communications team is equally essential in ensuring that stakeholders—whether customers, employees, or partners—are informed and reassured. Organizations are legally obligated to disclose breaches, and the quality, clarity, and timeliness of that communication often determine whether trust is preserved or lost. Cybersecurity professionals may patch vulnerabilities and mitigate future risks, but without clear, strategic communication, even the best technical response can leave people in the dark and cause unnecessary panic.

One of the most critical elements of cybersecurity is awareness. Many threats—from phishing to social engineering—target the weakest link: people. Ensuring that employees and stakeholders understand the risks and how to avoid them requires more than a one-time memo or a check-the-box training module. It requires consistent, clear, and engaging communication. By translating complex technical concepts into easily understandable information, communicators can help create a culture of security. This extends to everything from regular awareness campaigns to engaging content that demystifies topics like password security, device protection, and data privacy.

Gaining Technical Expertise: The Next Frontier
On the flip side, my experience with the technical aspects of cybersecurity has also been eye-opening. Through the Google Cybersecurity Certificate, I’ve gained hands-on experience with tools like Python, Linux, and SQL, and I’ve worked with Security Information and Event Management (SIEM) tools to identify risks and mitigate threats. Understanding these technologies has allowed me to better appreciate the technical side of cybersecurity.

My observations and learnings from the past weeks have made me appreciate the relationship between cybersecurity and communications. Both disciplines require a keen understanding of risk, an ability to anticipate and mitigate problems, and a focus on protecting people—whether through securing data or ensuring that information is clear and accessible. As I continue to explore both fields, I’m excited by the possibilities that lie at this intersection.

On to the next.

PS: I first published this article on my LinkedIn profile on 16/9/24.