Vulnerability Reports Management and Lifecycle

A vulnerability report is a confidential GitLab issue, and two entities are involved:

  • The reporter is who creates the GitLab issue. The reporter is a member of the team that finds a vulnerability during the break-it phase.
  • The developers are all team members of the (supposedly) vulnerable program.

Confidential issues are visible only to the developers (with sufficient permissions) and the reporter.

The communication between developers and reporters must take place using the issue comments.

Additional resources: Managing issues with GitLab

Report Management and Lifecycle

The lifecycle of a vulnerability report starts by opening a GitLab issue and terminates by closing it. GitLab issues can be reopened.

The figure below sketches the lifecycle of a vulnerability report for the SWD competition. The SWD competition scoring rules are built on top of the figure below.

Lifecycle of reports

New Issues (Break-it phase)

During the break-it phase, teams look for vulnerabilities in each other project and, whenever a team discovers one, a member of the team opens a new confidential issue in the developer’s project repository:

Confidential Issue

Important: The reporter MUST tick the check box This issue is confidential and should only be visible to team members with at least Reporter access.

Issues that are not flagged as confidential are visible to all teams and are not valid reports.

Reporters must fill all the fields with meaningful content:

  • Title: a title that summarizes the vulnerability
  • Type: select Issue
  • Description: precisely present the program behavior, how the behavior introduces a security risk, possible exploitation steps by an attacker, and the impact of successful exploitation. When presenting the program behavior, be as specific as possible. The more specific you are, the sooner developers will be able to reproduce and confirm the vulnerability.
  • Attachment: if you have prepared a proof-of-concept script, attach it! PoCs are always welcome, and speed up developers’ response.

In Progress (Fix-it phase)

During the fix-it phase, developers review their projects’ issues. In this phase, typically, each team assigned a developer to each issue, and the issue is in progress. The assignee is responsible for processing the issue.

Processing can result in:

  • The assignee confirms the vulnerability. The assignee reproduces the exploitation steps based on the issue description or successfully executes the PoC script. The assignee uses the tag CONFIRMED.
  • The assignee confirms the vulnerability, but another team reported it before. The assignee uses the tag DUPLICATE.
  • The assignee could not confirm the presence of the vulnerability. For example, the assignee could not understand the vulnerability description or reproduce the exploitation steps. In these cases, the assignee should seek the assistance of the reporter. The assignee could also not confirm the vulnerability because the report is incorrect or the reported behavior does not pose a real security risk. The assignee uses the tag NOT_CONFIRMED.

Closed (Fix-it phase)

When the processing of the issue is over, developers close the issue.

Resolved

When a vulnerability is confirmed, developers must:

  1. Work on a patch.
  2. Commit the patch to the repository. The commit string message MUST follow specific rules. See below.
  3. Add a comment to the issue acknowledging, thanking the reporter, and asking to verify that the patch fixes the issue
  4. Use the tag RESOLVED
  5. Close the issue

If developers or reporters perform additional tests to verify the effectiveness of the patch, the assignee can use the tag VERIFIED.

Declined or Invalid

This case happens when the assignee could not reproduce the problem for multiple reasons:

  • The assignee could not reproduce the problem with the information provided. In this case, the report is declined. The assignee uses the tag DECLINED.
  • The report does not describe an actual vulnerability. In this case, the report is invalid. The assignee uses the tag INVALID.

Won’t Fix

Fixing vulnerabilities can take time and developers may decide to prioritize the work. As a result, developers may decide not to fix a valid report. The assignee uses the tag WONTFIX.

Re-opening Issues

When an issue is closed because declined or invalid, the reporter could provide additional information. Developers and reporters must use comments to share more details about the report.

Developers or reporters can also reopen an issue that has already been patched. For example, this may happen when the patch is later discovered to be insufficient.