Competition Rules

Structure

The SWD Competition is a BIBIFI competition centered on web application security and vulnerability discovery and reporting. The competition is divided into three phases: the build-it, the break-it, and the fix-it phases.

  1. Build-it Phase: During the build-it phase, teams will develop an entire web application following the docs and specs that we provide. Teams get scored based on the specs’ adherence.

  2. Break-it Phase: During the break-it phase, teams will search for vulnerabilities in each other web applications. Teams will create working exploits and write high-quality vulnerability reports. Teams are scored based on the number of confirmed vulnerabilities.

  3. Fix-it Phase: During the fix-it phase, teams will address reports submitted by other teams by patching their code. Scoring is based on the number of fixed vulnerabilities.

General Rules

We invite students to report violations or inappropriate behaviors to the organizers. For more information, see the Reporting to the Organizers.

Code of Conduct

  • Your code will be tested on our servers and operate within our trust boundaries. Attacking our servers or any other component of the SWD infrastructure will not be tolerated. We consider scanning, probing and reconnaissance tests attacks too. Students will be disqualified and fail the lecture. However, we welcome feedback and reports about issues, problems, and improvements.
  • The SWD competition will foster a positive, ethical, and responsible culture about vulnerability notifications and vulnerability management. When interacting with one another, we expect students to do so professionally and respectfully. Misbehaviors like using abusive, offensive, and disrespectful language are not tolerated and will be penalized. Repeating or severe cases can disqualify students and fail the lecture.

During the build-it phase:

  • Teams are not allowed to obfuscate their code. You can be disqualified and fail the lecture.
  • Teams are not allowed to collaborate. You can be disqualified and fail the lecture.
  • Teams implementing mockup code with the goal to gain builder points can be reported to the organizers, who can take actions against them, e.g., assigning penalties or even disqualifying offenders.
  • Teams needs to reach a minimum number of points to be eligible for the exam. The number of points depend on the size of the team, starting from 300 points for two-members team and +100 points for each additional team member.

During the break-it phase:

  • Teams are not allowed to commit changes to their code.
  • Teams are not allowed to collaborate. You can be disqualified and fail the lecture.
    • Sharing vulnerabilities, PoCs, artifacts, or other useful hints/leads to find vulnerabilities
  • Teams are allowed to file at most 5 vulnerability reports against a single team.
  • Teams submitting bogus reports to gain breaker points can be reported to the organizers, who can take actions against them, e.g., assigning penalties or even disqualifying offenders.
  • Teams that could not find vulnerabilities in other projects are required to submit a technical report about the security assessment strategy and techniques used during the break-it phase.

During the fix-it phase:

  • Teams are not allowed to submit new vulnerability reports.
  • Teams must fix a single vulnerability at a time. It is forbidden to push one single patch addressing multiple vulnerabilities at once.
  • Collaboration during the fix-it phase is allowed and encouraged.
  • Teams improperly using issues to gain builder points can be reported to the organizers, who can take actions against them, e.g., assigning penalties or even disqualifying offenders.

Rules for Vulnerability Reports Management and Lifecycle

Teams reporting, addressing, and handling vulnerabilities must follow the instructions in Vulnerability Reports Management and Lifecycle.

Rules for Patches and Git Commits

Developer teams must follow the instructions in Rules for Patches and Git Commits.