Weekly Triage

Overview

The Vulnerability Management team receives, reviews, and approves/denies various requests including for Deviation Requests or SLA Exceptions. To ensure timely consideration of these requests, a team member is assigned randomly on a rotation as the DRI for the week for the initial triage and handling of new requests for that week.

Automation creates a new Weekly Triage Issue at the start of each week, and randomly chooses a team member to assign it to. The issue is based on this issue template which includes

General Guidance

TODO

Specific Guidance

POA&M

TODO

SLA Exceptions

As part of the weekly triage rotation the Vulnerability management team reviews & approves/denies SLA Exception requests, SLA Exception Requests can be raised by any other Gitlabber by following the SLA Exception Guidelines. These steps are here to guide the review process and provide consistent templated Approved/Denied messaging to the SLA Exception requester.

• Following the steps listed under the For Approver Section of the SLA Exception request
  • Please review the information above and approve at your discretion.
    • Does the justification convey a clear reason as to why an exception is required?
      • No? -> Request further information from the Requester.
    • Is this SLA Exception appropriate? When is an SLA exception request appropriate?, When is it not appropriate to request an SLA exception?

      • No? -> Fill in the template message bellow and post it as a comment on the SLA Exception request.

        Hi @<author>, 
        
        Thank you for raising this request for an SLA Exception, however the Vulnerability Management team cannot approve this exception request as the SLA cannot be met due to <fill in the reason> is within GitLab’s control, this fall's under [When is it not appropriate to request an SLA exception?]<!-- vale gitlab_<type>.handbook.RelativeLinks = NO -->(https://handbook.gitlab.com/handbook/security/product-security/vulnerability-management/sla-exceptions/#when-is-it-not-appropriate-to-request-an-sla-exception)<!-- vale gitlab_<type>.handbook.RelativeLinks = YES -->.
        
        For futher questions please comment here or reach out to `@vulnerability-team` in #security_help
        
        The Vulnerability Management team
        
        /label ~"ExceptionRequestApproval::Declined" 
        

      • Yes? -> Continue with reviewing the exception for approval.

        • Review remediation work outlined in the SLA Exception request.

          • If the remediation work is not outline clearly, seek clarification from the requester.

            Hi @<author>
            
            Can you please clarify the remediation plan for this vulnerability in question.
            
            Thanks
            The Vulnerability Management team
            

        • Review the expected Exception length against the Exception Length Restrictions.

          • If the exception length requested is not in line with the restriction, set the exception length to the maximum allowed for the severity level and respond to the requestor.

            Hi @<author>
            
            The exception length requested is not within the allowed <!-- vale gitlab_<type>.handbook.RelativeLinks = NO -->[Exception Length Restrictions]https://handbook.gitlab.com/handbook/security/product-security/vulnerability-management/sla-exceptions/#exception-length-restrictions)<!-- vale gitlab_<type>.handbook.RelativeLinks = YES -->. We have set the exception length to the maximum for the severity of this vulnerability. If the allowed time frame is not sufficient for remediation, please respond and we will work together to identify and document mitigation solutions.
            
            Thanks
            The Vulnerability Management team
            

        • If you are happy with the remediation details are accurate, clear and the exception length is appropriate. Complete the Approval wiht the following comment.

          Hi @<author>,
          
          Thank you for providing a clear and concise exception request, the Vulnerability management team is happy to approve this request for the requested timeframe.
          The due date has been set.
          
          Thanks
          The Vulnerability Management team
          
          /label ~"ExceptionRequestApproval::Approved" 
          /due in <n> days
          

        • Check for alignment and apply the appropriate risk treatment label if the requester has not done so.

SLA Exception near breach or breached

As part of the weekly triage rotation, a review of approved SLA Exception’s nearing their due date is performed. These steps are here to guide the process and provide consistent templated messaging to the SLA Exception request owner.

For an exception to fall under the At risk SLA Exceptions table, the due date must fall in the 2 weeks prior to the Weekly Triage Rotation issue due_date and be in an open state.

1. Add a comment to the SLA exception using the template below.

   Hi @<author>, 
   
   This SLA Exception is at risk of breaching due date.
   
   Has remediation work been completed?
   Can this exception request be closed?
   
   If not, please provide
     - An expected remediation timeline.
     - Detail why the existing extension was missed.
     - A requested to update the exception length if need be.
   
   note: An extension to the initial exception length is not a given and will require a approval by the Vulnerability Management Team.
   
   If all remediation work has been completed and deployed
     - Please confirm this is the case.
     - Please close close the SLA Exception Request issue.
   
   Thank you for your time.
   The Vulnerability Management team
   

Deviation Requests

TODO

Wiz issue/finding

TODO

View page source - Edit this page - please contribute.