# Build to Break: Your Guide to Cybersecurity at Hacktoberfest HackDay x OWASP JIS Univerity

> Source: <https://dev.to/arceuzvx/build-to-break-your-guide-to-cybersecurity-at-hacktoberfest-503b>
> Published: 2026-09-27 12:34:08+00:00

Welcome to [Hacktoberfest Hack Day Kolkata x OWASP JIS University](https://events.mlh.com/events/14953-hacktoberfest-hack-day-kolkata-x-owasp-jis-university) 💖

Build a project that solves a real cybersecurity problem.

Your project can focus on application security, cloud security, AI security, authentication, supply-chain security, detection and response, DevSecOps, or another security challenge.

You don't need to build a complete enterprise security platform. **Pick one meaningful problem, build a focused solution, and demonstrate that it works.**

Here are some areas to explore:

These are starting points, not restrictions. **If you have a different cybersecurity idea, build it.**

A simple way to structure a cybersecurity project is:

```
┌──────────────┐
│   Problem    │
└──────┬───────┘
       ↓
┌──────────────┐
│    Attack    │
└──────┬───────┘
       ↓
┌──────────────┐
│Security      │
│Control       │
└──────┬───────┘
       ↓
┌──────────────┐
│ Demonstrate  │
│   & Test     │
└──────────────┘
```

Ask:

**What are you trying to protect, and what are you protecting it from?**

For example:

**Problem:** Exposed API credentials can be used to access sensitive resources.

**Attacker:** Someone who obtains a leaked credential.

**Impact:** Unauthorized access to data or services.

Before building the solution, understand how the attack actually happens.

Think about:

**Attacker → Attack Vector → Vulnerability/Weakness → Impact**

```
Attacker
   │
   ▼
Stolen API Key
   │
   ▼
Unauthorized API Access
   │
   ▼
Sensitive Data Exposure
```

Your project should intervene somewhere in this attack path.

Your project should **do something about the security problem**.

```
Source Code
    │
    ▼
Secret Scanner
    │
    ▼
Credential Detected
    │
    ▼
Alert / Block Commit
```

Or:

```
IAM Policy
    │
    ▼
Permission Analysis
    │
    ▼
Privilege Escalation Path
    │
    ▼
Finding + Remediation
Security Logs
    │
    ▼
Detection Engine
    │
    ▼
Suspicious Activity
    │
    ▼
Alert / Investigation
```

The goal isn't to have the most features. **A focused security control that works is more valuable than a large collection of unfinished features.**

If you're using **Gemma or another open-source/open-weight model**, give the model a meaningful role in your system.

```
Security Detection
       │
       ▼
     Gemma
       │
       ▼
Explanation / Correlation
       │
       ▼
Remediation Recommendation
```

Good uses for AI include:

Treat model output as **untrusted input**, especially if it generates:

Prefer:

```
AI Output
    │
    ▼
Validation
    │
    ▼
Controlled Action
```

rather than:

```
AI Output
    │
    ▼
Production
```

Don't only demonstrate the happy path.

Try to break your own system.

At minimum, test:

```
Normal Prompt
     ↓
   Works

Malicious Prompt
     ↓
Injection Detected
     ↓
   Blocked
Vulnerable Policy
       ↓
Privilege Escalation
       ↓
     Detected
       ↓
Remediation Suggested
Leaked Credential
       ↓
    Detected
       ↓
Commit Blocked
       ↓
Developer Alerted
```

A cybersecurity project should be demonstrated with an actual security scenario.

A simple structure is:

**Attack → Detection/Prevention → Result**

Don't just show a dashboard and say:

"Our system detects attacks."

Show the attack.

Show what your system detects or prevents.

Show the result.

Avoid making claims that you cannot demonstrate.

Instead of:

"Our system completely prevents phishing."

Explain what your system actually does:

"Our system detects suspicious websites using URL, DOM and visual features."

"Our AI guarantees secure code."

Say:

"Our AI identifies potential security issues and suggests remediation."

If you report metrics such as accuracy, explain how you measured them.

[OWASP Top 10:2025](https://top10.owasp.org/2025/)

A starting point for understanding common application-security risks and finding project ideas.

[OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/)

Useful for projects involving LLMs, GenAI, AI agents, or open-source models.

[OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)

Practical implementation guidance for common security topics.

[OWASP API Security Top 10](https://owasp.org/API-Security/)

Useful if your project involves APIs, authentication, authorization, or access control.

[OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)

Use this to test your web application before submission.

[OWASP GSoC Project Ideas](https://community.owasp.org/initiatives/gsoc/gsoc2026ideas)

Explore real OWASP open-source projects and technical problem areas for additional inspiration.

[OWASP Project Directory](https://owasp.org/projects/)

Browse existing OWASP projects across application security, AI security, cloud security, tooling, and more.

These are provided for **inspiration and further exploration**. You do not need to contribute to an existing OWASP project for the Hackday.

Before submitting, ask yourself:

**Problem → Attack → Security Control → Test → Result**

You don't need to build the next enterprise security platform.

**Pick one real security problem. Understand it. Build a focused solution. Try to break it. Then demonstrate that your solution works.**