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: Cal.com closed its source code and consolidated pull request security after AI-accelerated attacks made open code increasingly exploitable.
Why it matters: For security and identity practitioners, the story shows how faster attack methods force tighter governance around code, authentication, and change control across human and machine-led delivery pipelines.
By the numbers:
- Cal.com had to review around 100 pull requests a day after adopting AI coding tools, up from roughly 40 per day previously.
👉 Read Gecko Security's analysis of AI-driven code review and continuous pull request security
Context
AI-assisted code review and automated scanning change the pace of software security, but they do not remove the need for governance. When code volume rises faster than security review capacity, teams get more findings, more duplication, and less confidence in what is actually exploitable. That creates a change-control problem as much as a vulnerability problem, especially when production code carries authentication and data-handling risk.
This article is really about how AI-accelerated development can overwhelm conventional application security workflows. The identity connection is indirect but real: secure delivery depends on authenticated pull request pipelines, controlled access to source code, and trustworthy automated review systems that behave like governed non-human identities inside engineering workflows.
Key questions
A: Keep pull requests small, focused, and easy to reason about. When a change mixes unrelated work, reviewers lose context, miss hidden dependencies, and spend longer validating the result. Break dependent work into stacked PRs, explain the purpose clearly, and use automation for tests and consistency checks so reviewers can focus on design, security, and correctness.
Q: Why do AI-assisted development pipelines increase the need for stronger security review?
A: AI-assisted development can accelerate code production faster than traditional review and testing processes can absorb. That creates more chances for logic bugs, insecure patterns, and vulnerable dependencies to reach production. Security teams need controls that keep pace with release velocity, especially where findings must be prioritised by exploitability rather than volume alone.
Q: What do organisations get wrong about having more scanners in the pipeline?
A: They often assume more scanners automatically mean better security. In practice, multiple tools can produce conflicting results, duplicate findings, and low-confidence noise. When teams cannot distinguish signal from clutter, review quality drops and critical issues are easier to miss.
Q: How do security teams know if their repo-scanning controls are actually working?
A: Look for two signals: untrusted repositories are always cloned into a temporary workspace, and no scanner path shells out to Git on copied inputs. If either condition is missing, the control is incomplete. A working program makes repository provenance visible before execution and separates inspection from attacker-controlled metadata.
Technical breakdown
Why AI-assisted development increases review pressure
AI coding tools raise the volume of code changes without raising the number of security reviewers in the same proportion. That changes the economics of AppSec. A team can scan more often and still miss more, because the bottleneck moves from detection to prioritisation and decision quality. In practice, security noise becomes a governance failure when developers cannot tell which findings matter, or when duplicate scanners disagree on severity and exploitability. The result is not weaker tooling alone, but a broken feedback loop between engineering speed and security assurance.
Practical implication: consolidate overlapping scanners and define one review path for release decisions.
What context-aware scanning changes in pull request security
Context-aware scanning goes beyond pattern matching by evaluating how code behaves in the application, where data flows, and whether a finding is actually exploitable in production. That matters because a raw vulnerability signature is not the same as a security decision. When a scanner can prove impact with a working proof of concept, it reduces false positives and helps small teams focus on exploitable issues instead of theoretical ones. This is especially important in fast-moving codebases where full manual validation no longer scales.
Practical implication: prioritise tools that can trace data flow and prove exploitability, not just flag matches.
How security belongs inside the engineering pipeline
When security is embedded in pull request workflows, it shifts from a separate gate to a continuous control. Findings are routed to the code owner, triage comments become reusable context, and fixes are resolved before code is widely exposed. That model works best when the process is predictable and repeatable, because consistency is what lets engineering teams trust the control. For identity and access governance teams, the lesson is similar: if a control cannot be enforced inside the workflow, it will eventually be bypassed by speed.
Practical implication: move triage and remediation ownership to the developer who changed the code.
NHI Mgmt Group analysis
AI-accelerated software delivery has created a new governance problem, not just a new tooling problem. When pull request volume rises from 40 to 100 a day, security review capacity becomes a control boundary. The issue is not only whether scanners detect more, but whether teams can convert findings into decisions fast enough to keep release governance meaningful. This is where application security, IAM for code repositories, and workflow automation intersect. Practitioners should treat review throughput as a security control, not an engineering convenience.
Context, not coverage, is the named concept that matters here. The article shows that duplicate scanners and inconsistent severities do not equal better assurance. A finding only becomes actionable when it is tied to application context, code ownership, and exploitable impact. That is analogous to identity governance failures where raw entitlement data is abundant but decision quality is low. Practitioners should optimise for contextual confidence, not scanner count.
Closed source reduced one exposure path, but it did not solve code-in-risk. The deeper lesson is that source visibility and vulnerability governance are separate problems. Hiding code may reduce opportunistic attack surface, yet teams still need continuous assurance over the software they ship. For practitioners, this means change control and secure development pipelines remain mandatory even when publication risk is removed.
AI changes the economics of attack faster than it changes the economics of defence. If adversaries can scan public code almost instantly, the defender's advantage comes from shorter decision cycles, stronger ownership, and less review friction. Security programmes that depend on slow, manual reconciliation will lose ground. Practitioners should redesign controls around decision speed and operational clarity, not static coverage goals.
For identity teams, the real intersection is governed access to code and automation. Pull request systems, scanning tools, and remediation workflows behave like non-human actors inside the software factory. If their permissions, routing, and decision boundaries are not tightly managed, they become part of the attack surface. Practitioners should extend identity governance thinking into the software delivery path.
What this signals
Context-aware security is becoming the baseline expectation for engineering programmes. Teams that still rely on raw alert volume will struggle to keep up with AI-assisted delivery, because throughput without context creates noise rather than assurance. The practical shift is toward controls that understand code ownership, data flow, and exploitability before a pull request is merged.
For identity and access programmes, the lesson is broader than AppSec. Automated review systems, build bots, and deployment workflows now act like governed non-human identities, which means access scope, approval paths, and auditability must be managed with the same discipline as privileged human access. The control plane is the pipeline.
Security teams should expect more pressure to prove that controls reduce decision time, not just detection counts. That makes metrics such as mean time to fix, false positive rates, and pre-merge closure more useful than scanner totals. The organisations that can turn findings into reliable action will keep pace with AI-accelerated development.
For practitioners
- Reduce scanner overlap in pull request pipelines Map every scanner currently running in the PR workflow, remove duplicate detections, and assign a single source of truth for release decisions. Preserve one control for static review and one for runtime validation where needed, but avoid parallel tools that generate conflicting severities.
- Route findings to code owners with exploit context Configure triage so each finding lands with the developer responsible for the change, along with data-flow context and proof of exploitability where available. This shortens remediation cycles and stops security from becoming an external queue.
- Measure time to fix, not just finding volume Track time from detection to closure for critical issues, then compare that against release cadence and pull request volume. If time to fix is rising while AI-assisted development increases throughput, assurance is falling behind delivery speed.
- Treat authenticated code access as a governed control surface Review repository permissions, bot access, and automation credentials that can modify source, trigger builds, or approve checks. Code delivery pipelines should be governed as tightly as any privileged operational environment because they now carry production risk.
Key takeaways
- AI-accelerated development can overwhelm traditional code security workflows, turning alert volume into a governance problem.
- Context, ownership, and exploitability matter more than raw scanner coverage when small teams are shipping at high speed.
- Security controls that live inside the engineering pipeline are more likely to produce timely fixes than external review gates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | PR.AC-4 aligns with controlling access in the code delivery pipeline. |
| NIST SP 800-53 Rev 5 | SI-4 | SI-4 fits continuous detection and validation of suspicious code changes. |
| CIS Controls v8 | CIS-16 , Application Software Security | Application software security is the core governance issue in PR scanning workflows. |
| MITRE ATT&CK | TA0002 , Execution; TA0006 , Credential Access | The article centres on exploiting code paths and securing software delivery. |
Map repository and automation access to PR.AC-4 and remove unnecessary write or approve permissions.
Key terms
- Context-Aware Scanning: Context-aware scanning is analysis that prioritises findings based on how code is used, where it runs, and what data it can reach. It goes beyond finding a flaw in isolation by helping teams focus remediation on code paths that materially increase business risk or exposure.
- Pull Request Security Gate: An automated control that blocks code from merging until it passes checks such as SAST, SCA, policy validation, and dependency approval. For AI-generated code, this gate matters because it shifts security review earlier, before flawed or unvetted code reaches the main branch.
- Security Noise: Security noise is the volume of low-value or poorly contextualized alerts that obscures the findings teams should act on first. In AppSec, too much noise slows remediation, frustrates developers, and can cause genuinely dangerous issues to be overlooked because attention is spread too thin.
What's in the full article
Gecko Security's full analysis covers the operational detail this post intentionally leaves for the source:
- How Cal.com tuned its pull request security workflow to reduce false positives and duplicate alerts
- The specific way Gecko traced code context to distinguish exploitable issues from noisy findings
- How findings were routed into engineering ownership so fixes happened inside the development process
- Why the team viewed predictability in remediation as a security control rather than a convenience
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps security and identity practitioners build the control discipline needed for modern delivery pipelines.
Published by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
