This document outlines the steps required to prepare for and establish a vulnerability management program. It does not cover methods for vulnerability discovery (e.g., scanning, pentesting, bug bounty, threat modeling, etc.); instead, it focuses solely on the management, classification, and oversight of identified vulnerabilities. For simplicity, we assume Jira is the bug tracking system in use due to its popularity.
- Identify contractual, compliance, and regulatory requirements: It is advisable to first consult with your compliance and legal teams to gather requirements from regulatory, contractual, and compliance standard perspectives and incorporate them into your program. Different compliance standards and customer contracts often have strict requirements for remediation timelines, which provide a minimal indication of risk ranking requirements and remediation deadlines.
- Identify and develop a vulnerability ranking methodology and corresponding Service Level Agreements (SLAs): Understanding how your program classifies risk levels and remediation timelines is critical. After gathering requirements from key stakeholders, refer to the Vulnerability level definitions for insights into selecting your risk prioritization methodology and reviewing sample SLAs.
- Identify bug tracking system: Determine which system (e.g., Jira) is used by the majority of engineering to track defects. This bug tracker should be used to file vulnerability tickets. It is not advised to request ops/engineering to use a different system for vulnerability tickets, as this deviates from their workflows and they are less likely to want to work with you.
- Understand how engineering queues are utilized: It is essential to understand how the core teams utilize bug tracking and issue management. Your vulnerability management program should seamlessly fit into engineering/ops workflows to streamline the process and reduce friction.
- Understand how engineering dashboards are used: Most dashboards use precise queries to ensure only the most important issues are visible. Understanding how engineering teams utilize dashboards provides insights into possible queries or query extensions you could develop and offer to ensure security issues appear on their dashboards.
- Decide how to file vulnerability tickets: Two common approaches are to
- Option 1 - Create a new issuetype: Jira supports the concept of issuetypes or sub-ticket types. Creating a custom issuetype for vulnerability ticketing enables full control of the fields and workflows.
Pros: Although it can be difficult to set up initially, it will pay dividends by enabling stable automation, reporting, and dashboarding.
Cons: It will require working with engineering leaders to ensure these issuetypes appear in their dashboards and queues; otherwise, they may be invisible. - Option 2 - Create a security checkbox: This involves creating and placing a checkbox on all ticket types labeled 'Is this a security concern?'
Pros: An advantage of this approach is that you can easily add a checkbox to all tickets that anyone can select. People outside of security, who aren't familiar with how to reach out to the team, may check this box, providing visibility into issues you'd typically never hear about.
Cons: Each ticket type will have different fields, making consistent querying for SLAs/remediation timelines difficult, building stable automation impossible, and dashboarding difficult or impossible.
Note: We advise using the issuetype approach; however, this requires more involvement to set up and may not be possible based on your available resources. If resources are very tight, you could start with a checkbox approach and migrate later.
- Option 1 - Create a new issuetype: Jira supports the concept of issuetypes or sub-ticket types. Creating a custom issuetype for vulnerability ticketing enables full control of the fields and workflows.
- Collaborate with key stakeholders to verify the workflow: Once you have mocked up your desired approach for filing/tracking vulnerabilities, it's important to sanity check this with multiple engineering managers and senior SWEs/SREs. This feedback is critical for adoption, buy-in, and ensuring your assumptions are correct.
- Create vulnerability ticketing in Jira: After determining if Option 1 or Option 2 is the right choice for you, implement it in Jira. Please see 'Vulnerability reporting requirements' for a list of specific fields to include.
- Enable new issuetype in sample project: Before adding a new issuetype company-wide, it is best to add it to a ticket type for testing (e.g., within a SECURITY project).
- Test your ticketing workflow: After implementing it, test every basic workflow including:
- Closing and reopening the issue.
- Moving into a review state, then reverting back to the to-do/queue state.
- Moving from a fixed state back to a pending fix state. This is because people may implement fixes they believe address the issue, but these fixes may be incomplete and require revisiting.
- Pilot in 1-2 engineering projects: After testing in a sample project, enable it in a small handful of production Jira project types. This will help identify any lingering bugs, use cases, or gaps in the process and oversight. This also allows you to determine Jira queries that can be used on engineering dashboards or other automation.
- Expand deployment company-wide: Decide whether to enable it for every project or only specific projects.
- Determine reporting requirements and capabilities: After reviewing the reporting requirements and metrics sections, determine what metrics and reporting you want.
- Generate reports for risk owners: A weekly or biweekly report sent to engineering leaders who have issues to address provides visibility into unaddressed risks. Please see 'vulnerability management reporting requirements' for details.
- Develop automation to identify issues: You will need automation to ensure things are working smoothly, that tickets have the correct fields, and that they aren't assigned to people who have left the company. Please see the ticket health automation section below for details.
This section will focus on two important aspects of vulnerability management, reporting, and oversight of ticket health.
Please see the vulnerability management reporting requirements for this topic.
Verifying the quality of your tickets in an automated fashion is critical to ensure that risk is properly assigned to the correct owners, classified at the appropriate level, and not lost in the process. It is recommended to build automation that queries for these common quality issues and notifies the security DRI for VM daily:
- Tickets assigned to 'unassigned': Tickets may be accidentally or intentionally assigned to 'unassigned,' and it's important to ensure these tickets are not lost.
- Tickets assigned to employee who have left the company: At some point, employees will leave the company, and tickets may remain assigned to them. It's important to flag these tickets promptly and reach out to their former manager to determine who the new owner should be.
- Tickets lacking a due date: For various reasons, this field may become blank. Each ticket should have a clear expected fix-by date for the risk owner to evaluate.
- Tickets which have had their priority downgraded: These tickets should be reviewed by the vulnerability management program owner or their delegate to determine if the decision to lower the severity/priority was appropriate.
- Due dates changed: People may attempt to change due dates to circumvent SLA oversight. It is recommended to mark this field as read-only; however, if you are unable to do so, you should monitor this field and notify the security team when the date is changed.
- Tickets which have had their priority increased: These tickets should be promptly reviewed to determine if an urgent matter, possibly requiring a security incident response, needs to be addressed. It also provides a signal on tickets which, during the transition to a higher priority, could be automatically considered out of SLA.
- Tickets which have transitioned to closed without following the proper workflow: After establishing your vulnerability ticket workflow, you will expect certain ticket states before an issue is closed. Creating automation to monitor tickets that have closed with unusual states can highlight incorrect ticket management by the risk owner or developer, as well as other issues. This will be highly dependent on how you have designed your ticket workflows.
Checklist version 1.2 copied from Sectemplates.com 2024