In early 2024, the open-source world came very close to a disaster nobody saw coming. A backdoor was found hiding inside xz Utils, a compression library that ships with most Linux systems. It was not slipped in by an outsider. It was built up over months, by a contributor the project had learned to trust. An engineer noticed it only because SSH logins felt a fraction slower than usual.
The uncomfortable part is that the harmful changes survived the project’s existing development and release controls until Andres Freund noticed an unexpected performance anomaly.
Most engineering teams already review code – pull requests get approved, scanners run in the pipeline. But malicious code sometimes still reaches production, and attackers still find it first.
The reasons are not purely technical. They sit in how reviews are scoped, staffed and prioritised. This blog breaks down the secure code review challenges teams run into today, why they have become sharper in 2026 and what a workable fix looks like for Indian firms under SEBI, RBI, CERT-In and DPDP obligations.
What is secure code review?
Secure code review is a structured check of source code to find security flaws before software goes live. A normal review asks whether the code works. A security review asks how the code could be abused.
A mature secure code review process blends two layers. Automated tools such as SAST, software composition analysis and secrets scanning give breadth. Manual review by someone who thinks like an attacker gives judgement. Most failures start when one layer is expected to do the work of both.
Why review has fallen behind the risk
Three shifts have changed the maths for review teams over the last two years.
- More code, less authorship: The 2025 DORA State of AI-assisted Software Development report from Google Cloud found that around 90 percent of technology professionals now use AI at work, while about 30 percent have little or no trust in the code it produces. Reviewers are increasingly checking more code produced with AI assistance, sometimes without the same level of understanding of its intent.
- Risk has moved into dependencies: The OWASP Top 10:2025 introduced Software Supply Chain Failures as a new category at number three. OWASP also flagged misplaced trust in AI generated code as a risk to watch.
- Attackers move faster than fix cycles: CERT-In’s blueprint on AI-assisted exploitation warns that AI tooling is compressing the gap between a weakness appearing and an exploit landing. It expects known exploited flaws on internet-facing systems to be closed within hours, not sprint cycles.
Five code review challenges that slow teams down
These are the friction points that show up again and again in real engineering environments.
- Reviewer bandwidth: Security expertise is scarce. One or two application security engineers cannot read every pull request across a large product team, so reviews get thin exactly when release pressure is highest.
- False positive fatigue: When a scan returns hundreds of findings with limited context, developers learn to dismiss the list. Real issues get buried under noise that nobody has time to triage.
- Business logic blind spots: Tools match patterns. They rarely catch a broken authorisation check in a loan approval flow or a refund path that can be replayed. Broken access control remains the number one risk in the OWASP Top 10:2025, and it is largely a logic problem.
- Code without an author: AI-generated snippets, borrowed Stack Overflow fixes and inherited legacy modules all arrive without anyone who can explain the intent behind them. Review turns into archaeology.
- Review treated as a release gate: A security check bolted on at the end of a sprint gets rushed by design. Findings then compete with launch dates, and launch dates usually win.
What Indian regulators now expect
For BFSI and regulated firms, code quality has become an audit item rather than an engineering preference.
- SEBI CSCRF requires regulated entities to run security testing after every major release, which pushes review into the delivery cycle instead of the annual audit window
- RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices, effective April 2024, expects secure-by-design development and independent assurance over IT controls
- DPDP Act 2023 carry penalties of up to Rs 250 crore for failure to maintain reasonable security safeguards, while the DPDP Rules, 2025 establish the operational framework for implementing the regime.
- CERT-In empanelment is now the practical benchmark Indian auditors look for when validating who performed the assessment
Under CERT-In’s six-hour reporting rule, a flaw missed in review can become a filing obligation the same day it is exploited.
How to close the gaps
A workable secure code review process does not need a bigger security team but a better shaped one.
- Tier your reviews by risk: Let automation handle high-volume pattern checks. Reserve expert time for authentication, payments, data access and anything touching personal data.
- Tune before you scale: A smaller, tuned ruleset that developers trust beats an exhaustive one they ignore.
- Treat AI output as third-party code: Review it with the same scepticism applied to an unknown open-source package, and track what came from where.
- Shift review left, not just testing: Threat model at design stage so reviewers know which paths matter before the pull request lands.
- Keep evidence: Auditors ask what was reviewed, by whom and what changed. A source code review with no trail is hard to defend.
Conclusion
Reviews usually because volumes of data grew, code ownership blurred and the clock got shorter. Fixing that means matching review depth to real risk, cutting the noise developers are asked to wade through and keeping evidence that stands up in an audit.
CyberNX is a CERT-In empanelled auditor, and our team combines manual and automated analysis to find the flaws that scanners alone miss. If your teams are struggling with secure code review challenges across a fast-moving release cycle, talk to our experts and get a clear view of where your code stands.
Secure code review challenges FAQs
What makes secure code review so difficult today?
Limited reviewer bandwidth, noisy scanner output, business logic flaws that tools cannot detect, unreviewed AI-generated code and reviews squeezed in at release time. Most of these are process gaps rather than tooling gaps.
How often should secure code review be performed
Review high-risk code with every significant change, and schedule a deeper expert-led review before major releases. SEBI-regulated entities must also test after every major release to stay aligned with CSCRF expectations.
Can automated tools replace manual source code review?
No. Automated tools are strong at known patterns such as injection flaws, weak cryptography and vulnerable dependencies. They struggle with authorisation logic, business flow abuse and context-specific design errors, which is where manual review earns its place.
How should teams review AI-generated code
Treat it like code from an unknown third party. Ask the developer to explain what each block does, check any dependencies the tool pulled in and look closely at authentication, access control and data handling paths.
