Workflow schema

Jira workflow

The SECURITY Jira project (https://folio-org.atlassian.net/browse/SECURITY) uses this workflow:

Workflow of the SECURITY Jira project

The OPEN state is the inital state, it is automatically embargoed – only security team can view the ticket. Open tickets need to be triaged.

If a member of the security team has triaged the ticket, the state is changed to “TO VOTE” (needs fix) or “UNDER REVIEW” (no fix needed). The member adds a comment explaining the triage result and the proposed next steps.

A “TO VOTE” ticket has a comment with a proposed fix. On the next security team meeting the team can approve the ticket and move it to the “IN PROGRESS” state.

If the ticket is “IN PROGRESS” the actual fix gets prepared. As the security ticket is still embargoed one or more additional tickets are created in the Jira projects of the affected modules so that the development teams prepare the fix. Critical service patch (CSP) approval justification is provided in the tickets as needed. The security ticket has “is implemented by” links to them.

If a module version with the fix has been released a member of the security team moves the state of the security ticket to “UNDER REVIEW”.

When a member of the security team moves a ticket to “UNDER REVIEW” state the member adds a comment with the proposed resolution: Done (fix has been provided), Declined (FOLIO is not affected), Won’t do (risk is tolerable, or flower release is out of support), Duplicate (there already exists a ticket about the same issue). The “UNDER REVIEW” ticket should be handled off-line by adding a thumb up to the comment, or adding comments. If there is no disagreement and two other members of the security team have added a thumb up then the ticket is moved to “COMPLETED” state while setting the proposed “Resolution” field.

The “Resolution” field gets cleared when the “COMPLETED” state is changed.

If needed any state can be changed to any other state to skip a state or got back to a previous state.