TL;DR: AI-driven attacks are compressing vulnerability discovery cycles, pushing Cal.com to close its source code and rely on continuous, context-aware pull request security rather than layered scanners, according to Gecko Security. The practical lesson is that engineering speed and security governance now depend on reducing noise, improving code context, and making triage part of the development workflow.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Gecko Security's blog post: AI-accelerated attacks and noisy scanner output pushed Cal.com toward closed source and pull-request-centric security governance.
Why it matters: IAM and security teams should read this as a governance signal: security decisions are shifting from point-in-time scanning to continuous, code-context-aware controls embedded in delivery workflows.
By the numbers:
- Cal.com said pull request volume climbed from around 40 a day to 100 as it adopted AI coding tools.
Context
AI-accelerated code review changes the economics of software security because attackers and defenders can now analyse code faster, with less human effort, than older review models assumed. When code changes move quickly, governance based on periodic scanning, duplicated findings, and manual reconciliation loses reliability, especially for teams that must decide whether a change is safe to ship.
Cal.com’s experience shows how this pressure reaches identity-adjacent governance as well, because code paths now control authentication, data handling, and access to sensitive customer information. When development speed increases and security staff remain small, the issue is not just vulnerability volume but whether review, ownership, and triage happen close enough to the pull request to matter.
Key questions
Q: What breaks when teams rely on manual security review after AI-assisted code changes?
A: Manual review becomes the bottleneck, especially when agents produce multiple iterations in a short time. Findings can sit unverified while code keeps moving, which weakens confidence in the release. Without automated rescans and consistent triage, teams struggle to prove that a fix actually removed the vulnerable behaviour.
Q: Why do multiple scanners often create worse security governance?
A: Multiple scanners often create conflicting severity scores, duplicate alerts, and more triage work than a small team can reliably absorb. That weakens governance because the team spends time reconciling tools instead of fixing exploitable issues. A single, context-aware decision process is usually more effective than several overlapping sources of partial truth.
Q: How should teams handle security findings in the pull request workflow?
A: Teams should route findings to the code owner, keep reviewer context attached to the change, and make fix decisions before merge. That approach turns review into a real control rather than a notification system. The goal is not perfect detection, but predictable closure of issues before code reaches production.
Q: How do security teams balance faster developer feedback with stronger code security controls?
A: Security teams balance speed and control by making analysis fast enough to fit normal development flow while keeping the findings accurate and actionable. That means prioritising low-friction checks in the IDE and pipeline, focusing on high-signal issues, and using policy to guide escalation. The best programmes reduce wait time without reducing governance.
Technical breakdown
Why AI-accelerated code review changes the threat model
AI-assisted code analysis lowers the effort needed to find weaknesses in public or rapidly changing code, which compresses the attacker’s discovery window. That shifts the defensive problem from finding every issue eventually to identifying exploitable issues fast enough to prevent release. In practice, security teams are no longer only competing with human reviewers or scheduled scans. They are competing with software that can mine code, compare patterns, and surface likely weaknesses continuously at machine speed.
Practical implication: treat review latency and false-positive noise as security risks, not just engineering inconveniences.
Why multiple scanners often reduce governance quality
Running several scanners can increase coverage on paper, but it can also produce duplicated findings, conflicting severity ratings, and too many alerts to reconcile. That weakens the control because the real question is not how many tools found something, but whether teams can decide what is exploitable and worth fixing. Context matters more than raw signal count, especially when code paths affect authentication, customer data, or release readiness.
Practical implication: consolidate findings into a single adjudication process that can rank risk by code context, not by scanner count.
Pull request review as a security control, not a developer checkpoint
A pull request review pipeline becomes a governance control when it routes findings to the code owner, preserves reviewer context, and forces security questions to be answered before merge. That is materially different from post-hoc scanning or ticket-based remediation. The mechanism is continuous decision-making at the point of change, which is where software risk is actually introduced. For small security teams, this also creates a memory of prior triage decisions that improves future reviews.
Practical implication: move triage and ownership into the pull request workflow so fixes happen before code reaches production.
Threat narrative
Attacker objective: The attacker objective is to find and exploit software flaws quickly enough to reach sensitive code paths before defenders can triage and fix them.
- Entry begins with AI-driven analysis of public code and pull requests, which collapses the time needed to spot weaknesses in exposed repositories.
- Escalation happens when noisy, overlapping scanners fail to separate exploitable issues from false positives, leaving real flaws unresolved in the delivery pipeline.
- Impact is a higher likelihood that vulnerable code reaches production in systems handling sensitive customer data and authentication logic.
Breaches seen in the wild
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI-assisted review is forcing security governance to move from detection volume to decision quality. The article shows that more scanners did not produce better security because the bottleneck became adjudication, not discovery. For identity and software governance teams, the lesson is that a control only works if it can still make a clear merge decision under high change velocity.
Context-aware review is becoming the decisive control for code that shapes access and data handling. When authentication logic and customer data processing sit inside the delivery pipeline, generic findings are not enough. Security teams need mechanisms that understand code path, ownership, and business impact, because that is what turns a finding into an actionable governance decision.
Software security is absorbing a pull-request-era governance model that looks increasingly like continuous assurance. Cal.com’s workflow shows the direction of travel: findings are routed, triaged, remembered, and resolved inside engineering rather than handed off later. That reduces the gap between discovery and fix, which is now the core control objective.
AI-accelerated code review is creating a new operational burden for small security teams. The article makes clear that a two-person security function cannot keep up if every tool produces a separate truth. The practical implication is to design security around fewer, higher-fidelity decisions, not around accumulating more alerts.
What this signals
Context-aware review is becoming the governance layer that matters most. When AI tools increase the pace of code creation, security teams need controls that understand how code behaves, not just whether a rule was triggered. The practical change is a move away from alert accumulation and toward merge-time decision quality.
Small security teams will increasingly win by designing for predictability. The article shows that a repeatable pull request process, not a larger scanner stack, is what makes remediation sustainable. That is the governance shift practitioners should plan for across application security and identity-adjacent code paths.
For practitioners
- Consolidate pull request findings into one decision point Route scanner output, code-context review, and developer ownership through a single workflow so teams can decide what is safe to merge without reconciling multiple truth sources.
- Prioritise exploitable findings over raw severity counts Use code path, data sensitivity, and execution context to rank findings so reviewers focus on issues that can actually reach production impact.
- Embed security triage inside the engineering process Store reviewer decisions, route fixes to the code owner, and keep resolution tied to the pull request rather than to a separate backlog.
- Tune review rules to your codebase Adjust suppression logic, context requirements, and ownership mapping so the pipeline reflects how your engineering team actually ships code.
Key takeaways
- AI-accelerated code review changes the security problem from finding more issues to deciding faster which issues are real and exploitable.
- For small teams, duplicate findings and conflicting severities become a governance failure because they slow closure instead of reducing risk.
- The practical response is to embed high-confidence review, ownership, and remediation inside the pull request workflow before code reaches production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, OWASP ASVS and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | The article focuses on securing code changes and review workflows before release. |
| Recommendation — Apply CIS-16 to embed security checks into the pull request and release process. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Code review governance affects who can change code paths that control access and data handling. |
| Recommendation — Use PR.AA-05 to enforce code-owner approval on changes affecting access logic and sensitive data flows. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The article concerns how security review catches flaws in application logic before deployment. |
| Recommendation — Use V15 to validate that secure coding review is built into the delivery workflow. | ||
| OWASP SAMM | Security Testing — Security Testing | The piece describes security testing as a continuous practice inside engineering, not a one-off scan. |
| Recommendation — Measure and improve security testing maturity so findings are actionable within the development lifecycle. | ||
Key terms
- Context-Aware Code Review: Context-aware code review is an analysis approach that checks code against business intent, identity boundaries, and workflow expectations, not just technical syntax. It is used to find issues that require reasoning about how an application is supposed to behave, especially in regulated or high-risk systems.
- Pull request security pipeline: A security control model that embeds scanning, triage, ownership, and remediation into the pull request workflow. Instead of treating review as a separate after-the-fact activity, it makes code approval the control point where risk is identified and resolved before release.
- Scanner noise: The volume of duplicate, low-confidence, or contradictory findings that reduces trust in security tooling. When scanner noise is high, teams spend more time reconciling alerts than fixing issues, and the result is slower remediation with weaker governance over real risk.
- Decision Quality: The extent to which a review outcome reflects the actual business need, usage evidence, and risk level of the entitlement being assessed. For identity governance, decision quality matters more than campaign completion because it determines whether excess privilege is removed, downgraded, or left in place.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, machine identity security, and secrets management. It is built for practitioners who need to connect identity controls to modern delivery and security workflows.
Published by the NHIMG editorial team on August 28, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org