Notifications
Clear all
Topic starter
28/08/2026 12:04 pm
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.
NHIMG editorial — based on content published by Gecko Security: AI-driven attacks, closed source, and continuous pull request security at Cal.com
Questions worth separating out
A: Keep pull requests small, focused, and easy to reason about.
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.
Q: What do organisations get wrong about having more scanners in the pipeline?
A: They often assume more scanners automatically mean better security.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Gecko Security's analysis of AI-driven code review and continuous pull request security →
AI-accelerated code review: what it means for security teams?
Explore further
28/08/2026 12:04 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI-accelerated code review is reshaping software security governance
