Estoy de acuerdo en que no es realmente infosec, por supuesto, no tiene personal para revisar el código usted mismo o hacer el CC. Sin embargo, sus habilidades y posición deben estar bien para abordar el problema a nivel de gestión. Me concentraría en los controles y le diría al CIO que está por este camino. Mantener la confidencialidad de los detalles de la investigación.
¿Cómo pasó el código a la revisión por pares? ¿Pueden demostrar que se documentó la revisión por pares (o sus procesos similares), se capacitó a las personas y se siguieron los procesos? ¿Están pidiendo regularmente a su vecino "+1 yo!" ¿Sin una cultura de comprobación real? ¿Dev tenía una autopsia de la falla? ¿Tienen sugerencias o nuevos procesos para evitar que esto vuelva a suceder?
¿QC tuvo una prueba automatizada? ¿Por qué o por qué no? ¿Recogió el error? ¿Por qué no fue parte de su cobertura de prueba? ¿Se añadirán a su cobertura de prueba? Cuando?
Verifique que los registros de auditoría coincidan con la historia de los desarrolladores y el control de calidad. Si las historias no coinciden, haga más preguntas.
Al final de todo, debe tener un informe con recomendaciones y conclusiones. El CIO puede convocar una reunión de revisión. Le preguntaría en privado al CIO si quiere poner miedo en el liderazgo por esta "brecha". Si no tiene cuidado con su documentación y restringe su lenguaje en torno a sus hallazgos, por supuesto, sus compañeros lo odiarán para siempre, pero ese es el lado oscuro de las investigaciones internas en infosec.
En mi humilde opinión, el liderazgo de control de calidad debería estar haciendo estas preguntas, pero dado que no se han puesto de pie para abordar el problema, es posible que el CIO no confíe en ese liderazgo.
Toda esta información debe conservarse, ya que puede ser útil como evidencia de su diligencia en la investigación de un problema de seguridad en el código. Revíselo con el CIO, limpie los detalles excesivos, agregue sus actividades de remediación y agréguelo a sus registros.