DEV Community: Akash Jha

QuietSOC 🔐 — Stop Drowning in Logs. Start With the Evidence.

Akash Jha — Mon, 26 Oct 2026 04:43:25 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

QuietSOC is a concept for a local-first AI assistant designed to make security log investigation less tedious for junior Security Operations Center (SOC) analysts.

Security analysts regularly deal with large volumes of authentication events, failed login attempts, unusual access patterns, and other security signals. Reviewing these events manually takes time that could be spent investigating the incidents that matter most.

QuietSOC aims to simplify the first stage of that workflow.

The proposed application would let an analyst upload a Windows authentication log or normalized CSV file and receive an investigation brief containing:

Suspicious activity: Rule-based identification of repeated failed logins and potentially suspicious authentication sequences.
An understandable explanation: AI-generated summaries that explain what the events might mean in plain language.
Traceable evidence: Relevant event IDs, timestamps, and supporting log entries.
Recommended next steps: Practical suggestions for further investigation.
A shareable report: A concise Markdown incident brief for documentation and handoffs.

The core idea is simple: analysts should not have to read every line of a log file before understanding where to start.

QuietSOC is currently a proposed project design, not a completed or tested application. The features above describe the intended functionality rather than verified capabilities.

Demo

A working demo is not available yet. The concept is to demonstrate a suspicious authentication sequence being uploaded, analyzed, and transformed into an evidence-backed incident briefing.

The planned demo would show the original events, the detection results, the AI explanation, and the final report in one workflow.

Code

The implementation has not yet been created, so there is no project repository to share at this stage.

The planned architecture uses Python, FastAPI, HTML, CSS, JavaScript, and local inference through Ollama.

How I Would Build It

The design separates security detection from AI-generated explanations.

1. Parse the logs

Python would normalize supported log formats into structured events containing timestamps, event identifiers, usernames, source addresses, and authentication outcomes where available.

2. Detect suspicious patterns

Deterministic Python rules would identify patterns such as repeated authentication failures and a successful login following a sequence of failures. These would be investigation signals, not automatic proof of an attack.

3. Explain the evidence with local AI

An open-weight model would receive a carefully selected set of relevant events and produce a structured explanation. Its output would need to reference the available evidence and acknowledge uncertainty rather than invent missing facts.

4. Present an investigation brief

A FastAPI backend and lightweight web interface would display the findings, event timeline, supporting evidence, severity assessment, and recommended next steps.

The proposed model is Gemma 3 running locally through Ollama. It has not yet been integrated or tested in this project.

Why Does Open Innovation Matter?

Security logs can contain sensitive operational information, usernames, internal addresses, and details about an organization's infrastructure. Sending such data to an external AI service may create privacy, compliance, or confidentiality concerns.

Open-weight models and local inference offer an alternative: organizations can explore AI-assisted workflows while retaining greater control over where their data is processed.

Open innovation also makes it possible for developers to inspect the surrounding implementation, adapt detection rules, evaluate model behavior, and build on publicly available tools rather than relying entirely on a proprietary service.

For a project like QuietSOC, transparency is particularly important. An AI-generated explanation should never replace the original evidence or become the sole basis for a security decision.

The long-term vision is an approachable, extensible assistant that helps junior analysts learn from their investigations while keeping the human analyst in control.

My Agent Session

No DevRelay agent session is available for this concept.

The Lazy Payoff

The intended benefit is to reduce the repetitive effort involved in manually reviewing authentication events, assembling a timeline, and writing an initial incident summary.

However, no time-saving measurements or user tests are available because the application has not been implemented.

A future evaluation would compare the time required to investigate the same synthetic log dataset manually versus with QuietSOC, while checking whether the generated findings remain accurate and traceable.

Prize Categories

No partner-category entry is being claimed at this stage. The proposed use of Gemma would need to be implemented and demonstrated before a Best Use of Gemma entry could be substantiated.

Final thought

QuietSOC began with a practical question: what if a junior SOC analyst could spend less time searching through repetitive logs and more time understanding the evidence?

The idea is to use open AI as an assistant to the investigation—not as a replacement for detection logic, evidence, or human judgment.

The next step is to turn this concept into a working, testable tool.

ScamShield: I Built a Local AI Scam Detector for Freelancers

Akash Jha — Mon, 19 Oct 2026 03:21:34 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

ScamShield: I Built a Local AI Scam Detector for Freelancers

Freelancing offers flexibility, but finding legitimate clients isn't always easy.

A job offer might look professional while asking for an upfront registration fee. A client might request an unusual payment transfer. Sometimes, the warning signs are subtle enough that a new freelancer doesn't know what to look for.

I wanted to build something practical to help freelancers pause, identify warning signs, and make more informed decisions before accepting an offer.

That's why I built ScamShield, a local AI-assisted freelance scam screening tool.

What I built

ScamShield lets users paste a freelance job offer, client message, or payment request and receive a structured analysis.

The current MVP includes:

Risk classification: LOW, MEDIUM, HIGH, or CRITICAL.
Risk scoring: A score from 0 to 100 based on detected warning signs.
Evidence-based findings: Matched text excerpts, rule identifiers, severity levels, and explanations.
AI explanations: Additional context generated by a locally running Qwen3 model.
Missing information: Details that the message doesn't establish, such as contract terms or independently verifiable company information.
Recommended next steps: Practical suggestions based on the detected indicators.
A web interface: A responsive frontend with example messages, character counting, and a structured analysis report.

The goal isn't to declare every suspicious message fraudulent. It's to help users understand what deserves closer inspection.

How it works

The most important architectural decision was to keep risk assessment separate from AI-generated explanations.

Here's the basic flow:

A user submits a message through the web interface.
The FastAPI backend validates the input.
A deterministic Python rules engine searches for known warning signs.
The engine calculates the risk score and classification.
If findings exist, the optional local AI component explains those existing findings.
The frontend displays the evidence, score, recommendations, and AI explanation.

The AI model does not determine the risk score, invent verified findings, or change the original severity ratings.

This separation makes the output easier to inspect and test.

Why open-source AI matters here

ScamShield uses Qwen3 4B through Ollama, allowing the explanation model to run locally instead of depending on a hosted AI API.

That matters for a tool that handles potentially sensitive client messages and job offers.

A local-first approach offers several advantages:

Privacy: Message content can remain on the user's machine during local analysis.
Control: The model can be replaced or reconfigured without redesigning the entire application.
Accessibility: Users can experiment without requiring a paid hosted-model API.
Transparency: Deterministic rules remain responsible for risk scoring, while AI provides supplementary explanations.

Local inference still requires suitable hardware and the model must be downloaded first. Running locally does not automatically make every component secure, but it gives users more control over where their data is processed.

Technology stack

Backend: Python, FastAPI, Pydantic
Frontend: HTML, CSS, JavaScript
AI inference: Ollama with Qwen3 4B
Testing: pytest, FastAPI TestClient, mocked AI responses
Development environment: Local Windows environment

Testing and reliability

I implemented automated tests for the rule-based analyzer, API endpoints, and Ollama client.

The latest full test run completed with 29 tests passing.

The tests cover input validation, risk classification, finding validation, malformed model responses, timeouts, HTTP errors, and preservation of the original findings. API tests also cover successful AI explanations, fallback behavior when Ollama fails, and skipping AI calls when no findings exist.

These tests verify expected application behavior; they are not proof that the tool can detect every type of scam.

Who could use it?

ScamShield is designed for freelancers, students looking for their first remote opportunity, and independent contractors who regularly receive unfamiliar job offers.

A future version could include configurable detection rules, additional message patterns, and more comprehensive evaluation against a curated collection of legitimate and suspicious offers.

For now, it is an MVP demonstrating how deterministic security checks and local AI explanations can work together.

Try the project

GitHub repository:
akashjha518 / ScamShield
ScamShield 🛡️

Protect Your Freelance Journey. Spot Scams Before They Strike.

ScamShield is an open-source, AI-assisted screening tool that helps freelancers assess suspicious job offers, client messages, and payment requests before responding. It looks for warning signs, shows the evidence behind its assessment, and suggests practical next steps.

Important: ScamShield is a decision-support tool, not a guarantee that a message is safe or fraudulent. Always verify clients and companies independently.

Contents
Why ScamShield?

Freelancers and people starting their careers can encounter fake job offers, upfront registration fees, suspicious payment requests, impersonation, and pressure to share sensitive information. These messages can be difficult to evaluate, especially for people who are new to freelance work.

ScamShield makes the assessment more understandable by surfacing…
View on GitHub

To run the project locally, install the Python dependencies, start the FastAPI backend, and serve the frontend. For AI explanations, install Ollama, download the configured Qwen3 model, and make sure the local Ollama service is running.

The project is still under development. Its findings depend on the available detection rules, and a low score does not establish that an offer is safe.

What I learned

Building ScamShield taught me that adding an AI model isn't the same as building a reliable AI-assisted application.

The surrounding system matters: input validation, structured outputs, error handling, tests, and clear limitations all influence whether users can trust what they see.

My biggest takeaway is that AI should help explain security evidence, not replace the logic responsible for establishing it.

That is the principle I want to continue following as ScamShield grows.

Conclusion

ScamShield is my attempt to turn a real problem faced by freelancers into a practical, locally runnable cybersecurity tool.

By combining deterministic detection with open-weight AI, it aims to make suspicious freelance offers easier to understand without requiring users to send their messages to a hosted AI service.

This is an early version, not a definitive scam detector. But it's a working foundation that I can test, improve, and develop further.

Thanks for reading!

🌿 CyberEscape: What If Your Next Cybersecurity Lab Was a Walk Outside?

Akash Jha — Mon, 12 Oct 2026 05:10:04 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

CyberEscape 🌿🔐 — Walk. Observe. Think like a defender.

What if learning cybersecurity didn't always mean sitting in front of a screen?

As someone learning and building in cybersecurity, I spend a lot of time working with virtual machines, terminals, networking tools, and security labs. These are essential for developing technical skills, but I wanted to explore another way of learning security concepts—one that connects everyday experiences with defensive thinking.

That's the idea behind CyberEscape, an AI-powered outdoor cybersecurity learning experience built for the Hacktoberfest 2026 Touch Grass challenge.

CyberEscape turns an ordinary walk into a safe, interactive cybersecurity mission. Instead of spending the entire experience looking at a screen, users receive a mission, put their phones away, observe their surroundings respectfully, and return to reflect on what they learned.

Here's how it works:

Choose a mission: Select a duration, difficulty level, and cybersecurity topic.
Generate with AI: Local AI creates an educational outdoor observation mission based on the selected preferences.
Step outside: Read the instructions, put the phone away, and observe your surroundings without interacting with people or testing real security controls.
Reflect: Return to the application and explain the cybersecurity principle, its potential impact, and a possible defensive improvement.
Learn and progress: AI analyzes the reflection and provides educational feedback and defensive recommendations. Successful reflections earn 10 XP, while mission progress and history are stored in browser localStorage.

CyberEscape currently covers five topics:

🔐 Physical Security
🕵️ Privacy & Exposure
🎭 Social Engineering
🛡️ Defensive Thinking
🌐 Network Security Awareness

The idea isn't to replace hands-on cybersecurity labs. It's to complement them with a different kind of learning experience.

A traditional lab asks you to investigate a technical environment. CyberEscape encourages you to connect security principles with everyday situations, think about why they matter, and consider how a defender could reduce potential risks.

The screen starts the mission. The real world provides the observation. Reflection turns it into a learning experience.

Demo

The best way to understand CyberEscape is to see its actual workflow.

Application screenshots

The CyberEscape interface and mission progress.

Configuring a mission and receiving AI-generated instructions.

Submitting a reflection and reviewing AI-generated feedback.

🎬 Video demonstration:

The demo should show the actual application in action: selecting a mission, generating instructions, submitting a reflection, receiving feedback, and viewing the resulting progress.

These screenshots and the recording should come from the working MVP rather than mockups.

Code

🔗 GitHub repository: https://github.com/akashjha518/CyberScape

The repository contains the CyberEscape implementation and project documentation.

The project is built around a simple idea: combine an accessible web interface with local AI to create a learning experience that encourages people to spend less time looking at their screens.

How I Built It

CyberEscape is a full-stack application built with React, Python, FastAPI, and a locally running open-weight AI model.

Technology stack

Technology	Role in CyberEscape
React	Builds the interactive user interface
Vite	Frontend development and build tooling
CSS	Application styling
Python	Backend implementation
FastAPI	API layer connecting the frontend to the application workflow
Pydantic	Validation of structured API data
Ollama	Runs the AI model locally
Gemma 3 4B (`gemma3:4b`)	Generates missions and analyzes reflections
Browser localStorage	Stores mission history and progress

1. Mission generation

The learner selects the duration, difficulty, and cybersecurity topic. The frontend sends the relevant configuration through the backend workflow, where the local AI model generates an educational mission.

This is where AI makes the experience more adaptable than a fixed collection of lessons. Mission content can be generated according to the learner's selected preferences rather than requiring every learner to follow identical instructions.

2. Reflection and AI feedback

After completing the outdoor observation activity, the learner returns and submits a reflection.

The AI analyzes the explanation and provides feedback and defensive recommendations. This encourages the learner to move beyond simply noticing something and consider the underlying security principle, its potential impact, and possible mitigation.

The model provides educational guidance; its output should not be treated as a guarantee of security correctness.

3. Local AI with Ollama and Gemma 3 4B

CyberEscape uses Gemma 3 4B through Ollama for mission generation and reflection analysis.

I chose a local inference approach because it fits the project's educational and privacy-conscious goals. The application can run these AI interactions on the user's machine when the required model and runtime are installed and configured.

This also gives the project a practical way to experiment with open-weight AI without depending exclusively on a hosted commercial AI API.

4. Progress tracking

The application stores mission history and progress in browser localStorage. Successful reflections earn 10 XP, giving learners a lightweight way to track their progress without requiring a separate account system in this MVP.

The result is a connected learning loop: configure, generate, observe, reflect, receive feedback, and track progress.

Why Does Open Innovation Matter?

For CyberEscape, open innovation matters because it gives me greater flexibility in how the AI component is run, explored, and integrated into the learning experience.

Local inference and user control

Ollama and Gemma 3 4B allow the AI model to run locally on a user's machine, subject to hardware and setup requirements.

This is particularly relevant for an application that processes written reflections. In the intended local setup, mission and reflection processing can take place without sending that content to a hosted commercial AI inference API.

Local inference alone does not guarantee complete application privacy or offline operation. Other network requests and data-storage behavior still matter, and browser localStorage is not encrypted storage.

Experimentation with open-weight AI

Using an open-weight model makes it possible to investigate the AI workflow more directly, experiment with prompts, evaluate model behavior, and explore alternatives without building the entire experience around a single hosted model endpoint.

It also makes the AI component a useful learning opportunity in its own right. Developers can examine how the model fits into the application and understand how AI-generated content is incorporated into a practical workflow.

Why Gemma?

Gemma 3 4B is central to CyberEscape's two AI-powered activities: creating outdoor missions and analyzing learner reflections.

The model is not included merely to add an AI label to the project. Its role is to help personalize the mission experience and provide feedback after the learner returns.

Open-weight AI made this implementation approach possible while keeping local inference at the center of the design.

Safety by design

CyberEscape is an educational awareness tool, not a security-audit application.

Its missions do not ask learners to trespass, test real access controls, interact with strangers, collect personal information, photograph people, or scan and investigate real networks.

The outdoor activity is intended to involve respectful observation and defensive reasoning. Learners put their phones away during the mission and return to the application for reflection.

I wanted the experience to encourage security awareness without turning public spaces or other people into targets for experimentation.

My Agent Session

The official challenge template makes this section optional.

[Add your DevRelay agent session link here if you have a relevant session to share.]

If no suitable session has been saved, this section can be removed before publication. I don't want to present an unavailable session or invent an agent workflow that wasn't documented.

Prize Categories

Best Use of Gemma

CyberEscape uses Gemma 3 4B through Ollama for its AI-powered mission-generation and reflection-analysis workflows.

This category is relevant because Gemma is part of the actual implementation rather than a technology mentioned only in the project description.

Final Thoughts

CyberEscape started with a simple question: can cybersecurity learning encourage people to step away from their screens without losing the practical thinking that makes security education valuable?

My answer was to build a small, working MVP that combines AI-generated missions, outdoor observation, reflection, feedback, and progress tracking.

It doesn't replace technical labs, SIEM investigations, packet analysis, or hands-on defensive security practice. Instead, it explores another way to develop awareness and connect security principles with everyday experiences.

Building this project also reminded me that AI is most useful when it serves a clear purpose. In CyberEscape, AI generates the learning activity and helps interpret the reflection, while the learner remains responsible for observing, thinking, and explaining.

For me, that's the most interesting part of the project: technology helps create an experience that deliberately asks the user to put technology aside for a while.

CyberEscape 🌿🔐 — Walk. Observe. Think like a defender.

🔗 Explore the project: CyberEscape on GitHub

I'd love to hear how other developers are using open-source AI to make learning more practical, engaging, and connected to the world outside the screen.

I Built CyberBuddy: A Local AI Cybersecurity Assistant for Non-Technical Users

Akash Jha — Mon, 05 Oct 2026 06:14:42 +0000

Have you ever received a message saying:

"URGENT! Your bank account will be blocked. Verify your account immediately."

Or clicked a link and wondered:

"Is this website actually safe?"

For someone with a cybersecurity background, these messages can contain obvious warning signs. But for a non-technical person, understanding those warning signs isn't always easy.
That's the problem I wanted to solve with CyberBuddy.
CyberBuddy is a local AI-powered cybersecurity assistant that helps non-technical users understand suspicious messages and URLs and decide what they should do next.
This project was built for the Hacktoberfest Weekend Challenge: Build for a Friend.

The Problem

Cybersecurity advice is often written for technical users.
Terms like:

phishing
credential harvesting
suspicious indicators
malicious URLs
account takeover
social engineering

can be confusing to someone who doesn't work in cybersecurity.

A person receiving a suspicious message doesn't necessarily need a complicated security report.
They need answers to simple questions:

Is this suspicious?
Why does it look suspicious?
What should I avoid doing?
What should I do next?

That's where CyberBuddy comes in.

Meet CyberBuddy

CyberBuddy is designed around a simple idea:
Give people understandable security guidance without requiring them to understand cybersecurity terminology.

The current MVP supports two types of analysis:

1. Suspicious Message Analyzer

A user can paste a suspicious email or message.
For example:

URGENT! Your bank account will be blocked.
Please provide your OTP immediately at
https://example.com/login

CyberBuddy analyzes the message and identifies indicators such as:

urgent or pressure-based language
credential requests
financial information requests
account access threats
URLs

It then calculates a risk level and score.

2. Suspicious URL Analyzer

Users can also enter a URL directly.
For example:

http://192.168.1.10/login

CyberBuddy can identify indicators such as:

HTTP instead of HTTPS
IP address used instead of a domain
security-sensitive keywords such as login

The URL is then assigned a risk score based on the detected indicators.

How CyberBuddy Works

One of the most important design decisions I made was to separate security analysis from AI explanation.
The architecture looks like this:

              User Input
                  │
                  ▼
        ┌─────────────────────┐
        │ Deterministic       │
        │ Security Analysis   │
        └──────────┬──────────┘
                   │
                   ▼
        ┌─────────────────────┐
        │ Evidence Detection  │
        └──────────┬──────────┘
                   │
                   ▼
        ┌─────────────────────┐
        │ Risk Assessment     │
        │ + Risk Score        │
        └──────────┬──────────┘
                   │
                   ▼
        ┌─────────────────────┐
        │ Gemma 3 4B          │
        │ Local AI            │
        └──────────┬──────────┘
                   │
                   ▼
        ┌─────────────────────┐
        │ Simple Explanation  │
        │ + Safe Actions      │
        └─────────────────────┘

The important part is:
Gemma does not decide the security risk.

The deterministic CyberBuddy analyzers and risk engines are responsible for detecting indicators and calculating the risk.
Gemma receives that existing analysis and explains it in simple language.
This makes the AI an explanation layer, rather than the authority making the security decision.

Why I Used Gemma 3 4B

For the AI component, I chose Gemma 3 4B running locally through Ollama.
The reason was simple: I wanted CyberBuddy's AI functionality to work locally without requiring an external API key.

The setup is:

CyberBuddy
     │
     ▼
Ollama
     │
     ▼
Gemma 3 4B

Gemma receives the structured security analysis generated by CyberBuddy.
For example:

Risk: CRITICAL
Risk Score: 95
Possible Attack: Phishing

Indicators:
- Urgent language
- Credential request
- Account access threat
- Suspicious URL

Gemma then turns that technical information into something a normal user can understand.
For example:

This message is highly suspicious because it creates urgency, requests sensitive information, and threatens account access. Do not click the link or provide your OTP or password.

The model runs locally, so the AI explanation doesn't require sending the analysis to a third-party AI API.

Example: Message Analysis

Here's an example of the message analyzer detecting a phishing-style message.

URGENT! Your bank account will be blocked.
Please provide your OTP immediately at
https://example.com/login

CyberBuddy produced:

Risk: CRITICAL
Risk Score: 95/100
Possible Attack: Phishing

It also detected multiple indicators:

Urgent or pressure-based language
Credential or verification information requested
Financial or payment information requested
Account access threat detected
URL detected

The recommended actions include:

Don't click the link until it has been verified.
Don't provide passwords, OTPs, PINs, or verification codes.
Don't share banking or card information.
Verify the warning through the organization's official website or application. Gemma then explains these findings in simple language.

Example: URL Analysis

CyberBuddy can also analyze a URL independently.
For example:

http://192.168.1.10/login

The result was:

Risk: MEDIUM
Risk Score: 40/100

Hostname: 192.168.1.10
Protocol: HTTP

Detected indicators:

URL does not use HTTPS
IP address used instead of a domain name
Security-sensitive keyword detected: login

Gemma then explains why these indicators matter and provides practical guidance.
The goal isn't to tell the user:

"This website is definitely malicious."

Instead, CyberBuddy explains:

"These indicators suggest that the website may not be trustworthy. Be cautious and avoid entering sensitive information until the website has been independently verified."

That's an important distinction.

Fail-Safe AI Design

Another design decision was making the AI component optional.
If Ollama isn't running, CyberBuddy's deterministic analysis should still work.
The architecture therefore behaves like this:

Ollama available
       │
       ▼
Risk Analysis → Gemma → Explanation

But if Ollama is unavailable:

Ollama unavailable
       │
       ▼
Risk Analysis → Normal Result

The application doesn't depend entirely on the AI model to function.
This also keeps the security analysis predictable.

Technology Stack

CyberBuddy currently uses:

Python
FastAPI
JavaScript
HTML
CSS
Ollama
Gemma 3 4B
Pytest

Backend
The backend is built with FastAPI.
It provides endpoints for:

POST /api/analyze/message
POST /api/analyze/url
GET  /health

Frontend
The frontend is a lightweight HTML/CSS/JavaScript interface.
Users can switch between:

Message
URL

and receive the analysis directly in the browser.

Testing
The project currently has automated tests covering:

message analysis
message risk engine
URL analysis
URL risk engine Current test result:

=============================== test session starts ================================
platform win32 -- Python 3.10.11, pytest-9.1.1, pluggy-1.6.0
rootdir: B:\Hacktoberfest\Cyberbuddy
plugins: anyio-4.15.1
collected 39 items                                                                  

tests\test_message_analyzer.py ..............                                 [ 35%]
tests\test_risk_engine.py .....                                               [ 48%]
tests\test_url_analyzer.py ..............                                     [ 84%]
tests\test_url_risk_engine.py ......                                          [100%]

================================ 39 passed in 0.15s ================================

Building for a Non-Technical User

The most important part of this project wasn't just adding AI.

It was thinking about how a non-technical person would use it.

A security tool can detect dozens of technical indicators, but displaying all of them without context doesn't necessarily help someone.

CyberBuddy therefore tries to translate:

Technical Evidence
       ↓
Simple Explanation
       ↓
Practical Action

For example:

Credential request detected

becomes:

"The message is asking for sensitive information such as a password or OTP. Legitimate organizations generally shouldn't ask you to provide these through suspicious links or messages."

The goal is to make security guidance easier to understand and act upon.

What I Learned

Building CyberBuddy taught me several things beyond simply connecting an AI model to an application.

1. AI shouldn't always be the decision-maker
For security-related applications, deterministic rules can provide a predictable foundation while AI can make the results easier to understand.

2. Local AI is practical
Running Gemma through Ollama made it possible to add an AI explanation layer without requiring an external API.

3. User experience matters
A technically accurate security result isn't enough if the person using the application doesn't understand what it means.

4. Testing matters even for small projects
The project currently has:

39 automated tests
39 passing

This helped me make changes while ensuring the existing analyzers continued to work.

5. Building for a real person changes how you think
Instead of asking:

"What cybersecurity feature can I add?"

I started asking:

"What would actually help someone when they receive a suspicious message?"

That changed the direction of the project.

What's Next?

CyberBuddy is currently an MVP, so there is plenty of room for improvement.
Some things I'd like to explore next:

Security alert/log analysis
More sophisticated URL detection
Additional phishing indicators
Better AI response formatting
More automated tests
SOC-oriented alert explanations
MITRE ATT&CK mapping for relevant security indicators
More accessible UI for non-technical users

The goal is to gradually turn CyberBuddy from a simple analyzer into a more useful personal cybersecurity assistant.

Try CyberBuddy

The project is available on GitHub:

akashjha518 / CyberBuddy

CyberBuddy is an AI-powered cybersecurity assistant that helps non-technical users analyze suspicious messages and URLs, assess security risks, and understand threats through local Gemma 3 4B AI running with Ollama.

🛡️ CyberBuddy

AI-Powered Cybersecurity Assistant for Non-Technical Users

CyberBuddy is a local, AI-powered cybersecurity assistant designed to help non-technical users understand and respond to suspicious messages and URLs.

Instead of requiring cybersecurity knowledge, CyberBuddy analyzes potentially dangerous content, identifies security indicators, assigns a risk level, and explains the result in simple language.

The project uses deterministic security analysis for risk assessment and Gemma 3 4B, running locally through Ollama, as an AI explanation layer.

🚀 Why CyberBuddy?

Cybersecurity warnings are often difficult for non-technical users to understand.

A suspicious message may contain:

Urgent requests
Phishing links
Requests for passwords or OTPs
Fake account warnings
Financial requests
Suspicious URLs

CyberBuddy provides a simple workflow:

Suspicious Message / URL
          ↓
   Security Analysis
          ↓
    Risk Assessment
          ↓
      Evidence
          ↓
    Gemma 3 4B AI
          ↓
 Simple Explanation
          ↓
    Safe Actions

✨ Features

📩 Suspicious Message Analyzer

Analyze suspicious emails, SMS messages, and…

View on GitHub

To run the project locally, you'll need Python, Ollama, and Gemma 3 4B.
The basic AI setup is:

ollama pull gemma3:4b
ollama run gemma3:4b

Then start the CyberBuddy backend:

uvicorn backend.main:app --reload --port 8000

Open the frontend and start analyzing suspicious messages or URLs.

Final Thoughts

Cybersecurity doesn't have to be understandable only to cybersecurity professionals.
Sometimes the most useful security tool is one that simply answers:

"Here's why this looks suspicious, and here's what you should do next."

That's what I wanted CyberBuddy to provide.
I'm excited to build on this project and continue exploring how local open-weight AI can make cybersecurity guidance more accessible to everyday users.
Thanks to the Hacktoberfest Weekend Challenge: Build for a Friend for encouraging developers to build something around a genuine problem faced by someone else.

DEV Community: Akash Jha

QuietSOC 🔐 — Stop Drowning in Logs. Start With the Evidence.

What I Built

Demo

Code

How I Would Build It

Why Does Open Innovation Matter?

My Agent Session

The Lazy Payoff

Prize Categories

ScamShield: I Built a Local AI Scam Detector for Freelancers

ScamShield: I Built a Local AI Scam Detector for Freelancers

What I built

How it works

Why open-source AI matters here

Technology stack

Testing and reliability

Who could use it?

Try the project

akashjha518 / ScamShield

ScamShield 🛡️

Protect Your Freelance Journey. Spot Scams Before They Strike.

Contents

Why ScamShield?

What I learned

Conclusion

🌿 CyberEscape: What If Your Next Cybersecurity Lab Was a Walk Outside?

What I Built

Demo

Code

How I Built It

Technology stack

1. Mission generation

2. Reflection and AI feedback

3. Local AI with Ollama and Gemma 3 4B

4. Progress tracking

Why Does Open Innovation Matter?

Local inference and user control

Experimentation with open-weight AI

Why Gemma?

Safety by design

My Agent Session

Prize Categories

Final Thoughts

I Built CyberBuddy: A Local AI Cybersecurity Assistant for Non-Technical Users

The Problem

Meet CyberBuddy

How CyberBuddy Works

Why I Used Gemma 3 4B

Example: Message Analysis

Example: URL Analysis

Fail-Safe AI Design

Technology Stack

Building for a Non-Technical User

What I Learned

What's Next?

Try CyberBuddy

akashjha518 / CyberBuddy

CyberBuddy is an AI-powered cybersecurity assistant that helps non-technical users analyze suspicious messages and URLs, assess security risks, and understand threats through local Gemma 3 4B AI running with Ollama.

🛡️ CyberBuddy

AI-Powered Cybersecurity Assistant for Non-Technical Users

🚀 Why CyberBuddy?

✨ Features

📩 Suspicious Message Analyzer

Final Thoughts