DEV Community: siyadhkc

I Built My Own AI Research Assistant for Cybersecurity — Here's the Honest Breakdown

siyadhkc — Wed, 17 Jun 2026 15:16:16 +0000

Most people use AI the same way:

Open ChatGPT, Claude, or Gemini.
Ask a question.
Get an answer.
Close the tab.

I did that too—until I started spending more time on cybersecurity research, vulnerability analysis, and application security. At some point, it felt strange researching privacy and security while sending chunks of my work to infrastructure I didn't control.

So I decided to build my own.
...
No API keys. No subscriptions. No cloud processing. Just a Ryzen 7 7435HS, 16GB RAM, an RTX 3050, and a growing curiosity about what actually happens behind the chatbot interface.

The goal was simple: create a local AI research assistant that could search my notes, help with security research, and keep everything on my machine. What I didn't expect was that building it would teach me more about AI, LLMs, RAG, agents, and AI security than years of simply using them ever could.

Here's what I built and what I learned.

First: What "Building Your Own AI" Actually Means

Let’s kill the ambiguity before we go any further. There are three distinct tiers to this:

Level 1 — Running an existing model locally: You download a pre-trained model and run inference on your own hardware. You didn't create the intelligence; you stopped renting it. This is what most developers mean when they say "I built my own AI." It's also what I did. No shame in it.
Level 2 — Customizing a foundation model: You take a pre-trained model and augment it with your own data — notes, research, codebases, documents. This is RAG (Retrieval-Augmented Generation) or fine-tuning territory. Most startups building "AI assistants" operate here. They did not build a model; they adapted one. There's a difference, and the marketing conveniently forgets it.
Level 3 — Training from scratch: OpenAI, Anthropic, Google, Meta. Thousands of GPUs, millions of dollars, specialized research teams. Not realistic for individuals.

I'm at Level 1 moving toward Level 2. That's the practical sweet spot for anyone doing real work without a datacenter.

How LLMs Actually Work (The Part Nobody Explains Clearly)

LLMs are prediction systems. They don't think. They predict the statistically most likely next token given everything in their context window.

Input:  "The capital of France is"
Output: "Paris"

Do that billions of times across a massive training corpus, and complex, reasoning-like behavior emerges. That's genuinely it. No magic. No ghost in the machine. Just very expensive statistics that happen to be incredibly useful.

Understanding this matters for security work specifically:

Prompt Injection: The model cannot fundamentally distinguish between your system instructions and an attacker's instructions injected through retrieved content.
Hallucinations: The model is predicting probable text, not retrieving ground truth.
Verification: You should never blindly trust model output on anything critical without verification.

⚠️ The core paradox of LLMs: The model is confident. The model is sometimes wrong. These two facts coexist comfortably and will continue to cause problems for everyone who forgets them.

Why Local? The OPSEC Argument

For general-purpose use, cloud AI is fine. For security research, the calculus is completely different. When you use a cloud model:

Your prompts leave your machine.
Sensitive context — CVEs you're analyzing, vulnerability writeups, client infrastructure details — passes through third-party infrastructure.
You have zero visibility into what's logged, retained, or used for training.

If you're doing bug bounty, AppSec auditing, or anything involving non-public vulnerability data, feeding that into a cloud API is an OPSEC problem. Full stop.

Local solves this. Your data stays on your hardware. No terms of service to audit. No compliance risk from third-party data processing. No API costs. It works completely offline, allowing unlimited experimentation without watching a token counter.

The tradeoff? Setup takes a weekend and your hardware has strict limits. Still worth it.

The Tool: Ollama

Ollama is the easiest on-ramp to local AI. Think of it as Docker for language models — it handles downloads, quantization, GPU acceleration, and exposes a clean REST API at http://localhost:11434.

Installation & Setup

# Mac / Linux installation
curl -fsSL https://ollama.sh | sh

# Pull and run a model
ollama run qwen3:8b

That's it. The model downloads, loads into memory, and the API goes live.

What's happening under the hood:

Download Model Weights ──> Load Into RAM/VRAM ──> Tokenize Input ──> Transformer Inference ──> Local REST API

Ollama is a model manager, a runtime, and an API server all in one. The intelligence is in the model weights; Ollama is just the plumbing that makes those weights usable without a PhD in infrastructure.

Handy Ollama CLI Commands

ollama list         # See installed models
ollama pull qwen3:8b # Download a specific model
ollama rm llama3    # Remove an unwanted model
ollama ps           # See what models are currently loaded in memory

Picking the Right Model for Your Hardware

Not all models fit on all machines. Here is an honest breakdown of the hardware requirements:

RAM / VRAM	Recommended Model	Experience Notes
8GB	Gemma 4 4B or Phi-4 Mini	Fits cleanly, decent quality, highly efficient
16GB	Qwen3 8B or DeepSeek R1 Distilled 8B	The Sweet Spot. Fast and highly capable
32GB+	DeepSeek R1 14B–32B	High-level technical reasoning, heavily data-intensive

My daily driver: Qwen3 8B. It provides strong technical reasoning, handles code exceptionally well, is Apache 2.0 licensed, and runs cleanly on my laptop without fighting for VRAM.

The 2026 Open Model Landscape

The open-model ecosystem moves fast. Here's where things actually stand right now:

Qwen3 (Alibaba): Currently one of the strongest all-around open families. Apache 2.0, excellent multilingual, and top-tier technical performance. The 4B and 8B variants run wonderfully on consumer hardware. This is my default recommendation.
DeepSeek V4 & R1: DeepSeek changed the industry when R1 dropped. MIT licensed, it matches frontier models on math and code benchmarks. The distilled 8B and 14B variants bring heavy-duty reasoning right to consumer hardware.
Kimi K2.5: Excellent tool usage and designed specifically for agentic workflows. Worth watching if you're building automated agents rather than just doing Q&A.
GLM-5.1: Focused on advanced reasoning and agentic tasks. Particularly impressive for structured technical work.
Llama 4 Scout (Meta): The first Mixture of Experts (MoE) architecture in the Llama family, sporting a massive 10-million token context window. However, it requires ~55GB of VRAM, making it impractical for standard laptops.
Gemma 4 (Google): Highly efficient and accessible. This is your best option if you need capable reasoning on strictly constrained hardware resources.

💡 The honest takeaway on hardware: 8GB of VRAM was borderline a couple of years ago. It's cramped now. 12GB is the modern floor for serious local work, while 16GB gives you room to actually experiment.

The Problem With Raw Models: They Don't Know Your Stuff

A stock model only knows what it was trained on. It doesn't know your security notes, your project internals, your custom vulnerability writeups, or yesterday's newly disclosed CVEs.

That gap is the main limitation of Level 1. The fix is RAG.

RAG: Teaching Your AI Your Own Knowledge

RAG stands for Retrieval-Augmented Generation. The concept is simpler than the name suggests:

User Asks Question 
       │
       ▼
Search Vector Database (ChromaDB)
       │
       ▼
Retrieve Relevant Document Chunks
       │
       ▼
Inject Context into System Prompt (Question + Source Chunks)
       │
       ▼
Local LLM Generates Grounded Answer

A Practical Local RAG Implementation in Python

Here is how you can spin up a local RAG pipeline using LangChain and Ollama.

pip install chromadb langchain langchain-community langchain-ollama

from langchain_core.prompts import ChatPromptTemplate
from langchain_ollama import OllamaEmbeddings, ChatOllama
from langchain_community.vectorstores import Chroma
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain.chains import create_retrieval_chain
from langchain.chains.combine_documents import create_stuff_documents_chain

# 1. Your proprietary knowledge base 
your_docs = [
    "BOLA (Broken Object Level Authorization) occurs when an API doesn't verify the requesting user has permission to access the specific object. Most common API vulnerability in 2026.",
    "JWT tokens must be verified server-side. Common mistakes: not checking the signature algorithm, skipping expiry validation, or accepting 'none' as a valid algorithm.",
    "Django DEBUG=True in production exposes detailed stack traces, environment variables, and raw database queries to anyone who triggers an internal server error."
]

# 2. Split text into digestible chunks
text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = text_splitter.create_documents(your_docs)

# 3. Initialize local embeddings and store in ChromaDB
embeddings = OllamaEmbeddings(model="qwen3:8b")
vector_store = Chroma.from_documents(chunks, embeddings)
retriever = vector_store.as_retriever(search_kwargs={"k": 2})

# 4. Connect to local LLM
llm = ChatOllama(model="qwen3:8b", temperature=0)

# 5. Define the RAG prompt system
system_prompt = (
    "You are a security research assistant. Use the following pieces of retrieved context "
    "to answer the question. If you don't know the answer, say that you don't know.\n\n"
    "Context:\n{context}"
)
prompt = ChatPromptTemplate.from_messages([
    ("system", system_prompt),
    ("human", "{input}"),
])

# 6. Create and execute the RAG chain
question_answer_chain = create_stuff_documents_chain(llm, prompt)
rag_chain = create_retrieval_chain(retriever, question_answer_chain)

response = rag_chain.invoke({"input": "What is BOLA and why is it dangerous?"})
print(response["answer"])

Point this script toward your local Markdown folders, OWASP PDFs, PortSwigger writeups, or disclosed HackerOne reports, and you instantly have a local research assistant that knows your actual data.

RAG vs. Fine-Tuning: The Classic Misconception

Beginners almost always assume they need to fine-tune a model to teach it new information. Usually, they are wrong.

┌───────────────────────────────────────┬───────────────────────────────────────┐
│               USE RAG WHEN            │            USE FINE-TUNING WHEN       │
├───────────────────────────────────────┼───────────────────────────────────────┤
│ • Knowledge changes frequently        │ • You need style/tone behavioral shifts│
│   (new CVEs, fresh writeups)          │ • You need strict output formatting   │
│ • You need explicit source citations  │ • You want deep task specialization   │
│ • You want fast, zero-cost iteration  │ • You have a vast, clean dataset      │
└───────────────────────────────────────┴───────────────────────────────────────┘

The play: Always start with RAG. Fine-tune only if RAG fails to meet your structural formatting needs after extensive testing.

The Next Evolution: MCP (Model Context Protocol)

RAG gives a model knowledge. MCP gives a model tools.

Model Context Protocol allows local LLMs to safely step outside their sandbox and interact natively with systems:

              ┌──> GitHub Repository
              ├──> Live CVE Databases
User ──> Agent ──> Tools ──> ├──> Burp Suite Reports
              ├──> Local Filesystem
              └──> System Logs

A chatbot answers questions; an agent completes tasks. Imagine an automated workflow: Find latest Django CVEs ──> read advisories ──> compare against requirements.txt ──> generate a remediation report ──> open a local GitHub issue. That's the power of tool integration.

The Security Risks Inside Your Own Local Tools

Running AI locally protects your data from leaving your machine, but it shifts the application attack surface. Prompt injection isn't theoretical—it's cataloged under real CVEs (e.g., CVE-2025-53773 in GitHub Copilot allowing remote code execution).

When building local RAG and agent architectures, you must defend against:

Indirect Prompt Injection: If your RAG system ingests external data (scraped web pages, untrusted security feeds, public PDFs), an attacker can embed malicious instructions inside those sources. When the data is retrieved, it hijacks your model's execution flow.
Data Poisoning: Malicious or inaccurate documents dropped into your local directory will poison your vector database embeddings, leading to engineered hallucinations.
System Prompt Leakage: If your application logic depends on sensitive instructions or hardcoded parameters in the backend prompt configuration, assume they can be extracted by a clever prompt payload.
Blind Trust in Output: The model will give completely inaccurate code analysis or flawed exploit interpretations with absolute confidence. Always cross-reference AI-generated analysis with canonical sources like the NVD (National Vulnerability Database).

🛡️ The Defense: Apply least-privilege principles to your agent's tools, sandbox execution environments, sanitize inputs, and treat every retrieved document chunk as potentially untrusted adversarial input.

Honest Downsides of Going Local

The Hardware Ceiling: 16GB of RAM gets you to an 8B parameter model cleanly. DeepSeek R1 reasoning models at 14B or 32B require 24GB+ VRAM. If you want to run heavy models, you'll eventually need to expand your hardware or securely lease a decentralized bare-metal GPU (like RunPod or Vast.ai).
The Capability Gap: While the open-source gap closed drastically, frontier cloud models still hold an edge in multi-step complex synthesis across thousands of asynchronous documents.
Engineering Overhead: Building robust, stateful RAG pipelines with proper chunking, accurate embeddings, and tool orchestration takes real development time. Budget a weekend for setup, not an hour.

Why This Matters Beyond Just Privacy

Building a local AI system isn't about outperforming a trillion-dollar tech giant on a standard benchmark.

You cannot thoroughly audit AI-integrated applications if you treat the model as a black box. You cannot effectively reason about prompt injection vectors in an enterprise system if you have never engineered a document pipeline from scratch.

A few years ago, understanding the TCP/IP stack separated master engineers from beginners. Today, understanding LLM inference, embedding vectors, context windows, and tool integration protocols is becoming the new dividing line.

To paraphrase Richard Feynman: There is a profound difference between knowing the name of something and knowing the thing itself.

Build the thing. Then break it. Then secure it. That's where the real learning starts.

Let's Connect!

I write about API security, backend systems, and building tools from scratch.

💬 Drop your thoughts or local setups in the comments below!
🛠️ What models are you running on your local rig?

AI Just Got Scarier and More Powerful — And Nobody Is Talking About the Right Things

siyadhkc — Fri, 12 Jun 2026 10:07:21 +0000

A honest breakdown of where AI actually is in June 2026 — from purely my perspective.

Let me be upfront before you read a single word further.

I am not an AI promoter.

I read Books lot of books . Before I wrote a line of code, I spent above one years physically wiring network infrastructure — routers, switches, CCTV systems, cable runs in hot server rooms. That background makes me instinctively suspicious of anything that promises speed without understanding. And right now, in June 2026, the AI industry is running at full promotional speed while a lot of developers are quietly getting hurt by believing it.

So here's my actual take. Not a review. Not a tutorial. An honest read on what's happening, what's real, what's dangerous, and what you should actually do.

First: What Just Dropped Yesterday

I'm writing this on June 11th, 2026. Recently, Anthropic released Claude Fable 5 — and this one is different enough to talk about seriously.

Fable 5 is a Mythos-class model. Mythos is Anthropic's highest tier — previously restricted to a small group of security and infrastructure companies under something called Project Glasswing, because the cybersecurity capabilities were considered too powerful for general release. Yesterday they made a safeguarded version of that same class of model publicly available.

What does Mythos-class mean in practice? In their internal tests, Fable 5 migrated a Ruby codebase with 50 million lines of code in a single day. The same job would have taken an entire engineering team more than two months.

Let that sit for a moment.

The model scores more than 10% higher than Claude Opus 4.8 on key benchmarks — and Opus 4.8 was itself released just two weeks ago. The pace of capability improvement is no longer measured in quarters. It's measured in weeks.

Fable 5 is available now on the API at $10 per million input tokens and $50 per million output tokens. For Pro and paid subscribers, it's free through June 22nd — after that, usage credits will be required. The context window is 1 million tokens with 128,000 maximum output tokens.

There's also Claude Mythos 5 — the same base model but with some safety classifiers lifted, available only to approved organizations through Project Glasswing. Not for general access.

The cybersecurity angle matters to me specifically: Fable 5 has safeguards that route high-risk cybersecurity queries to the older Opus 4.8 instead. Anthropic explicitly built in a fallback for misuse. After 1,000+ hours of red teaming, no universal jailbreaks were found. That's not a trivial engineering achievement — and it tells you something about how seriously they're taking the dual-use problem.

What Else Is in the Field Right Now

The model landscape as of June 2026 — no hype, just the state of play:

GPT-5.5 (OpenAI, April 2026) — rebuilt architecture from scratch, leads on agentic workflows and multimodal tasks. 1 million token context window. The ecosystem is still the largest of any model.

Gemini 3.1 Pro (Google) — strongest benchmark on GPQA Diamond reasoning at 94.3%, integrates natively with Google Workspace. If you live in Google's stack, this is frictionless.

Grok 4 (xAI) — leads raw SWE-bench coding scores. Best features locked behind the $300/month SuperGrok tier.

DeepSeek V3.2 — delivers roughly 90% of the top proprietary model quality at 1/50th the price. The open-source gap has effectively closed for most real-world tasks.

The honest conclusion: there is no single best model. Anyone still arguing that debate is fighting 2024. The right model depends on your specific task, your stack, and what you can afford. Use Claude for long-context coding and agentic work. Use Gemini if you're embedded in Google Workspace. Use DeepSeek if cost is the constraint and quality is close enough.

The Statement That Broke the Developer Internet

At Davos in January 2026, Dario Amodei — CEO of Anthropic, the man who built Claude — said this to The Economist:

"We might be 6–12 months away from models doing all of what software engineers do end-to-end."

He backed it with a specific example: engineers inside Anthropic who told him they no longer write any code from scratch. "I just let the model write the code, I edit it," is how they described their workflow.

The internet predictably split into two camps — panic and dismissal. Both camps missed the point.

He's right that the act of translating a decided solution into working syntax is being automated. He's wrong — or at minimum imprecise — that this is the same thing as software engineering.

Here's the distinction that matters: writing code was never the hard part of software engineering. It was never where the real cognitive work lived. The hard part has always been the thinking before and after the code — understanding the system, identifying the failure modes, designing the authorization model, knowing what to do at 3am when production fails in a way nobody predicted.

AI can write the code. It cannot understand your system. That gap is where your value lives. The developers who forget this and outsource their thinking along with their typing are not becoming more productive. They are becoming fragile.

Klarna's CEO agreed with Amodei — his company's white-collar workforce will shrink by a third by 2030. Zoho's founder went further, publicly advising software developers to consider alternative livelihoods. These are not fringe opinions. They are the operating assumptions of the people running major technology companies right now.

The question isn't whether AI is changing software development. It obviously is. The question is: what specifically remains irreducibly human — and are you protecting that?

The Vibe Coding Data Is In — It's Bad

Here's where I get specific, because this is the part most AI articles skip.

Andrej Karpathy — one of the most respected AI researchers alive — coined the term "vibe coding" in February 2025. The pitch: describe what you want, accept all AI changes, stop reading diffs, let it handle everything. 4.5 million people watched that original post. A movement was born.

Eighteen months later, we have the data.

Veracode tested over 100 large language models across 80 coding tasks. 45% of AI-generated code contains OWASP Top-10 vulnerabilities. Two years of model improvements have not moved that number. Cross-site scripting defenses failed 86% of the time. Log injection, 88%.

A security firm built 15 identical apps using five popular vibe coding tools. The result: 69 vulnerabilities across those apps. Six were critical.

One developer ran a 30-day vibe coding experiment — coding speed went up fivefold initially, then the AI introduced passwords stored in plain text and API keys exposed in responses.

The Aikido Security founder put it most precisely: "Two engineers can now churn out the same amount of insecure, unmaintainable code as 50 engineers."

Speed without comprehension isn't productivity. It's technical debt with a delayed timer.

This is Taleb's Fooled by Randomness playing out in real time. The code runs, so it feels correct. The deployment succeeds, so it feels secure. The vulnerability — the injection flaw, the misconfiguration, the hardcoded credential — isn't visible until the breach, which arrives looking like bad luck rather than the direct consequence it was.

I study this from a security angle. What vibe-coded applications look like from an attacker's perspective is not complicated. They look like an invitation.

Where AI Is Actually Going — The Honest Version

Dario Amodei has described the trajectory like this: AI systems that are "broadly better than all humans at almost all things" — what he calls "a country of geniuses in a datacenter." He believes this arrives between 2026 and 2027. Anthropic's co-founder Jack Clark extended that slightly, saying by end of 2026 or 2027, AI will be smarter than a Nobel Prize winner across many major disciplines.

Andrej Karpathy's timeline is five to ten times more pessimistic. He argues useful autonomous agents are a decade out and that fundamental research breakthroughs — not just scaling — are required to get there.

Both are credible, informed people with access to the same data, arriving at opposite conclusions. That gap is not solvable by reading more takes on Twitter. The honest answer is: nobody knows. What we do know directionally:

Gartner predicts 40% of enterprise applications will include task-specific AI agents by end of 2026, up from less than 5% in 2025. The agentic AI market is projected to hit $251 billion by 2034.

Anthropic itself warned — in the same week they released Fable 5 — that AI systems may soon achieve recursive self-improvement: autonomously improving themselves without human intervention. They are simultaneously releasing the most powerful model ever made publicly available and warning that the pace of progress may be outrunning our ability to govern it. That tension is worth sitting with.

How to Actually Be Good in This Era

This is the part most articles don't write because it requires taking a real position.

Protect the 70% that AI cannot replicate.

System thinking. Threat modeling. Authorization design. Debugging under pressure when production fails. Judgment calls on architecture. Reading the code AI generates — every line, not on vibes. These are not automatable because they require context, stakes, and accountability that exist in your specific environment, not in the training data of any model.

Feynman distinguished between knowing the name of something and knowing the thing itself. Vibe coders know the name of what they want to build. The thinking — the actual understanding — is what they've offloaded. That's precisely where the vulnerabilities enter.

Use AI seriously for the 30% it's genuinely good at.

Boilerplate and scaffolding where patterns are well-defined and low-risk. Snippets for problems you already fully understand — if you don't understand the problem, AI-generated code for it is dangerous, not helpful. Reading unfamiliar codebases faster. Generating test cases that surface edge cases you might have missed. First drafts of documentation.

The precondition for all of this is comprehension first. The AI accelerates work you already understand. It does not replace the understanding.

Read the model outputs like an adversary would.

If you're a developer integrating any AI into production — Fable 5, GPT-5.5, anything — your threat model now includes prompt injection, indirect prompt injection via poisoned context sources, and agent privilege escalation. These are not theoretical. Agentic coding assistants have been shown to follow embedded instructions in poisoned README files — exfiltrating credentials while the developer watches what looks like normal code being written.

Thinking like a defender requires first thinking like an attacker. That combination — developer who builds systems, security researcher who breaks them — is the most defensible position in this market right now.

Don't mistake velocity for capability.

The engineers Amodei referenced — those who no longer write code — are editing AI output. Editing requires judgment. Judgment requires deep understanding of what you're editing and why. The moment that understanding atrophies, the editing becomes rubber-stamping. And rubber-stamped AI code at production scale is exactly what the breach statistics are capturing.

Marcus Aurelius: "Never esteem anything as of advantage to you that will make you break your word or lose your self-respect." The self-respect version for engineers in 2026 is: never call yourself a developer if you can no longer read and reason about the code you're shipping.

The Actual Summary

Claude Fable 5 is a genuine capability leap. The model landscape has never been more competitive or more capable. Amodei's warnings about software engineering disruption are serious and partially correct. The vibe coding security data is as bad as the skeptics predicted. AGI timelines are genuinely uncertain — plan for a wide band, not a specific year.

What this means for you: the developers who survive and matter in this era will be those who used AI as a force multiplier on deep understanding — not as a substitute for it. The ones who outsourced their thinking along with their typing will find themselves unable to debug, unable to secure, unable to reason about the systems they're responsible for.

Speed is available to everyone now. Understanding is not.

That asymmetry is your edge — if you protect it.

I write about API security, Django, and how developers can think more carefully about what they build. I don't post often, but when I do, it's because I have something I actually believe. Follow if that interests you.

Why Most Django Boilerplates Are Insecure by Default

siyadhkc — Wed, 03 Jun 2026 16:18:06 +0000

You found a Django boilerplate on GitHub. It has 2k stars, a clean README, Docker support, and a Makefile. You clone it, rename a few things, push to production.

Congratulations. You just shipped someone else's security assumptions.

The Illusion of "Production-Ready"

Every boilerplate claims to be production-ready. The badge is right there in the README. But production-ready for what? A side project? A fintech API? A platform that stores user PII?

"Production-ready" in most boilerplates means: it runs without errors. That's it. The security part is usually left as a comment that says # TODO: change this before deploy — which, statistically, nobody changes.

This isn't an attack on boilerplate authors. They're solving a real problem: Django's initial setup is tedious, and abstracting that away has genuine value. The problem is that the defaults they choose get inherited silently by every project that forks them.

And defaults are everything in security.

What Actually Ships in Most Boilerplates

Let me walk through what you'll typically find if you dig past the README.

1. `DEBUG = True` Tied to an Environment Variable That Defaults to True

# settings.py
DEBUG = os.environ.get("DEBUG", "True") == "True"

This is the canonical mistake. The intent is good — make DEBUG configurable. But the default is True. So if you deploy and forget to set the environment variable, Django will cheerfully expose your full stack trace, local variables, installed apps, and settings to anyone who hits a 404.

I've seen this in repos with thousands of stars. The author probably never intended it to ship this way. But it does.

The fix is trivial:

DEBUG = os.environ.get("DEBUG", "False") == "True"

One word. The default should always be the safe option.

2. `SECRET_KEY` Hardcoded or Weakly Generated

SECRET_KEY = "django-insecure-abc123xyz-changeme"

Django's startproject actually warns you with the django-insecure- prefix now. But plenty of boilerplates generated before that convention still have static keys checked into version control.

Even the ones that generate it dynamically sometimes do it wrong:

# generates a NEW key on every restart
SECRET_KEY = os.environ.get("SECRET_KEY", get_random_secret_key())

This means every server restart invalidates all existing sessions and CSRF tokens. That's not a security fix — that's a different bug wearing a security costume.

The secret key needs to be generated once, stored as an environment variable, and never committed to Git. Full stop.

3. `ALLOWED_HOSTS = ["*"]`

ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "*").split(",")

Again — the default is the dangerous value. ALLOWED_HOSTS = ["*"] disables Django's Host header validation entirely, opening the door for host header injection attacks. This isn't theoretical. Attackers use it to poison password reset emails with their own domain.

The boilerplate author probably put "*" there so you can docker-compose up without configuring anything. Convenience for the developer. Risk for the user.

4. CORS Configured Wide Open

# django-cors-headers
CORS_ALLOW_ALL_ORIGINS = True

CORS exists to protect your users' browsers. When you set this to True, you're telling every origin on the internet that it can make credentialed requests to your API. Combined with SESSION_COOKIE_SAMESITE = None (which some boilerplates also set), you've recreated the conditions for CSRF attacks in a Single Page App context.

The reasoning is always the same: "I'll change this when I know my frontend's domain." But that moment never comes cleanly in the chaos of early development, and it ships.

5. No Security Headers

Django doesn't set security headers by default. You need django.middleware.security.SecurityMiddleware in MIDDLEWARE, and then you need to actually configure it:

SECURE_BROWSER_XSS_FILTER = True  # deprecated but harmless
SECURE_CONTENT_TYPE_NOSNIFF = True
X_FRAME_OPTIONS = "DENY"
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_HSTS_PRELOAD = True
SECURE_SSL_REDIRECT = True

Most boilerplates have SecurityMiddleware in the list. Few have these settings configured. HSTS in particular is almost always missing — which means every user's first request is over HTTP until they get redirected.

6. Session and Cookie Settings Left at Defaults

# What most boilerplates ship
SESSION_COOKIE_HTTPONLY = True   # ✅ Django default, usually fine
SESSION_COOKIE_SECURE = False    # ❌ Default — cookies sent over HTTP
CSRF_COOKIE_SECURE = False       # ❌ Default — CSRF token sent over HTTP
SESSION_COOKIE_SAMESITE = "Lax"  # ✅ Usually fine, but often overridden

SESSION_COOKIE_SECURE = True means the browser will only send the session cookie over HTTPS. Leaving it False means someone on the same network can intercept it over HTTP. This is a solved problem — but it requires explicitly setting it, and boilerplates rarely do.

7. Django Admin Sitting on `/admin/`

urlpatterns = [
    path("admin/", admin.site.urls),
    ...
]

This is Django's own default, so I can't blame boilerplate authors entirely. But nobody changes it either. The admin panel at /admin/ is the first thing automated scanners probe. Moving it to something non-guessable costs you nothing and removes you from a significant percentage of automated attacks.

path("your-own-path-here/", admin.site.urls),

Why This Keeps Happening

The ecosystem isn't malicious. It's optimizing for the wrong metric.

Boilerplates get stars based on how quickly they get you from zero to running. Security settings that would break a local setup — like SECURE_SSL_REDIRECT = True without an SSL cert — get disabled so the DX is smooth. The secure version is the harder version to demo.

Django itself deserves some of this too. The framework ships with safe defaults in some areas (CSRF protection is on by default, passwords are hashed), but makes you opt-in to the rest. That opt-in surface is where boilerplates consistently fail to follow through.

And then there's us — developers who clone first, configure later, and ship before "later" arrives.

What a Secure Boilerplate Default Looks Like

Split your settings. This is non-negotiable.

settings/
    base.py      # shared across all environments
    local.py     # DEBUG=True, no SSL, relaxed CORS
    production.py  # strict everything

In production.py, the defaults should be secure. If something is missing — a SECRET_KEY, a DATABASE_URL — the app should refuse to start, not silently fall back to an insecure value.

# production.py
SECRET_KEY = os.environ["SECRET_KEY"]  # KeyError if missing — intentional
DEBUG = False
ALLOWED_HOSTS = os.environ["ALLOWED_HOSTS"].split(",")

SECURE_SSL_REDIRECT = True
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
CORS_ALLOWED_ORIGINS = os.environ["CORS_ALLOWED_ORIGINS"].split(",")

Notice the os.environ["KEY"] without .get(). If the variable isn't set, it raises a KeyError and the app doesn't start. That's correct behavior. Failing loudly in production is safer than running silently insecure.

A Checklist Before You Ship

If you're using any boilerplate — including one you wrote yourself six months ago — run through this before you deploy:

[ ] DEBUG = False in production, with no unsafe default fallback
[ ] SECRET_KEY sourced from environment, never in version control
[ ] ALLOWED_HOSTS explicitly set, no wildcards
[ ] CORS_ALLOW_ALL_ORIGINS = False, origins explicitly whitelisted
[ ] SESSION_COOKIE_SECURE = True
[ ] CSRF_COOKIE_SECURE = True
[ ] SECURE_SSL_REDIRECT = True
[ ] SECURE_HSTS_SECONDS set
[ ] Django admin URL is not /admin/
[ ] django.middleware.security.SecurityMiddleware is first in MIDDLEWARE

Run python manage.py check --deploy too. Django ships a deployment checker that will call out many of these issues. Most developers don't know it exists.

The Honest Takeaway

Boilerplates are a starting point, not a finished product. The problem is the word "boilerplate" implies it's something you don't need to think about — just add your code on top. But the security layer is exactly the part that requires thinking.

The ecosystem needs better defaults. Boilerplate authors should make the safe behavior the path of least resistance, not the other way around. Django could be more opinionated about production configuration. And we — as developers shipping things to real users — need to stop treating security settings as a post-launch concern.

It never becomes post-launch. It becomes a breach report.

If you found this useful, I write about Django security, API security, and backend architecture on Dev.to. The next piece will be on OWASP API Top 10 vulnerabilities in real Django REST Framework code — the ones that slip through code review.

I Built a Pre-Commit Secret Scanner Because GitHub's Is Too Late

siyadhkc — Sun, 24 May 2026 15:31:20 +0000

Let me start with a confession.

I have accidentally committed a .env file. Not to a private internal repo with no consequences. To a public GitHub repo. With a real Stripe test key in it.

I caught it within minutes, deleted the file, rotated the key, pushed a new commit. Classic developer scramble. Nothing happened — at least as far as I know.

But that "as far as I know" lived in my head for a while.

That experience is what eventually led me to build env-guard — a Python CLI tool that scans your project for secrets and installs as a git pre-commit hook, blocking the commit entirely if it finds something suspicious. The secret never leaves your machine. No scramble. No rotation. No anxiety.

The problem with GitHub Secret Scanning (it's a timing problem)

GitHub has a feature called Secret Scanning. It's legitimately good — it covers dozens of credential formats across major providers and will notify you when it finds something. I'm not here to trash it.

But it has one fundamental flaw that no amount of good engineering can fix:

It runs after you push.

Think about what that means. By the time GitHub scans your code and sends you an alert, your secret has already:

Left your machine
Traveled over the internet
Landed on GitHub's servers
Been indexed, if the repo is public

Automated bots scrape public GitHub repos constantly. We're talking seconds after a push, not minutes. GitHub will alert you, but the key is already out there. You're now rotating credentials, auditing API usage logs, and hoping whoever grabbed it hasn't done anything with it yet.

Without env-guard:
  code → commit → push → GitHub scans → alert → key already exposed ❌

With env-guard:
  code → commit blocked → fix locally → push clean code ✅

Think of GitHub Secret Scanning as your last line of defense. env-guard is your first.

The secret never enters git history at all. There's nothing to rotate, nothing to audit, and nothing to lose sleep over.

Who this is actually for

If you work with any of the following on a regular basis, env-guard is for you:

API keys — OpenAI, Stripe, Twilio, SendGrid, any SaaS you integrate with
Cloud credentials — AWS access keys, GCP service accounts, anything that costs money if misused
Database connection strings — postgres://, mongodb://, redis:// — all of these contain passwords
Private keys — RSA, EC, OpenSSH — the kind that give access to your servers

Basically: if you work on real software that talks to real services, you have secrets somewhere in your local environment. And humans make mistakes. Even careful ones.

I've seen this happen to senior engineers. It's not a skill issue. It's a missing safety net issue.

What it detects

env-guard ships with 54 detection rules covering every major category of credential you'd encounter in a typical backend or fullstack project:

Category	What it catches
AWS	Access Key ID, Secret Access Key, Session Token
Google	API Key, OAuth Client Secret, Service Account JSON
GitHub	Personal Access Token, OAuth Token, App Token
Stripe	Live and Test Secret Keys, Publishable Keys
OpenAI / Anthropic	API Keys
Slack	Bot Token, User Token, Webhook URL
Twilio	Account SID, Auth Token
SendGrid	API Key
Databases	PostgreSQL, MySQL, MongoDB, Redis connection strings
Private Keys	RSA, EC, PGP, OpenSSH private key blocks
Django	SECRET_KEY
Generic	Password assignments, token assignments, API key assignments
And more	Razorpay, NPM, PyPI, Heroku, Netlify, Cloudinary, and others

Each rule carries a severity level — HIGH, MEDIUM, or LOW — so you're not staring at an undifferentiated wall of warnings. A live Stripe secret key is HIGH. A generic-looking token assignment might be MEDIUM. The output is human-readable and actionable.

$ env-guard scan .

env-guard scan report
Path    : .
Scanned : 42 files
Found   : 1 potential secret(s)

  ✖ HIGH  Stripe Live Secret Key
  File : config/settings.py:12
  Code : STRIPE_KEY = "sk_live_abc123..."

──────────────────────────────────────────────────
  1 HIGH
──────────────────────────────────────────────────

Scan failed — secrets detected. Do not commit.

File. Line number. What was found. Severity. No ambiguity, no guesswork — you know exactly where to go and what to fix.

Getting started in 60 seconds

Install it:

pip install env-guard

Requires Python 3.8+. Run a scan on your current project right now:

env-guard scan .

Go ahead. Run it on a real project you're working on. You might be surprised what's sitting there.

The pre-commit hook — the part that actually changes your habits

Ad-hoc scanning is useful for audits, but the real shift happens when env-guard becomes invisible. When you don't have to think about running it. When it just works in the background every single time you commit.

That's what install-hook does:

env-guard install-hook

Run that once inside your repo. From that point forward, every git commit triggers an automatic scan before anything gets written to git history:

env-guard: scanning for secrets...
env-guard: commit blocked. Remove secrets before committing.
env-guard: to skip this check (NOT recommended): git commit --no-verify

If nothing is found, the commit proceeds normally — you won't even notice it ran. If something is found, the commit is hard-blocked with a clear message telling you exactly where the problem is.

The --no-verify escape hatch exists because I didn't want to be heavy-handed. Sometimes you're committing a test fixture that contains a fake-looking credential. The escape hatch is there — but it requires a conscious decision, and that friction is intentional.

To remove the hook if you ever need to:

env-guard uninstall-hook

Handling false positives

Every scanner has them. A SHA-256 hash that structurally resembles an API key. A documentation example with a placeholder that matches a pattern. A test fixture with a fake credential for unit tests.

env-guard handles this with a .envguardignore file in your project root — same concept as .gitignore, one pattern per line:

# Ignore specific files
tests/fixtures/sample.env

# Ignore by extension
*.log

# Ignore entire directories
docs/

Because it's a committed file, your whole team gets the same exclusions automatically. No per-developer configuration needed.

CLI flags for different workflows

A few flags that cover the common situations:

# Only surface the critical findings
env-guard scan . --severity HIGH

# Machine-readable output for scripting
env-guard scan . --format json

# Scan without failing the process (reporting mode)
env-guard scan . --no-fail

The --no-fail flag is worth calling out specifically. If you're adding env-guard to an existing large codebase, you probably don't want to immediately block everything and deal with 50 findings on day one. Run with --no-fail first, triage what's real vs. false positive, set up your .envguardignore, then remove the flag when you're confident. Gradual adoption is a completely valid path.

For teams: CI/CD as a second checkpoint

Pre-commit hooks protect your own machine. But what about:

External contributors who clone the repo and don't run install-hook
New team members who haven't set up their environment yet
Automated processes that generate config files with credentials

For that, env-guard works in CI pipelines too. Here's a GitHub Actions workflow you can drop into any repo:

name: Secret Scan

on: [push, pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      - run: pip install env-guard
      - run: env-guard scan .

This gives you the same local protection applied to every PR, from every contributor, on every push. env-guard locally + this workflow in CI = defense in depth that actually makes sense.

env-guard vs GitHub Secret Scanning — use both

	env-guard	GitHub Secret Scanning
When it runs	Before commit, on your machine	After push, on GitHub's servers
Blocks the secret	Yes — commit is blocked	No — secret is already pushed
Works offline	Yes	No
Custom ignore rules	Yes, `.envguardignore`	Limited
Free	Yes	Yes (public repos)
Requires GitHub	No	Yes

These aren't competing tools. They protect different parts of the pipeline. Run env-guard locally to stop secrets before they ever leave your machine. Keep GitHub Secret Scanning on as a fallback for anything that slips through — external contributors, edge cases, human error. Use both.

The thing I keep thinking about

There's a concept in security called "shift left" — the idea that you should catch problems as early in the development process as possible, because the earlier you catch something, the cheaper it is to fix and the less damage it causes.

A leaked credential caught before the commit? Zero cost. Rotate nothing. Tell no one. Move on.

A leaked credential caught after a push to a public repo? Rotate the key, audit usage logs, send an incident report if it's a team environment, and spend a few days with that low-grade anxiety of "did anything actually get accessed?"

env-guard is a shift-left tool. The entire design philosophy is: don't give the secret a chance to travel. Keep it local. Catch it at the source.

Try it

pip install env-guard
env-guard scan .

If you want the hook:

env-guard install-hook

Source on GitHub: github.com/siyadhkc/env-guard

If it catches something on the first scan — good. That's the point. And if you hit a false positive that's annoying, open an issue. I want the pattern library to be genuinely useful, not just technically comprehensive.

What's coming next

A few things on the roadmap:

Pre-push hook option — a second checkpoint right before the push, for teams who want both
More detection rules — 54 is solid but the ecosystem keeps growing
Project-level config file — custom severity thresholds, rule toggles, team-specific settings beyond just ignores

If this is useful to you, star the repo and watch for updates. And if you've ever had a bad day because of an exposed credential — you're not alone, and this is for you.

Built with Python. MIT licensed. Contributions welcome.

I built a multi-tenant food delivery platform alone. Here's what nobody tells you about that.

siyadhkc — Sun, 17 May 2026 16:40:10 +0000

Four user roles. One payment gateway that lied to me. Three rewrites of the same feature. And a GPS bug that nearly flooded my database. This is the real story behind Savor.

I was tired of building things that felt fake

At some point every developer hits a wall with tutorial projects. You've built the weather app. You've done the blog CRUD. You've cloned Twitter in a weekend. And none of it actually teaches you what it feels like when four different types of users are all touching the same data at the same time, and you have to keep their worlds completely separate.

I wanted something that would break me a little. Something with real business logic, real money, real state synchronization problems. Food delivery checked every single box.

Customers order food. Restaurants fulfill it. Delivery agents pick it up. Admins oversee everything. Four completely different actors, all interacting with overlapping data, all in real time. That's not a tutorial problem — that's a systems problem. I called it Savor.

"Building this was the first time I genuinely didn't know if something would work until I ran it. That was terrifying and that was the point."

These aren't exciting choices. They're correct ones.

Django REST Framework on the backend. React 19 + Vite on the frontend. PostgreSQL. I didn't pick these to be cool. I picked them because the problem needed a mature ORM, ACID-compliant transactions, and a frontend that wouldn't fight me on state management.

Layer	Tech	Why it mattered
Backend	Django 5.1 + DRF	Atomic transactions, battle-tested ORM, signals for cross-model side effects
Frontend	React 19 + Vite	Fast HMR, modern concurrent features
Auth	SimpleJWT + rotation	Silent 60-min access token rotation, 7-day refresh — no mid-session logouts
Database	PostgreSQL	ACID compliance. Nested financial data cannot partially save.
Payments	Razorpay	Localized processing, webhook verification
Media	Cloudinary CDN	Edge delivery. Serving images from Django would be career-ending performance-wise.
Styling	Tailwind CSS 4.0	Zero runtime. Design tokens kept four portals visually coherent.
Animations	Framer Motion	Micro-interactions. A premium feel isn't just design — it's movement.
Mapping	Leaflet.js	Live GPS plotting on the customer tracking view

The one decision I'd revisit: React Context API over Zustand. Context was fine for the scope but I started feeling prop drilling pain by week four. If you're building something this complex, just start with Zustand.

Each portal was its own distinct problem

The customer app was where I started because it's the most tangible — you can see it, click it, feel it. The discovery architecture has two layers: global cuisines (Arabian, South Indian, Desserts) and restaurant-internal categories (Must Try, Specials). Getting that hierarchy right in the serializers took four iterations. The cart was where I first hit real business logic — you can't add items from two different restaurants to the same cart. I built persistent local state that checks restaurant ID on every cart mutation. Sounds simple. It wasn't.

The restaurant partner portal was the one I underestimated the most. I assumed it'd be a dashboard with some CRUD. What I got was the most complex portal in the system. Restaurant owners are power users. The order lifecycle — Pending → Accept → Preparing → Ready for Delivery — cascades into downstream state changes across three other portals simultaneously. I used Django signals for this. Required very careful thinking about idempotency.

The delivery agent interface is the one I'm most proud of technically. Geo-fencing logic is implemented at the queryset manager level, not the view level. A Kochi agent cannot see a Mumbai dispatch — and this isn't a frontend filter someone can bypass with a crafted request. The data simply doesn't exist in the response. Getting the earnings calculation to be atomic and accurate on the Delivered status transition took three rewrites.

The admin console could have been an afterthought. I didn't let it be. With 3,000+ menu items seeded from the Kerala restaurant dataset, server-side pagination was non-negotiable. I implemented cursor-based pagination — offset pagination on PostgreSQL becomes unusably slow past 1,000 rows.

Live demo: food-delivery-seven-bice.vercel.app

The struggles nobody writes about in project writeups

01 — Multi-tenancy took three complete rewrites

The first version filtered at the serializer level. That works until a restaurant owner in tenant A briefly sees an order from tenant B during a race condition. The second version moved filters to the view layer — better, still bypassable. The third version put tenant scoping into the queryset manager. That's where it needed to be from the start. Two full days of debugging a bug that shouldn't have existed if I'd thought it through properly the first time.

02 — Razorpay webhook verification in development is a trap

Webhooks need a publicly accessible endpoint. In development, you don't have one. I spent a full day debugging a signature verification failure that turned out to be a timezone mismatch in how I was constructing the HMAC payload. I ended up building a local webhook simulator specifically for dev testing, stripped out before production. This is not in any Razorpay tutorial I found.

03 — GPS telemetry nearly destroyed my database

Early testing: delivery agents broadcast coordinates on every geolocation API event. The browser's watchPosition fires multiple times per second. At 10 concurrent test agents, that was hundreds of database writes per minute for a field that only needs to update every few seconds. I added a frontend debounce and a backend timestamp guard that rejects updates more frequent than 3 seconds. The database survived. My nerves less so.

04 — CSS across four portals with four different visual languages

The customer app is warm and premium. The delivery interface is utilitarian and fast. The admin console is dense and data-heavy. The partner portal is somewhere between all three. Tailwind's design token system helped, but by week three the tokens were drifting in ways that required a full audit to fix. CSS architecture is genuinely hard at scale and nobody talks about the multi-portal version of this problem.

05 — The cart constraint bug that appeared in production and nowhere else

Cart state was using localStorage with a restaurant ID key. In production, the Vercel edge occasionally delivered a cached app version mid-session with a stale cart key. The constraint check passed because the key comparison was against an old restaurant ID. Never reproduced locally. Fixed by adding a session-scoped cart version hash alongside the restaurant ID. The worst kind of bug: requires production traffic to surface.

The one decision that saved the whole system

Early on I had a choice: enforce multi-tenancy at the UI layer or the data layer. The UI layer is easier — you just filter what you show. The data layer is harder — you modify how querysets are constructed at the model level so filtered-out data is never even fetched.

I chose the data layer. Every restaurant-scoped query goes through a custom queryset manager that injects the tenant ID before the SQL hits PostgreSQL. Bypassing tenant isolation requires compromising the Django application layer itself — not just crafting a request with different parameters.

For financial data, I used @transaction.atomic everywhere that touched nested profile updates. A restaurant's payout configuration and platform commission rate update in a single atomic operation. Either both succeed or neither does. This is not optional when you're dealing with money.

"The architecture that survives isn't the one that looks cleanest in a diagram. It's the one that fails gracefully when things go wrong — and they will go wrong."

You only understand failure modes by creating them

You can read about multi-tenancy. You can read about JWT rotation. You can understand atomic transactions in the abstract. But there's a kind of understanding you only get from tracing a data leakage bug through four layers of abstraction at 11pm, finding the one queryset that forgot to filter by restaurant_id, and sitting with the fact that your first two architectural decisions were wrong.

Building Savor taught me that system design isn't about choosing the right technologies. It's about understanding the failure modes of every interface between them. The Razorpay integration fails if my webhook handler is slow. GPS tracking floods my database if the frontend isn't debounced. Multi-tenant isolation breaks if I filter at the wrong layer. None of these are things you learn by reading. You learn them by breaking them, badly, and having to fix it.

If you're in the middle of a solo project right now and it feels like the complexity is winning — it probably is, temporarily. That's what week three feels like. The tangle is the work. Push through it.

Live demo: food-delivery-seven-bice.vercel.app

Backend API: food-delivery-backend-c4pe.onrender.com/api

Github: food-delivery-github

Postman collection at backend/postman.json — all auth rotation, order status, and multi-tenant profile endpoints pre-configured.

I built a JSON CLI tool with Bun and TypeScript — here's what actually happened

siyadhkc — Mon, 11 May 2026 01:31:57 +0000

I wanted a tool that could flatten JSON, filter it, colorize output, and fetch from a URL — all from
the terminal. Something between jq and gron but with a cleaner, more intuitive API. So I built
jray. This is the honest post-mortem of how it went.

GitHub: github.com/siyadhkc/jray
Website:siyadhkc.github.io/Jray

Why I built it

Every time I'm debugging an API response or poking around some nested config file, I reach for jq.
And every time, I spend the first five minutes googling the syntax again. jq is powerful — genuinely
— but it's its own language, and unless you're writing complex transformations daily, that overhead
adds up.

gron is the other tool I kept coming back to. It flattens JSON into greppable dot-notation, which
is exactly what you want when you're trying to find where a deeply nested key lives. But gron is
read-only. You can't filter and get structured output back. You can't fetch from a URL. The color
situation is nonexistent.

So I scoped out what I actually needed:

Flatten JSON to dot-notation paths (a.b.c = value) so I can see structure at a glance
Filter by key pattern without learning a query language
Fetch directly from a URL so I don't have to curl | jray every time
Color output by default on TTY
Fast enough that it doesn't feel like overhead when I'm in the middle of something

Bun was the obvious runtime choice. Fast cold start, native TypeScript support, a built-in test
runner, and bun build --compile that bundles everything into a single self-contained binary. No
Node.js version headaches, no separate install step for the runtime.

How it's structured

I kept the architecture intentionally flat. No frameworks, minimal dependencies. The core logic is
split into focused modules:

flatten.ts — recursive flatten and unflatten. Takes a nested object and produces a map of dot-notation paths to primitive values. Unflatten goes the other direction.
filter.ts — glob-style pattern matching on the flattened keys. user.* gives you everything under user, **.id matches any id at any depth.
color.ts — ANSI color output. Keys in one color, values type-aware (strings, numbers, booleans each get their own).
fetch.ts — thin wrapper around Bun.fetch that handles the request, checks content type, and pipes the response into the flatten pipeline.
cli.ts — argument parsing and wiring. Reads from stdin, a file path, or a URL depending on what flags you pass.

The whole thing compiles down to a single binary:

bun build ./src/cli.ts --compile --outfile jray

No runtime dependency on Bun after that. You ship the binary, it works.

The problems I actually ran into

npm name conflict

First thing I did after writing the initial working version was try to publish as jray. Already
taken — and not squatted. An actual published package with actual users. So I had to switch to a
scoped package: @siyadkc/jray.

That sounds like a small change but it cascades. The README, the install command in all the
examples, the binary name in package.json, the GitHub Actions publish step, the Dev.to article
draft I'd already half-written — all of it needed updating. It also changes how users install it
slightly, since scoped packages require the @ prefix. Not a dealbreaker, but check npm before you
name your CLI.

Package size bloat

My first publish was heavier than it needed to be. Bun's compiled binary includes the runtime,
which is expected and fine. But the npm package itself had no files field, so it was packaging
everything — source maps, test files, the node_modules from dev, local configs. None of that
belongs in a published package.

Fix was straightforward:

"files": ["dist/", "README.md"]

That single field cut the published package weight significantly. Always define files. The npm
registry doesn't know what's dev and what's production unless you tell it.

Windows compatibility

I had a postinstall script that ran chmod +x on the binary. Works perfectly on Linux and macOS.
On Windows it throws and the install fails. I wrapped it in a try-catch and updated the docs to note
that Windows users should either run the binary path directly or use WSL. Not the cleanest solution,
but honest about the platform situation. Full Windows support is on the roadmap.

GitHub Actions for CI and publishing

The pipeline itself wasn't complicated — install Bun, run tests, publish to npm on a version tag.
But there's one specific thing that tripped me up: not using --frozen-lockfile in CI.

Without it, bun install in CI can silently update the lockfile, which means your CI might be
testing against different dependency versions than what you developed against. Always use:

- uses: oven-sh/setup-bun@v1
  with:
    bun-version: latest
- run: bun install --frozen-lockfile
- run: bun test

Publishing to npm from Actions requires setting NPM_TOKEN as a repository secret and passing it
through to the publish step. Once that's wired, releases are a tag push away.

What it actually does

# Install
bun add -g @siyadkc/jray

# Flatten JSON from stdin
echo '{"user":{"name":"Eliot","age":24}}' | jray
# user.name = "Eliot"
# user.age = 24

# Flatten a local file
jray data.json

# Filter by key pattern
jray --filter "user.*" data.json
# user.name = "Eliot"
# user.age = 24

# Fetch from a URL and flatten
jray --fetch https://api.example.com/users/1

# Disable color (for piping into other tools)
jray --no-color data.json

The filter uses glob-style matching against the full dot-path of each key. So user.* matches one
level under user, while **.id would match any id at any depth in the document. It's
intentionally simpler than jq's filter syntax — the goal is something you can remember without
looking it up.

Where it sits vs the competition

gron is the closest thing and the most direct comparison. It also flattens to dot-notation and
it's what made me realize there was a gap to fill. But gron has no color output, no URL fetching,
and no NDJSON streaming support. jray has all three.

jq is in a different category. It's a transformation tool — you write expressions, you reshape
data, you do complex operations. jray is an inspection tool. You throw data at it and you
understand the structure immediately. They're complementary more than they're competing.

fx is another one that comes up. Interactive, powerful, but it's a TUI. If you're in a script or
piping between tools, you don't want a TUI. jray is designed to be pipeline-friendly from the
start.

The longer-term vision is broader than just JSON. Supporting YAML and TOML with the same flatten
and filter interface makes it a universal structured-data CLI. There's also TOON (Token Oriented
Object Notation), which is an emerging format that's genuinely useful for LLM developer workflows
since it's optimized for tokenization. That's a real differentiator if the format gets traction.

The launch

Published to npm, wrote this article, posted on X . Also shared in the Bun
Discord since the community there is small enough that people actually read it.

The GitHub Pages site is live. It's getting redesigned right now — moving toward a flatter, more
minimal aesthetic with an interactive playground section where you can paste JSON directly in the
browser and see the flatten and filter output in real time. No install required to try it. That
single feature will probably do more for adoption than any amount of posting.

What I'd do differently

I'd define the files field before the first publish, not after. I'd also check npm for name
conflicts before I was emotionally attached to the name. And I'd set up the CI pipeline before
the first push to main so I wasn't debugging GitHub Actions at the same time I was trying to
ship.

The architecture decisions held up fine. Bun was the right call. The modular structure meant I
could add fetch.ts and color.ts without touching the core flatten logic. That's about as much
as you can ask from a first project's structure.

Try it

bun add -g @siyadkc/jray

GitHub: github.com/siyadhkc/jray

If you're working on something similar with Bun, or you have opinions on the filter API design,
drop a comment. Always curious how other people are solving the same problems.

This is my first article writing on this platform so if i made any narration mistake or anything feel free to tell me, i will improve my writing skill and the way of telling this
-- let's get connected --

From Hardware to Hacking: How Understanding Systems Changed My Approach to Security

siyadhkc — Wed, 15 Apr 2026 15:56:13 +0000

Introduction

I didn’t start my journey in cybersecurity. I started with hardware and networking, learning how systems actually function at a low level — how machines communicate, how configurations impact behavior, and how failures happen.

The Shift to Development

Later, I moved into development, working with Python and full-stack technologies. Building applications helped me understand how software is structured, but it also revealed something important:

Most applications are not built with security as a priority.

The Turning Point

This realization pushed me toward cybersecurity, specifically:

Web application security
API security
Cloud platforms (AWS, Azure, GCP)

Instead of just building systems, I began analyzing how they can be exploited.

A Different Way of Thinking

The biggest shift was in mindset:

From:
“How do I build this system?”

To:
“How can this system fail or be attacked?”

This dual perspective — builder and attacker — is critical in modern cybersecurity.

What’s Next

I’ll be sharing:

Practical security insights
Real-world learning experiences
Breakdowns of vulnerabilities and misconfigurations

If you’re interested in understanding systems deeply — not just building them, but also testing their limits — follow along.

I built a modern alternative to gron using Bun and TypeScript

siyadhkc — Sun, 12 Apr 2026 17:16:36 +0000

The problem

Working with JSON in the terminal is painful. jq is powerful
but requires learning a whole query language. grep works but
matches values too — not just paths.

For example if I search for "name" in my JSON:

grep matches json.user.name ✅ (correct)
grep also matches json.bio = "my name is Alice" ❌ (wrong)

So I built jray.

What jray does

jray flattens any JSON into one line per value:

$ jray data.json
json.organization.name = "Acme Corporation"
json.users[0].name = "Alice Pemberton"
json.users[0].role = "admin"
json.users[0].active = true
json.billing.plan = "enterprise"

Now you can grep it, awk it, pipe it — using tools you already know.

Four commands that cover everything

# Flatten with color output
jray data.json

# Fetch a URL directly — no curl needed
jray https://jsonplaceholder.typicode.com/users/1

# Filter by path only (never matches values)
jray data.json --filter "billing"

# Extract any subtree as clean JSON
jray data.json --select "billing"

# Print just the values
jray data.json --values

# Reconstruct original JSON
jray data.json | jray --ungron

The comparison with existing tools

Feature	jray	jq	gron
Flatten to lines	✅	❌	✅
Reconstruct JSON	✅	❌	✅
Filter by path	✅	✅	❌
Extract subtree	✅	✅	❌
Fetch from URLs	✅	❌	✅
Color output	✅	✅	✅
No query language	✅	❌	✅
TypeScript / modern	✅	❌	❌

What I learned building it

This was my first open source CLI tool. Key lessons:

1. Separate your CLI from your logic
cli.ts handles only I/O — reading files, printing output.
flatten.ts, filter.ts etc. know nothing about terminals.
This makes everything testable in isolation.

2. Use unknown not any in TypeScript
JSON is dynamic but that doesn't mean any. Using unknown
forces you to check types before using values — much safer.

3. Recursive functions are perfect for JSON
JSON is a tree. Walking a tree with recursion is the
cleanest pattern — each call handles one node and
delegates children back to itself.

4. Bun is genuinely fast and simple
Native TypeScript, built-in fetch, fast startup.
For a CLI tool, Bun is a great choice.

5. The README matters as much as the code
Nobody uses a tool they can't understand in 30 seconds.
Writing clear examples with real output is as important
as writing the code itself.

Install and try it

npm install -g @siyadkc/jray

Then:

jray https://jsonplaceholder.typicode.com/users/1

GitHub: github.com/siyadhkc/Jray

for more info Website: https://siyadhkc.github.io/Jray/

This is my first open source tool. Feedback on the code
quality is very welcome — especially from experienced
TypeScript developers!

DEV Community: siyadhkc

I Built My Own AI Research Assistant for Cybersecurity — Here's the Honest Breakdown

First: What "Building Your Own AI" Actually Means

How LLMs Actually Work (The Part Nobody Explains Clearly)

Why Local? The OPSEC Argument

The Tool: Ollama

Installation & Setup

What's happening under the hood:

Handy Ollama CLI Commands

Picking the Right Model for Your Hardware

The 2026 Open Model Landscape

The Problem With Raw Models: They Don't Know Your Stuff

RAG: Teaching Your AI Your Own Knowledge

A Practical Local RAG Implementation in Python

RAG vs. Fine-Tuning: The Classic Misconception

The Next Evolution: MCP (Model Context Protocol)

The Security Risks Inside Your Own Local Tools

Honest Downsides of Going Local

Why This Matters Beyond Just Privacy

Let's Connect!

AI Just Got Scarier and More Powerful — And Nobody Is Talking About the Right Things

First: What Just Dropped Yesterday

What Else Is in the Field Right Now

The Statement That Broke the Developer Internet

The Vibe Coding Data Is In — It's Bad

Where AI Is Actually Going — The Honest Version

How to Actually Be Good in This Era

The Actual Summary

Why Most Django Boilerplates Are Insecure by Default

The Illusion of "Production-Ready"

What Actually Ships in Most Boilerplates

1. DEBUG = True Tied to an Environment Variable That Defaults to True

2. SECRET_KEY Hardcoded or Weakly Generated

3. ALLOWED_HOSTS = ["*"]

4. CORS Configured Wide Open

5. No Security Headers

6. Session and Cookie Settings Left at Defaults

7. Django Admin Sitting on /admin/

Why This Keeps Happening

What a Secure Boilerplate Default Looks Like

A Checklist Before You Ship

The Honest Takeaway

I Built a Pre-Commit Secret Scanner Because GitHub's Is Too Late

The problem with GitHub Secret Scanning (it's a timing problem)

Who this is actually for

What it detects

Getting started in 60 seconds

The pre-commit hook — the part that actually changes your habits

Handling false positives

CLI flags for different workflows

For teams: CI/CD as a second checkpoint

env-guard vs GitHub Secret Scanning — use both

The thing I keep thinking about

Try it

What's coming next

I built a multi-tenant food delivery platform alone. Here's what nobody tells you about that.

I was tired of building things that felt fake

These aren't exciting choices. They're correct ones.

Each portal was its own distinct problem

The struggles nobody writes about in project writeups

The one decision that saved the whole system

You only understand failure modes by creating them

I built a JSON CLI tool with Bun and TypeScript — here's what actually happened

Why I built it

How it's structured

The problems I actually ran into

npm name conflict

Package size bloat

Windows compatibility

GitHub Actions for CI and publishing

What it actually does

Where it sits vs the competition

The launch

What I'd do differently

Try it

From Hardware to Hacking: How Understanding Systems Changed My Approach to Security

Introduction

The Shift to Development

The Turning Point

A Different Way of Thinking

1. `DEBUG = True` Tied to an Environment Variable That Defaults to True

2. `SECRET_KEY` Hardcoded or Weakly Generated

3. `ALLOWED_HOSTS = ["*"]`

7. Django Admin Sitting on `/admin/`