Impact
At least one user experienced issues with reattack processing. The issue started on UTC-5 25-11-21 12:39 and was reactively discovered 3 days (TTD) later by a client who reported through our help desk [1] that reattacks remained stuck in the REQUESTED state for many hours after being submitted. The problem was resolved in 4.3 hours (TTF), resulting in a total window of exposure of 3.2 days (WOE) [2].
Cause
A combination of issues led to the issue: a bug introduced in the vulnerability-reporting system prevented the reattack results produced after the SAST+SCA scan from being processed, affecting all reattacks requested; the fix for this bug was delayed for several hours because the affected namespace was unable to deploy updates or scale correctly; and a second backend issue in the cloning flow disrupted the scheduler responsible for re-queuing reattacks that had been waiting for long periods, leaving them stuck in the REQUESTED state [3],[4].
Solution
To fully restore correct behavior, the processing of static scan inputs was wrapped in a robust error-handling block that logs detailed information and notifies the workflow engine when failures occur, preventing silent interruptions, and the logic responsible for checking existing jobs was updated to include the scheduler that retries delayed reattacks, ensuring these tasks are properly recognized and processed [5],[6].
Conclusion
A processing bug, a deployment issue, and a scheduler logic flaw caused the incident. All contributing issues have now been fixed. Reattacks are once again processed reliably, and additional safeguards were added to ensure that failures in report processing and job scheduling are detected and handled safely in the future. INFRASTRUCTURE_ERROR < UNHENDLED_EXCEPTION < INCOMPLETE_PERSPECTIVE