1972158 - Sectigo: Lack of documentation for vulnerability NVD rating adjustment

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Martijn Katerbarg]

Preliminary Incident Report

Summary

• Incident description: For two discovered vulnerabilities, requested as samples during our annual WebTrust audit, we became aware that no proper documentation was filed internally regarding the decision making process leading to the vulnerability’s NVD rating to be adjusted.

• Relevant policies: Network and Certificate System Security Requirements Version 1.7 Section 4. f. 3.

• Source of incident disclosure: Audit

Comment 1

[Martijn Katerbarg]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000016
• Incident description:

For two discovered vulnerabilities requested as samples during our annual WebTrust audit, we became aware that no proper documentation was filed internally regarding the decision making process leading to the vulnerability’s NVD rating to be adjusted.

• Timeline summary:
  • Non-compliance start date: 2024-07-01 – 11:01 UTC
  • Non-compliance identified date: 2025-06-11 - 14:22 UTC
  • Non-compliance end date: 2024-10-14 – 11:00 UTC
• Relevant policies: Network and Certificate System Security
  Requirements Version 1.7 Section 4.f.3
• Source of incident disclosure: Audit

Impact

• Total number of certificates: N/A
• Total number of "remaining valid" certificates: N/A
• Affected certificate types: N/A
• Incident heuristic: N/A
• Was issuance stopped in response to this incident, and why or why not?: N/A
• Analysis: N/A
• Additional considerations: N/A

Timeline

All times are in UTC.

• 2024-07-01:
  o 11:01:09 Vulnerability #1 is first discovered.
• 2024-07-08:
  o 11:01:09 Vulnerability #1 is officially registered as Mitigated due to a regular patching cadence of the affected servers.
• 2024-07-09:
  o 10:30 An internal ticket is filed requesting our DevOps team to patch the affected servers for vulnerability #1. Vulnerability #1 has already been patched, but this was not yet reflected in the data available to the person creating the ticket itself.
• 2024-07-12:
  o 13:15 The internal ticket is updated reflecting vulnerability #1 has been patched.
• 2024-09-09:
  o 11:00:09 Vulnerability #2 is first discovered.
• 2024-09-25:
  o 09:30 An internal ticket is filed requesting our DevOps team to patch the affected servers for vulnerability #2, amongst other patches.
• 2025-09-30:
  o 21:34 The internal ticket is updated requesting an outage of affected servers due to a pending kernel update.
• 2024-10-09:
  o 19:34 All affected servers have been restarted, completing the patching process.
• 2024-10-14:
  o 11:00:09 Vulnerability #2 is officially registered as Mitigated.
• 2025-05-28:
  o 00:54 During our annual WebTrust audit, we are requested to provide evidence of timestamped documentation showing if and when both vulnerabilities had their criticality recast.
• 2025-06-02:
  o The WebTrust auditor sends a reminder related to the evidence request.
• 2025-06-05:
  o 15:00 On our weekly WebTrust audit status update call, the lack of evidence regarding the two affected vulnerabilities is mentioned as a potential audit finding.
• 2025-06-11:
  o 14:22 We receive and internally circulate the first draft WebTrust audit reports. The draft report lists the lack of evidence for recasting the vulnerability criticality as an Other Matters audit finding. As we do not have further evidence available, we declare this as an incident.
• 2025-06-19:
  o 18:20 While all vulnerabilities have already been patched, we also recast the vulnerability within our scanning software with proper comments around the reasoning for the recast.
• 2025-06-23:
  o 12:30 During the investigation of this incident it’s raised that analysis of discovered vulnerabilities is a single person’s responsibility. This is flagged as the major contributing factor on this incident.

Related Incidents

Bug	Date	Description
1906028	2024-07-03	Both Bug 1906028 and this bug shared a common issue due to the lack of evidence around vulnerability management tracking
1955721	2024-07-03	Both Bug 1955721 and this bug shared the lack of evidence for vulnerability management tracking

Root Cause Analysis

Contributing Factor #1: Single person responsibility.

• Description:
  During the analysis of this incident, it becomes apparent that general management of vulnerability scanning, including the analysis and recasting of vulnerability ratings, has become a single person responsibility due to role changes within the team.

• Timeline: We have not identified a specific timeline for this contributing factor. Rather, this has been looming over the vulnerability management process for a long time without being properly addressed.

• Detection: This single point of failure was brought to light during the investigation of this incident.

• Interaction with other factors: N/A.

Contributing Factor #2: Procedure not properly followed.

• Description:
  Upon discovery of the vulnerabilities a decision was soon made to adjust the criticality rating of the vulnerabilities, because mitigating controls were already in place.

While this decision was made within reasonable time, it was not documented anywhere, leading to a lack of evidence during our WebTrust audit. While documenting this is part of our internal policies, the team in charge was under the impression this was a requirement only for vulnerabilities marked as critical. With the adjustment in criticality rating, the belief was that this no longer fell under the policy.

It’s our belief that the single person responsibility identified in Contributing Factor #1 can have contributed to the misunderstanding and subsequent lack in creation of a log entry.

• Timeline:
  • Based on the main incident timeline, by 2024-07-05 at 11:00 UTC the rating adjustment should have been logged for vulnerability #1.
  • Based on the main incident timeline, by 2024-09-13 at 11:00 UTC the rating adjustment should have been logged for vulnerability #2.

Neither of these events occurred, causing the current incident.

• Detection: During the investigation with responsible teams, this contributing factor was raised.
• Interaction with other factors: We believe Contributing Factor #1 may have lead to a shortcut being taken, by which standing procedure was not followed, i.e. correctly logging and describing the decision to recast both vulnerabilities.

Lessons Learned

• What went well:

  • The discovered vulnerabilities were never exploitable due to compensating controls already in place.

• What didn’t go well:

  • We did not properly document and log the decision process when the NVD criticality rating of the vulnerabilities was reassessed.
  • A critical process to us, the management and analysis of vulnerabilities had become a task for which a single person was responsible.

• Where we got lucky: N/A

• Additional: N/A

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Increase the head-count responsible for management of vulnerability scanning, analysis and follow-up.	Prevent	Contributing Factor #1	Single-person accountability and responsibility is something which should not have occurred. By sharing this responsibility amongst multiple team members, we expect this will not only prevent issues with availability, but will also increase the awareness thought process regarding the process itself.	2025-06-23	Completed
Instigate a weekly, multi-person, standing call for vulnerability scanning review.	Prevent	Contributing Factor #2	Effective immediately, we have instigated a weekly, multi-person standing call for the analysis and review of newly discovered vulnerabilities. With this weekly call, we expect to see an increase of awareness within the team itself, spark debate when there are questions or misunderstandings, and most importantly an ongoing and timely analysis and documentation of all vulnerabilities.	2025-06-23	Completed

Appendix

N/A

Comment 2

[Martijn Katerbarg]

Unless any questions or comments are posted in the next several days, we will post a Report Closure Summary by this time next week.

Comment 3

[Martijn Katerbarg]

Report Closure Summary

• Incident description:

For two discovered vulnerabilities requested as samples during our annual WebTrust audit, no proper documentation was filed internally regarding the decision making process leading to the vulnerability’s NVD rating to be adjusted.

• Incident Root Cause(s):

General management of vulnerability scanning, including the analysis and recasting of vulnerability ratings, has become a single person responsibility due to role changes within the responsible team. While a decision on adjusting the rating was made in a timely fashion, it was not documented anywhere.

• Remediation description:

We have increased the head-count responsible for management of vulnerability scanning, analysis and follow-up and instigated a weekly, multi-person, standing call for vulnerability scanning review.

• Commitment summary:

All Action Items disclosed in this report have been completed as described, and we request its closure.

In order to ensure the ongoing effectiveness of the improvements implemented by the Action Items, vulnerability management will be a focus-item for our internal audits for the foreseeable future.

Comment 4

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2025-07-15.