Beyond Tutorials: Our First Hackathon and Open Source Experience

Hey everyone! 👋

I'm Gurjot, a first-year student at Alta School of Technology, and this is my first time sharing my experience on DEV.

I'm had recently participated in my first hackathon with my team, KOS, where we're working on a cybersecurity project called Reachable Vulnerability Analyzer.

If someone had asked us a few months ago what working on a real-world software project looked like, we probably wouldn't have had a very clear answer.

Like most beginners, our coding journey started with learning programming, solving basic problems, watching tutorials, and trying to understand how things actually work. We were learning different programming concepts, getting familiar with Git and GitHub, and slowly exploring the world of development.

We knew there was a lot more to software development than just writing code, but we hadn't really experienced it ourselves.

And now, here we are, participating in our first hackathon and getting our first real exposure to open-source development.

Honestly, we were excited, a little nervous, and weren't entirely sure what to expect.
So, where did it all begin?
Hackathons have always sounded exciting to us. People come together, pick a problem, brainstorm ideas, write code, make mistakes, debug things, and somehow try to turn an idea into something useful within a limited amount of time.

But experiencing it yourself is quite different from just hearing about it.

This time, we got the opportunity to work on a project that introduced us to a completely new area of development: Cybersecurity.

And that's where things got interesting.
The project we're working on
Our project is called Reachable Vulnerability Analyzer.

When we first went through the problem statement, we had to read it a couple of times to properly understand what we were actually supposed to build.

Here's the basic idea.

Most modern applications depend on third-party libraries and packages. Sometimes, these libraries contain security vulnerabilities, and security scanners report them even when the vulnerable functionality is never actually used by the application.

This creates unnecessary alerts and makes it harder for developers to identify which vulnerabilities actually matter.

Our goal is to build a tool that can analyse whether a vulnerable function inside a dependency is actually reachable from the application's code.

In simpler words, we don't just want to know whether a vulnerable package is present. We want to understand whether our application can actually reach the vulnerable part of that package.

Sounds interesting, right?

At least, that's what we thought before getting into the technical side of it! :')
The part nobody really talks about: Understanding things before building them
We think one of the biggest surprises for our team has been realising how much goes into understanding a project before you even start writing the actual code.

We started by exploring the existing GitHub repository, going through its folders, understanding the project structure, and trying to figure out how everything was connected.

We also had to set up the development environment using Python, install dependencies, create virtual environments, and get everything running properly.

And trust us, even these initial steps taught us quite a bit.

There were moments when we weren't sure what a particular file was doing or why something wasn't working. Sometimes, a small setup issue would take more time than expected.

But slowly, things started making sense.

We also came across concepts like static analysis, call graphs, dependency analysis, and vulnerability reachability. Most of these were new to us, so understanding them was a learning experience in itself.

One thing we particularly found interesting was the concept of a call graph. It basically helps us understand how different functions call one another and how a particular function might be reached during program execution.

It's fascinating how something that looks like a simple function call can become an important part of analysing software security.
More questions, more confusion, more learning!
One thing we've noticed while working on this project is that every answer somehow leads to another question.

For example, what if our analyser encounters a vulnerability that isn't already present in its database?

What if the library is unknown? Can we still analyse whether a vulnerable function is reachable?

Should our tool depend entirely on existing vulnerability databases, or should it also be capable of analysing unfamiliar situations?

These are some of the questions that have made us think beyond the obvious solution.

We're slowly understanding that building a project isn't just about making something work for a few expected cases. It's also about thinking about what could go wrong and how the tool should handle situations we haven't planned for.

And honestly, that's one of the most interesting parts of this entire experience.
From watching Git tutorials to actually using Git
Another small but important part of this journey has been getting more comfortable with Git and GitHub.

We had previously tried learning Git through online tutorials, but we won't lie, some concepts just didn't make sense to us at first.

Working with an actual repository has made things much easier to understand.

Cloning repositories, navigating through folders, using the terminal, setting up environments, and figuring out how an existing project works — these things might sound basic, but when you're doing them for the first time, every small step feels like progress.

We've realised that watching someone do something and actually doing it yourself are two very different experiences.
It's still going on!
The hackathon is currently in progress, so we don't have a final result or a success story to share just yet.

There are still things to figure out, problems to solve, and a lot of learning left to do.

But we think that's what makes this experience special.

We're getting to work on something that we wouldn't normally encounter while solving everyday programming questions. We're exploring a new domain, understanding an unfamiliar codebase, and learning how real-world development works.

As first-year students, we know we have a long way to go. There are plenty of concepts we still need to understand, and sometimes even the basics can be challenging.

But we're beginning to realise that you don't necessarily need to know everything before you start.

Sometimes, you just need to take the first step and figure things out along the way.

This is our first hackathon, our first proper open-source experience, and hopefully the beginning of many more such experiences.

For now, we're just enjoying the process, learning whatever we can, making mistakes, asking questions, and trying to build something meaningful.