DEV Community: Tariq Davis

What Happens When the Breach Happens Somewhere the World Forgot to Defend

Tariq Davis — Sun, 17 May 2026 04:36:09 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

What Happens When the Breach Happens Somewhere the World Forgot to Defend

I'm a 21-year-old Cybersecurity and Digital Forensics student at Caribbean Maritime University in Jamaica. My research group spent months building an academic proposal on IoT forensic challenges in the Caribbean — the gap in standards, the resource constraints, the fact that most forensic frameworks were designed for labs that don't exist here.

That research sat in a document. It felt incomplete. Not wrong — just theoretical.

Then I built Threat Trace in 12 days for the Gemma 4 Challenge and something clicked.

The problem I kept running into

Caribbean institutions — hospitals, universities, government facilities — are deploying IoT devices at scale. Smart sensors, networked cameras, connected infrastructure. Most of it is third-party managed, under-resourced, and running firmware that hasn't been updated in years.

When a breach happens, the forensic playbook assumes things that don't exist here. Dedicated forensic hardware. Large IT teams. Vendor support that shows up same-day. Regulatory frameworks that actually map to the local legal environment.

None of that is guaranteed in Jamaica. Most of it isn't there at all.

So when I started thinking about what to build for this challenge, I didn't want to build another generic demo. I wanted to build something that made the problem tangible — not a report you read and forget, but something you feel.

Why a simulator and not a tool

There's a difference between knowing forensic methodology and understanding why it matters.

I've studied the 6-stage forensic process. I know what chain of custody means. But reading about it and making a decision under pressure are different things. The second one sticks.

I built Threat Trace so that when you choose to reboot a compromised sensor instead of isolating it first, you feel it. The integrity meter drops. The feedback tells you exactly what you just destroyed. And then you have to keep going with contaminated evidence.

That's the lesson. Not a textbook explanation — the consequence.

The game generates a full investigation from any IoT incident you describe. Gemma 4 31B reads your scenario and builds 6 forensic stages, each with real decision points, real evidence, and real consequences for wrong choices. At the end you download a forensic report — actual methodology, actual findings, usable outside the game.

How I actually built it

I didn't start with code. I started with a scenario.

"A smart water pressure sensor at a children's hospital in Mandeville began sending encrypted packets during maintenance windows — always 1AM-3AM, never consecutive nights. A nurse in the maternity ward noticed hot water pressure dropped every time the anomaly occurred."

I wrote that prompt and fed it to Gemma 4 through the Google AI Studio API. What came back wasn't what I expected.

Gemma didn't just map an attack technique. It identified a function in the generated firmware called trigger_valve_bleed() — called immediately before send_encrypted_payload(). The physical pressure drop wasn't a side effect. It was a signal. The attacker was using the hospital's water valves as an out-of-band heartbeat to confirm successful exfiltration to a local observer.

I didn't tell Gemma to find that. It reasoned to it from context.

It also caught that the non-consecutive timing was deliberate evasion of threshold monitors. And it noted that a nurse — not IT, not a SIEM alert — was the first line of detection. That detail is the most Caribbean thing in the whole report. And Gemma put it there.

That's when I knew the model could carry this build.

The architecture decision that made it free to run

One API call per investigation. That's it.

When you submit a scenario, Gemma generates everything upfront — all 6 stages, every choice, every consequence, every narrative, the full report. During gameplay there are zero API calls. Every response is instant because it's already computed.

This matters because the communities this tool is meant for can't afford per-request costs at scale. Front-loading the generation makes free 24/7 deployment viable. Cached scenarios cost nothing to replay.

The structured JSON output from Gemma 4 was critical here. The model's thinking mode can produce loose text that breaks parsing. Forcing the output format through the API config takes the parse failure rate from around 50% to near-perfect. The game state is deterministic — the correct answer is pre-computed, so scoring requires no AI at runtime.

Why Gemma 4 31B specifically

Three reasons that weren't negotiable.

Context window. IoT incidents don't happen in isolation. Logs from 12 sensors, network captures, firmware analysis, infrastructure context — it all needs to be in one prompt for the model to reason across it. Gemma 4 31B's 256K context window handles that. Most open models cap at 8K-32K. That's not enough.

Structured output. The game lives or dies on clean JSON. Gemma 4 delivers it when you configure the output correctly.

Open model. The whole point of this build is accessibility. Using a closed API to solve an accessibility problem is a contradiction. Gemma is open. Anyone can run it locally, self-host it, extend it. That matters for the communities this is built for.

What the Caribbean context actually changes

Most forensic simulators are built for abstract environments. Generic corporations, unnamed cities, fictional institutions.

Every case Threat Trace generates is grounded in real Caribbean constraints — NWC managing critical hospital infrastructure remotely, university IT volunteers running forensic investigations with borrowed hardware, JCF Cybercrime Unit reporting requirements, the Jamaica Cybercrime Act.

When Gemma generates a case set in Mandeville or St. Elizabeth, it doesn't just change the location. It changes the available resources, the institutional dynamics, the observation chain. The Mandeville hospital case had a nurse as the first line of detection because the IT team was small and overwhelmed. Gemma inferred that from the context I gave it.

That specificity is what makes the tool feel real rather than academic.

What I actually learned

I started this as a student who'd written a research proposal about IoT forensics in the Caribbean. I finished it having built something that demonstrates the problem more clearly than the proposal did.

The 40/60 score and 70% evidence integrity on my first run through my own simulator told me more about my actual forensic decision-making than any exam has.

Gemma 4 didn't just power the build. It challenged me inside it.

That's what an open model at this capability level makes possible — not just better apps, but tools that give real feedback to the people who need it most, running in environments that can't afford anything else.

🎮 Play Threat Trace →

🔗 GitHub

I Built an IoT Forensic Investigation Simulator Powered by Gemma 4 — Paste Any Incident, Get a Full Case with Evidence, Decisions, and a Forensic Report

Tariq Davis — Sat, 16 May 2026 07:00:53 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

I built Threat Trace — an IoT forensic investigation simulator that takes any incident scenario and turns it into a playable 6-stage investigation, powered by Gemma 4 31B.

You describe an incident. Gemma reads it and generates a complete forensic case — real evidence, real decision points, real consequences. Every stage puts you in front of a choice. Wrong calls contaminate your evidence or break chain of custody. At the end you get a downloadable forensic report you can actually use.

This isn't a quiz. It's a training tool built for people who don't have access to expensive forensic labs — specifically designed around the Caribbean institutional context: small IT teams, limited hardware, JCF Cybercrime Unit reporting requirements, and the kinds of incidents that actually happen here.

Demo

🎮 Play Threat Trace →

Try the pre-loaded scenarios or paste your own IoT incident. Every input generates a unique case.

Code

🔗 github.com/FlowArchitect895/Threat-Trace

How I Used Gemma 4

I chose Gemma 4 31B Dense. Here's why that was the only real option for this project.

The Architecture: Front-load everything

Gemma does all the heavy work once — at generation. When you submit a scenario, one API call produces the entire investigation: all 6 stages, every choice, every consequence, every narrative, and the final report. During actual gameplay there are zero API calls. Every response is instant because it's already been computed.

This makes free 24/7 deployment viable. Cached scenarios cost nothing to replay.

Why 31B Dense specifically

256K context window. IoT incidents don't happen in isolation — they involve logs from multiple devices, network captures, firmware dumps, infrastructure context. I needed a model that could hold an entire incident in one prompt and reason across all of it. No other open model has that context window.

Structured output reliability. Gemma 4's thinking mode produces clean, parseable JSON when you force the output format correctly. Without it the parse failure rate is around 50%. With it — near perfect. The game state depends on deterministic output, so this wasn't optional.

Open model. The whole point of this build is accessibility. Running on a closed API defeats that for the communities this tool is meant to serve.

What Gemma actually does

The depth surprised me. I threw this at it:

Gemma mapped it to T1041 — Exfiltration Over C2 Channel and built the case around an Industrial IoT water pressure sensor. But it didn't stop at the attack technique. It identified that the pressure drop was caused by a function called trigger_valve_bleed() — executed immediately before send_encrypted_payload(). The physical action preceded the data transmission. That means the attacker was using valve actuation as an out-of-band heartbeat to confirm successful exfiltration to a local observer.

It also caught that the non-consecutive timing wasn't random — it was deliberate evasion of basic threshold monitors. And it flagged the exfiltrated payload as internal VLAN mapping data, identifying the sensor as a pivot point for lateral movement, not the final target.

A nurse found the breach. Not IT. Gemma put that in the analysis without being told to.

That's adversarial reasoning. Not pattern matching.

The Caribbean context layer

This is what makes it different from a generic forensic simulator. Every generated case includes:

Resource constraints realistic to Jamaican institutions — the Mandeville case used university tools to compensate for limited forensic hardware budgets
JCF Cybercrime Unit and Jamaica Cybercrime Act reporting requirements
Third-party utility dependencies — NWC managing critical hospital infrastructure with no on-site visits in 8 months
The human observation chain — a nurse, not a security system, was the first line of detection

That last point is the most Caribbean thing in the report. And Gemma put it there without being told to.

The downloadable report reflects all of this — not a game score, an actual forensic document.

Judging criteria mapped

Intentional model selection — 256K context for multi-artifact IoT scenarios, structured JSON for game state reliability, open model for the communities this serves.

Technical implementation — front-loaded generation, zero-cost runtime, structured output parsing, deterministic scoring with pre-computed consequences.

Creativity — IoT forensics as an interactive investigation with real physical consequence. A water pressure drop in a maternity ward as the first indicator of compromise. Caribbean context as a first-class feature, not an afterthought.

Usability — three preloaded scenarios, open input for any incident, downloadable forensic report with real methodology output that investigators can actually use.

Most Beginners Approach Bug Bounty Completely Wrong

Tariq Davis — Sat, 09 May 2026 01:24:17 +0000

Bug Bounty Isn’t What You Think It Is

By Tariq Davis

I’m not a veteran bug bounty hunter.

I’m a cybersecurity student who got curious about how people legally get paid to break systems. That curiosity pulled me into bug bounty, and the first thing I noticed was how messy the beginner information is.

Most content either:

assumes you already know what you’re doing,
or turns simple ideas into overly technical theory.

So I started building the kind of guide I wish I had when I began.

No hype. No fake “make thousands overnight” promises.

Just the actual framework.

What Bug Bounty Actually Is

Bug bounty programs are simple in concept:

Companies pay independent researchers to find and responsibly disclose vulnerabilities in their systems.

You:

test systems that are in scope,
find a vulnerability,
write a report,
submit it,
and get paid if it’s valid.

That’s the model.

What makes it interesting is the incentive structure behind it.

The company wants weaknesses discovered before malicious actors find them. You get rewarded for helping expose those weaknesses legally and responsibly.

It’s one of the few spaces where the attacker mindset and business incentives genuinely align.

The Severity Ladder Beginners Misunderstand

A lot of beginners enter bug bounty thinking about massive payouts immediately.

That mindset usually kills consistency before it even starts.

Here’s the reality:

P1 — Critical

Remote code execution. Full account takeover. Large-scale compromise.

Huge payouts.
Not beginner territory.

P2 — High

Authentication bypasses, major exposure issues, serious privilege escalation.

Possible later on.
Still difficult.

P3 — Medium

IDORs. Stored XSS. CSRF.

This is where beginners should realistically focus.

Real vulnerabilities. Real learning. Real payouts.

P4 — Low

Information disclosure. Open redirects. Missing security headers.

A lot of first accepted reports land here.

And honestly? That’s fine.

A P4 still proves:

your process worked,
your report was accepted,
and you successfully navigated a real security workflow.

That matters more than chasing criticals on day one.

The Real Skill Isn’t “Finding Bugs”

This is the part most beginner content misses completely.

Bug bounty isn’t just about running tools and hoping something appears.

The real skill is learning how to understand systems.

The best researchers spend huge amounts of time on:

recon,
mapping attack surfaces,
identifying patterns,
and understanding how applications behave.

You’re not just searching for vulnerabilities.

You’re building a map.

And once the map becomes clearer, the weaknesses become easier to notice.

That shift in perspective changes everything.

Why Most Beginners Burn Out

A lot of people approach bug bounty like a lottery system:

random target,
random tools,
random expectations.

Then they quit after finding nothing for weeks.

But bug bounty is closer to pattern recognition than gambling.

The early stage is mostly:

learning systems,
improving observation,
documenting behavior,
and building methodology.

That foundation matters more than flashy payouts.

Final Thoughts

The free preview of the Bug Bounty Starter Kit was designed specifically for beginners who want a grounded introduction without the noise.

It covers:

what bug bounty actually is,
how severity works,
and where beginners realistically belong.

The full guide expands from there into tooling, recon workflows, reporting structure, and practical execution.

You can check it out at:
www.tagzauthor.com

More cybersecurity frameworks and beginner-focused guides are coming soon.

Support TagzAuthor: ko-fi.com/tagzauthor
My author page: Amazon Bookstore