Purple Team Hackathons for Application Security Testing

As a cyber security consultant, I have been responsible for overseeing security testing practices and coordinating penetration tests to ensure that after major updates, applications remained secure and aligned with the OWASP Top 10. While these tests effectively assessed compliance with standard security benchmarks, they often missed the types of vulnerabilities that could be uncovered if a user interacted with the application unexpectedly.

The issue is twofold. Developers have full knowledge of the applications but lack the objectivity to complete thorough testing; it would be equivalent to marking their own work. External testers, on the other hand, may lack the deep product knowledge to test thoroughly beyond the OWASP framework, especially within the constraints of a typical five-day penetration test.

To bridge this gap, I proposed an internal hackathon focused on identifying weaknesses within the codebase. To encourage participation and maximise engagement from the workforce, I suggested monetary rewards for teams that successfully discovered vulnerabilities.

Problem Statement

The hackathon addressed a knowledge gap between penetration testers and developers. Each party lacked either the objectivity or the product-specific knowledge depth needed to test applications in a deeper way. The hackathon was the right approach because it was collaborative and leveraged the in-depth knowledge already possessed by developers.

Many organisations struggle with maintaining their codebase. Contributions are often made over time by multiple authors with varying approaches to security. This lack of consistency makes keeping the codebase secure problematic and unwieldy. Traditional penetration tests, while valuable, tend to yield a narrower and more generic set of findings, usually in alignment with the OWASP Top 10.

I proposed the hackathon as a low-cost method of improving the codebase by identifying vulnerabilities and cultivating a stronger application security mindset, with the findings from the hackathon being logged and resolved internally.

How hackathons support AppSec and purple teaming

A security hackathon can support application security by giving developers, testers, security teams and wider business participants a structured way to look for weaknesses in a realistic but controlled environment. It also creates a purple team dynamic because offensive thinking, defensive learning and remediation planning happen close together.

This approach does not replace formal penetration testing or secure SDLC controls. Instead, it adds another layer of collaborative security testing that can help teams improve secure coding practices, identify recurring vulnerability patterns and build developer security awareness.

The Challenge

The hackathon was open to the entire workforce, allowing teams of four to participate in a one-day bug-hunting hackathon within a test environment that closely mirrored the production codebase for a single application. Teams were asked to register ahead of time.

Lessons Learned

When setting out to plan a hackathon, I thought the engineering team would find bugs that were outside of what is usually found in a penetration testing engagement. However, the results were better than expected. Here are the key lessons learned from this exercise:

• Non-technical employees expressed an interest in the hackathon, which created an opportunity to champion security outside of technical teams.
• Preparation is everything. During the first hackathon, feedback revealed that uncompiled code within the environments ate into testing time.
• Financial rewards are a massive incentive. Similar to public bug bounty programmes, many people are motivated by monetary incentives.
• Bugs found will likely highlight a trend in coding practices, creating opportunities to improve the wider codebase.
• Some technical employees are likely to have a strong interest in security, which creates opportunities to nurture internal AppSec talent, security champions and specialised roles.

Running an internal bug bounty hackathon is a practical way of building a security-first culture within your engineering team. The benefits gained from the event are determined by careful planning and clear objectives.

Guidelines for setting up your bug bounty hackathon

The hackathon supplemented the existing penetration testing in place, allowing teams to uncover obscure and intricate bugs based on their knowledge of the product. This was valuable because any bugs discovered could be fixed across all instances where the code was used, maximising the impact of a single discovery.

Security culture building through internal hackathons

Internal hackathons can also support security culture building because they make security visible, practical and collaborative. Instead of security being seen only as a gatekeeping or audit function, teams experience security as something they can actively contribute to.

This matters for AppSec because developer behaviour, secure coding habits, vulnerability reporting, remediation discipline and cross-team communication all influence whether security improvements last after a single test or event.

I encourage organisations to experiment with internal hackathons to improve the quality of their codebases, foster the purple team skill set and increase security awareness across the organisation. By gamifying the security testing process, hackathons serve as an educational and impactful way of bringing security to the forefront.

Key takeaways

• Many people across the organisation are likely to be curious about cyber security, and the hackathon can be used to involve them.
• Bugs discovered during the hackathon can help identify skill gaps within the development team and shape future security awareness training.
• A hackathon can enhance cross-departmental communication by encouraging collaboration between people who would not usually work together.
• Collecting data on the type of bugs found in each hackathon can provide valuable insight to multiple stakeholders.