Several rules for organizing a cybersecurity hackathon

We’ll tell you how we planned and held the event so that it was not only useful, but also memorable for the development teams.

Preparation Rules

The central element of the event was a specialized platform with functionality for team formation, task booking, score tracking, and progress monitoring. Upgrading the platform took quite some time: we added a user-friendly interface for participants, automated score calculation, and integrated with other corporate systems. This minimized the organizers’ manual work and made the process as transparent as possible.

This was our first time running a cyber security bugathon, and none of the participants had encountered this format before. So before the event, we held a briefing, introduced the teams to the rules, and prepared them for the challenges. All events were held online in the evenings so everyone could join in comfortably.

We held three workshops in total:

• Workshop #1: “How to Work with Vulnerabilities: A Guide for Development Teams.”
  We explained how to identify and classify vulnerabilities correctly, and shared best practices for dev teams. This helped participants understand where to start and what to focus on.

• Workshop #2: “Approaches to Fixing Vulnerabilities in Your Applications.”
  We discussed methods for fixing vulnerabilities, reviewed real cases, and talked about tools and techniques that help minimize risks.

• Q&A session before the bugathon. This final meeting covered a recap of the rules and bugathon mechanics, answered questions, and gave last recommendations to resolve misunderstandings and set teams up for productive work.

Opening

We started with a business breakfast. Breakfast sets the right tone: everyone is well-fed, happy, energized, and cheerful. We also handed out branded starter packs to participants: drip coffee packs, sticker packs, and “remuvki” for a good mood.

Don’t forget the merch. The event will be over, but the memories will stay.

After breakfast, the VP of IT gave a kickoff speech, emphasized the significance of cyber security, and wished all the participants good luck. At 11:00, he ceremoniously struck the gong to officially start the bugathon.

At that moment, tasks went live on the platform, and the teams dove in.

For two days, participants solved challenges, hunted vulnerabilities, and earned points. We did our best to create a comfortable environment: team areas in the office, breakfast and lunch in the kitchen. Organizers were available 24/7 to answer questions and support participants.

Tasks

One of the problems with bugathons is that the tasks are monotonous and come from technical debt. How we made it interesting: some of the tasks were invented from scratch, so the approaches to solving them were not similar to the usual work tasks.

And to give teams variety and motivation to try something new, we allowed participants to choose for themselves and prepared 4 types of tasks:

1. Fixing vulnerabilities identified by automatic scanning tools (SAST/SCA).

2. Fixing vulnerabilities discovered by the AppSec team.

3. Writing security autotests

4. Finding new vulnerabilities.

A bit about the task mechanics.

The vulnerabilities for the first type of task were grouped by repositories. Each individual task actually consisted of N vulnerabilities identified by tools in the repository. For each fixed vulnerability, X points were awarded — the total number of points for a task corresponded to the number of vulnerabilities (N) multiplied by X. If a team managed to fix only part of the vulnerabilities in a repository, we awarded the corresponding number of points.

The mechanics for the teams were fairly simple. They needed to:

• create a separate branch,

• make changes,

• run a scan of the branch to make sure the vulnerabilities were fixed,

• open a PR to the release branch and report in the chat.

PRs were reviewed by tech leads for the relevant competency (for standards compliance) and by the AppSec team (for the scan report and its results). If everyone gave an "OK," the task was considered "preliminarily" solved and the team was awarded points.

"Preliminarily" because to fully complete the task, the team had to deploy those changes to production — and without making any further edits to the code.

We did not require teams to do regression testing or submit a testing report during the bugathon, but this was a mandatory prerequisite for deployment, so teams were motivated to check everything before finishing the task, so as not to lose points if problems arose before release and they had to make code changes.

The second type of task differed from the first in that:

• each vulnerability was its own separate task,

• to confirm it was fixed, AppSec approval was required.

As with the first type, teams created a separate branch, made code changes, and set up delivery to the test environment. Then they asked the AppSec team to confirm that the vulnerabilities were fixed. After receiving approval from the competency tech lead and the AppSec team, the team received "preliminary" points.

The third type of task focused on writing security autotests.

Some of the checks that the AppSec team performs manually when analyzing updates can be automated. This ensures those checks are always performed (for example, by integrating them into the team’s pipelines) and reduces the workload on AppSec specialists. These are exactly the checks teams implemented during the bugathon.

Each task of this type involved writing several automated tests, and for each test, we assigned a certain number of points. The most active participants in solving this task were the QA specialists. They wrote the automated tests, while the AppSec team, together with the QA tech leads, verified both the logic of the automated test and the quality of its implementation.

The last type of tasks was aimed more at engaging developers and giving them the feeling of being real hackers. We did not expect that the teams would be able to find both the time and the resources to search for vulnerabilities, but we hoped. And we were pleasantly surprised that the guys managed to handle this task and find a couple of vulnerabilities in their colleagues' functionalities.

For this activity, we created abstract tasks without any specific context.

Each found vulnerability was assessed by the AppSec team, and if it was confirmed and no one had previously reported it (even outside the event), we awarded points depending on the level of criticality.

Note. In the article, we shared tasks similar to those we gave during the bugathon. Feel free to read, we have detailed the solutions.

Five simple* cybersecurity tasks for developersHello! This is Masha from AppSec at Alfa-Bank. I love making sure developers enjoy their work, and the products are well... habr.com

Closing

Bugathons, hackathons, and other similar events usually last one or several days. And at the end, participants want to feel that they did not waste their time. Therefore, the final part was the most grandiose. The evening closure included delicious food, drinks, and numerous interactive activities where everyone could win prizes.

We gathered the participants in an internal venue, decorating it in the style of the event. Plus, a good backdrop for photos.

The ceremonial part should not be prolonged.

Ours began with the final word from the cybersecurity director, who thanked everyone for their participation. And then we moved on to awarding the top 3 winning teams. Interestingly, the competition for the 1st and 3rd place was tense — the outcome of the prize spot was decided by a single delivery.

We also separately recognized the bug hunters — those who found vulnerabilities during the bugathon.

The closing is the final point when all participants can feel the atmosphere of the event and get inspired to participate next time.

Results

A few conclusions in the form of notes.

• We engaged IT specialists in cybersecurity and were pleased with the numbers – 24 teams of up to 10 people. A month later, we hit a sold out (250+ participants) at an internal CTF.

• A pleasant "side effect" — closed vulnerabilities, written security autotests, and clean repositories.

• Screw-ups. Can't do without them. For example, we figured out that tasks from pentesters are more difficult and should be priced higher. We also realized how tough it is to work with someone else's functionality — testing and rolling out changes through other teams.

• Mythbusting: that it's impossible to fix a vulnerability in 2 days or to find a new vulnerability in someone else's functional area.

People are the main value! All of this worked out thanks to the joint efforts of four departments. Thanks for the support to IT, AppSec, Internal Comms, DevRel, and the marketing department.

And to everyone who participated.