The goal of this document is to:
- Outline the minimum information you should require in your vulnerability tickets.
- Suggest automation for vulnerability reporting to ensure that risk owners maintain an up-to-date understanding of issues requiring their attention.
Each vulnerability ticket should contain, at minimum, the following fields:
- Subject: Accurate description of the issue versus something vague or generic that may be overlooked.
- Description of Issue: A clear description of the vulnerability and its perceived impact on the company, customers, data, and employees.
- Reproduction Instructions: This should contain everything necessary for testing the issue and should be self-contained in one ticket.
- Assignee: The person to whom the issue is assigned.
- Fix By Date: This date should be tied to the vulnerability SLA based on the issue's priority.
- Priority or Severity: This priority should align with your vulnerability ranking methodology.
These fields are not necessary for initiating a program but can be useful for generating metrics once the basics are in place.
- Vulnerability source: This field represents where a vulnerability came from. For example, a security scanner, penetration tester, customer, bug bounty, developer, security researcher, or customer. You can generate metrics against this field to determine where issues are coming from.
- Vulnerability type: This field represents classes or categories of vulnerabilities. By tracking this information, you can generate metrics and dashboards that provide visibility into systemic issues and enable strategic solutions to address them.
- Impacted assets: Some companies choose to list IPs, product names, or hostnames in their own field to enable querying.
In addition to ensuring that vulnerability tickets contain the required information, you will need to monitor the status of each issue. Generating useful reports informs the security team and risk owners about issues requiring attention. It is recommended to build automated reporting that provides weekly or bi-weekly updates to risk owners and offer support when they have questions. Below is a minimal set of information that should be communicated to risk owners and the security team.
- Issues by priority, assigned to engineering leaders: A simple list of issues under the risk owner's name, with higher priority issues at the top of the list.
- Issues by priority, assigned to engineering leaders which are out of SLA: A list of issues under the risk owner's name that are past the due date for remediation. This list should exclude items that have been risk accepted, such as those using a security exception or risk acceptance process.
- Issues by priority, assigned to engineering leaders approaching out of SLA status: A list of issues under the risk owner's name that are about to be out of SLA. Ideally this should include days remaining to highlight specific timelines.
Important Note: It is strongly recommended to gather feedback from risk owners to ensure you are including information they care about, at the frequency they want, and with the level of detail they need.
Below are additional reports that can be included in the same weekly report to engineering and security leadership. The advantage is having a single, centralized report that provides clear instructions on issues requiring each risk owner's attention.
- Security exceptions expiring: When a security exception program is in place, you can include vulnerabilities with exceptions that are about to expire in the same report. This provides visibility that issues need to be revisited.
- Security exceptions requiring approval: When a security exception program is in place, you can flag tickets requiring risk owner approval for issues they want an exception for.
Document version 1.2 copied from Sectemplates.com 2024