Impact
Three groups experienced inconsistencies in vulnerability statuses and reporting. The issue started on UTC-5 25-07-08 19:40 and was proactively discovered 14.8 hours (TTD) later by a staff member, who reported through our help desk [1] that some vulnerabilities that should have been marked as Vulnerable were not being reported to clients because their status had incorrectly changed to Submitted. This incident affected only the metadata of the vulnerabilities and the metrics of related findings, both at the database level, in API responses, and in how the information was displayed on the platform. The problem was resolved in 2.2 days (TTF), resulting in a total window of exposure of 2.9 days (WOE) [2].
Cause
The issue surfaced after a migration was executed [3]. However, complications had already been introduced earlier with the implementation of a new table in DynamoDB to store issue history [4]. To temporarily address data linkage issues, multiple sources were used to populate vulnerability history.
The historical data was migrated to the destination table [5], but due to ongoing inconsistencies, data was being saved in two places. This dual-source approach led to conflicting information and caused some vulnerabilities to display the incorrect statuses.
Solution
A corrective migration was developed and executed to locate and fix the affected records, restoring the appropriate status for the vulnerabilities [6].
Conclusion
We are moving forward with the implementation of a single, unified data source for vulnerability history. This will reduce complexity, eliminate inconsistencies, and improve the reliability of status reporting across the system. FAILED_MIGRATION < DATA_QUALITY < INCOMPLETE_PERSPECTIVE