I agree it's not really infosec, you're of course not staffed to review code yourself, or do QC yourself. However, your skills and position should be fine to address the issue at a management level. I would focus on the controls and let the CIO know you're going down this road. Keep the investigation details confidential.
How did the code pass peer review? Can they demonstrate that peer review (or your similar processes) were documented, people were trained and the processes followed? Are they regularly asking their neighbour to "+1 me!" without a culture of actually checking? Did dev have a post-mortem of the failure? Do they have suggestions or new processes to prevent this from happening again?
Did QC have an automated test? Why or why not? Did it pick up the bug? Why was it not part of their test coverage. Will be be added to their test coverage? When?
Check that the audit logs match the story of the developers and QC. If the stories don't match, ask more questions.
At the end of it all, you should have a report with recommendations and findings. The CIO can call a review meeting. I would privately ask the CIO if you want to put fear into the leadership for this "breach". If you're not careful about your documentation and curbing your language around your findings, of course your peers will hate you forever, but that's a dark side of internal investiigations in infosec.
IMHO, QC leadership should be asking these questions, but given they haven't stood up to take the issue, the CIO might not have confidence in that leadership.
All of this information should be retained as it may be useful as evidence of your dilligence in investigating a security issue in code. Review it with the CIO, clean up the excessive detail, add your remediation activities and add it to your records.