featured articles
Software Security Needs a New Unit to Review
For the last decade, the pull request has been the moment a developer's work paused long enough for someone else to look at it. That pause is what turned the PR into a checkpoint. A reviewer read the diff and checked it for whatever could go wrong: bugs, broken business logic, security holes. Nobody designed the PR to be a security control. It became one because it was the last place in the software lifecycle where a person reliably paid attention before code shipped.
Now agentic development is breaking the math that made the diff work. PRs are getting bigger and more frequent at the same time, and the pause they run through hasn't gotten any longer. The unit of review is shifting under security's feet.
Before anyone scanned PRs, security tools ran against whole repositories, and compliance programs accepted that as review. The results were unusable: thousands of noisy findings and no way to tell which ones mattered. So the industry moved down to the diff. It was the easiest unit to work with, not the right one.
The PR is changing. Drastically.
Look at what a pull request is actually made of: a diff, a comment thread, and an approval button. None of it was ever the control. It was just tooling built for the moment someone paused to review the work. The pause survived on three conditions. PRs stayed small enough to read closely. Rare enough that every one of them got read. And the review produced a handful of issues that a developer will actually fix.
Agentic development is killing all three at once. Cursor's enterprise data shows average PR size more than doubling, with volume up another 25% on top. Mega PRs, 1,000 lines or more, are now routine. A Microsoft study of Claude Code and GitHub Copilot CLI users found adopters merging roughly 24% more PRs, hitting 50% in heavy-use weeks and holding there for four months. And bigger PRs carry more issues per review, pushing every comment thread past the point where developers stop reading it.
Any one of these would strain a review built around a careful pause. Together they take away everything it needed: time per PR, few enough PRs to give each one that time, and findings scarce enough to get fixed.
What's actually inside all those new PRs
Volume is only half the problem. The other half is what's landing inside each PR. CodeRabbit's analysis of AI-co-authored pull requests found they carry roughly 1.7 times more issues than human-only PRs, including 1.5 to 2 times more security-relevant findings like improper credential handling and insecure object references. High-issue outliers cluster in AI-assisted work. So a reviewer doesn't know which PR needed the slow read until they've already skimmed past it.
Compliance programs accept PR approvals as evidence that changes were reviewed before deployment. Today, the audit trail looks exactly like it did three years ago. What's changed is what that approval means. It used to mean someone read the code. Now, on a 1,500-line agent-written PR that arrived with six others that morning, it mostly means the person ran out of reasons to keep it open. The requirement is still being met on paper. Whether real security is happening underneath is a separate question, and no audit is built to ask it.
The unit was always a proxy
Once you see the PR as a stand-in for attention rather than a control in its own right, the question changes. Scaling review to handle more, bigger PRs is the wrong project. The real question is where that attention needs to live now that it can't all sit in one checkpoint.
Some of it belongs below the PR, where an agent makes decisions in real time and context can be applied before a diff exists. Some belongs above it, at the repository level, because a vulnerability spread across several small, reasonable PRs never shows up in any single diff. And some belongs before the PR entirely, in the architecture and design decisions that shape what an agent, or a developer, can build in the first place.
The repository level is the one that should give people pause, because the industry has been there before. Repo-wide analysis is where this story started, and it collapsed under its own findings. But that was a context problem, not a level problem. The tools flagged patterns without knowing what was reachable, what was exploitable, or what mattered to the product. Analysis that traces attack vectors and validates exploitability before it surfaces anything produces the one thing the old scanners never could: a short list. Five findings a developer will actually fix, with a risk score that is attached to a product. The comment-count condition, restored at the level the industry abandoned.
So PR reviews are dead? Right? Right?
No, PR reviews aren't dead. The pause they measured is.
Reviews stay in the program as one place security happens, not the primary one. Attention has to live where decisions live now: in the design before code exists, in the code as it's written, in the repository as it evolves. This is what we do at Prime, that's the architecture: review the design, guard the code, trace attack vectors across the repo, dependencies, and cloud continuously.
Black-Box Pentesting Gives Attackers the Advantage
For years, black-box penetration testing has relied on a simple premise: simulate an attacker who knows nothing about the system. The tester starts outside the application, discovers endpoints and functionality, infers architecture, and gradually builds an understanding of how the product works.
That assumption is outdated.
A serious attacker already has more information than the traditional black-box model assumes. Source code routinely leaves organizations through compromised insiders, contractors, repositories, legitimate access obtained under false pretenses, and AI-assisted development workflows. Source secrecy is no longer a strong foundation for offensive security.
If applications need to remain secure when an adversary understands how they work, testing needs to begin from the same vantage point. That is attacker parity.
Source code leaves through ordinary access
Source-code theft does not require a dramatic breach.
The North Korean IT worker campaign illustrates the problem. The FBI has warned that DPRK IT workers use false identities to obtain legitimate employment with U.S. companies and then use that access to steal proprietary information. In January 2025, the FBI specifically warned that workers had held stolen source code and other proprietary data for ransom.
Google Threat Intelligence has documented the same campaign at significant scale. The important security lesson is how access is obtained. An attacker hired under a false identity receives credentials, repository access, internal communications, and the same development environment as other employees. From the application's perspective, that access is legitimate.
AI-assisted development creates another path. Developers now work across coding assistants, model APIs, IDE extensions, autonomous agents, and third-party development services. When proprietary code is submitted to an external AI service, that service becomes part of the system trusted with the code. NIST's Generative AI Profile identifies data privacy, information security, third-party components, and data governance as areas organizations need to manage when deploying generative AI.
Source confidentiality is a weak assumption for an offensive security strategy.
Black-box testing assumes attacker ignorance
A black-box tester spends part of every engagement reconstructing information the engineering organization already possesses. They discover APIs, map routes, infer trust boundaries, experiment with authentication flows, and probe application behavior to understand the architecture.
That work is useful when the objective is to measure what an outsider discovers from an exposed application. It is a limited model of what a capable adversary does.
Source access changes the economics of attacking an application. Reconnaissance is faster, hypotheses are easier to form, and security controls are inspected directly instead of inferred through trial and error. Authorization logic, hidden endpoints, dependency behavior, and implementation assumptions all become easier to investigate.
The attacker spends more time searching for exploitable weaknesses while the black-box tester spends valuable engagement time rediscovering how the product works.
We already accept this model with open-source software. Security controls in an open-source application must withstand attackers who can inspect the implementation. Proprietary applications deserve the same standard.
White-box testing creates attacker parity
Defenders already possess an extraordinary amount of useful security context. They have the source code, architecture, security requirements, dependencies, deployment model, and historical design decisions.
White-box penetration testing puts that context to work.
A tester who understands the implementation moves directly into deeper questions about exploitability. They trace authorization logic across services, follow data through trust boundaries, examine how security controls are implemented, and identify places where implementation differs from design intent.
That context also makes it easier to investigate attack paths rather than isolated findings. A minor authorization weakness becomes critical when combined with a particular identity path or cloud configuration. Source code provides only part of that picture. Effective Product Security testing also needs architectural context, identity, infrastructure, dependencies, and application behavior.
A capable attacker uses whatever information they obtain. Defenders should use the information they already own.
Attacker parity must continue as the product changes
A white-box assessment still represents a point in time. The application starts changing again as soon as the engagement ends.
New code lands, dependencies change, APIs evolve, infrastructure is modified, and authorization logic gets refactored. AI coding tools and development agents have accelerated software production and increased the volume of changes security teams need to understand.
Attackers keep studying the product as it evolves. Offensive security needs the same continuity.
Continuous white-box pentesting preserves application context and repeatedly evaluates what is actually exploitable as the product changes. At Prime, that means connecting code with architecture, dependencies, cloud resources, application behavior, security decisions, and attack paths so testing starts with the context required to investigate meaningful risk.
Black-box testing still has a role
Black-box testing remains useful for understanding what an unauthenticated or opportunistic outsider discovers. It tests externally observable attack surface and exposes weaknesses in authentication, configuration, discovery, and application behavior.
It should not define the upper bound of an offensive security program.
A motivated adversary has source code, internal documentation, credentials, architecture details, or extensive time to study how the product works. Your security team already has more context than that.
Use it.
Treat source access as part of the threat model, give testers the information advantage available to defenders, and test applications from the perspective of an informed adversary.
Ready to see how Prime continuously tests applications with the same product context an informed attacker would? Learn more at primesec.ai.
Prime introduces a new operating model for Product Security
Prime Security today introduced a new operating model for Product Security, expanding its platform to help security teams participate in every product decision - from architecture and design through implementation and continuous validation.
The announcement comes as the company returns to Black Hat USA, one year after winning the conference's prestigious Startup Spotlight competition, where it will showcase the expanded platform this week in Las Vegas.
Prime's expanded platform addresses a fundamental change in how software is built. As AI accelerates engineering and compresses the distance between architecture, implementation, and deployment, security can no longer rely on reviewing finished code alone. It must participate continuously as products are designed, built, and shipped.
From day one, Prime has taken a different approach to Product Security. Rather than analyzing isolated pieces of software, the platform was built to understand products as complete systems - starting with architecture and design decisions, where critical security context is created long before code is written.
That architectural foundation now extends across the entire product lifecycle, enabling security teams to participate before the code, in the code, and after the code through a shared understanding of the product.
The expanded platform includes autonomous design reviews, AI security code reviews, AI coding guardrails, risk-focused software supply chain security, and continuous white-box pentesting - all powered by the same understanding of the product and its architecture.
Prime CEO Michael Nov said:
"Software development has fundamentally changed. Architecture, implementation, and deployment no longer happen as separate phases - they increasingly happen together, often inside the same AI-assisted workflow. Security can't keep up by reviewing software after it's built because the important decisions have already been made. Product Security has to participate as those decisions are being made. That's what Prime was built for."
Backed by Foundation Capital, Flybridge and Scale Venture Partners, Prime is trusted by organizations including PayPal, Bumble, Qualtrics, MX, and ThoughtSpot among its customers.
Customers report completing security design reviews in as little as 15 minutes, increasing security team capacity by 4-5x, and reducing false positives by up to 90% compared to traditional application security approaches.
Learn more at https://www.primesec.ai or visit https://www.primesec.ai/blackhat-2026 for Black Hat activities and event information.
Prime introduces a new operating model for Product Security
Prime Security today introduced a new operating model for Product Security, expanding its platform to help security teams participate in every product decision - from architecture and design through implementation and continuous validation.
The announcement comes as the company returns to Black Hat USA, one year after winning the conference's prestigious Startup Spotlight competition, where it will showcase the expanded platform this week in Las Vegas.
Prime's expanded platform addresses a fundamental change in how software is built. As AI accelerates engineering and compresses the distance between architecture, implementation, and deployment, security can no longer rely on reviewing finished code alone. It must participate continuously as products are designed, built, and shipped.
From day one, Prime has taken a different approach to Product Security. Rather than analyzing isolated pieces of software, the platform was built to understand products as complete systems - starting with architecture and design decisions, where critical security context is created long before code is written.
That architectural foundation now extends across the entire product lifecycle, enabling security teams to participate before the code, in the code, and after the code through a shared understanding of the product.
The expanded platform includes autonomous design reviews, AI security code reviews, AI coding guardrails, risk-focused software supply chain security, and continuous white-box pentesting - all powered by the same understanding of the product and its architecture.
Prime CEO Michael Nov said:
"Software development has fundamentally changed. Architecture, implementation, and deployment no longer happen as separate phases - they increasingly happen together, often inside the same AI-assisted workflow. Security can't keep up by reviewing software after it's built because the important decisions have already been made. Product Security has to participate as those decisions are being made. That's what Prime was built for."
Backed by Foundation Capital, Flybridge and Scale Venture Partners, Prime is trusted by organizations including PayPal, Bumble, Qualtrics, MX, and ThoughtSpot among its customers.
Customers report completing security design reviews in as little as 15 minutes, increasing security team capacity by 4-5x, and reducing false positives by up to 90% compared to traditional application security approaches.
Learn more at https://www.primesec.ai or visit https://www.primesec.ai/blackhat-2026 for Black Hat activities and event information.
Prime Security Raises $20M Series A December 2025
Prime’s new platform accelerates development with automated security reviews and full visibility into design-level risks
NEW YORK CITY and TEL AVIV – December 9, 2025 – Prime Security, creator of the first Agentic Security Architect, today announced its $20M Series A funding. The round was led by Scale Venture Partners, with participation from Foundation Capital, Flybridge Ventures, and Ofir Ehrlich, CEO & Founder of Eon. The new funding will fuel Prime’s go-to-market expansion and accelerate development of its Agentic Product Security Platform, a growing suite of autonomous AI agents that continuously monitor, assess, and guide product security throughout the entire development lifecycle.
Modern development runs at machine speed, but security still operates like an assembly line, slow, manual, and dependent on scarce expertise. Today, security teams have the capacity to manually review only a small fraction of planned work before release, leaving the rest to chance. As AI-assisted coding accelerates development velocity, this gap keeps widening. Prime’s agentic platform automates this manual craftsmanship, transforming design-stage protection into a continuous, intelligent process that scales with engineering.
"Integrating security into the design phase has always been a technically challenging manual process. Prime's unique approach transforms this critical, time-consuming stage." said Ariel Tseitlin, Partner at Scale Venture Partners. "This team are both visionaries and operators. Having led technical, GTM, and security teams at companies like PayPal and Own, and scaled enterprise Product Security programs, they've experienced firsthand the problem they're solving. This combination of category-creation vision and deep operational expertise is what defines market leaders."
Prime Security is developing a new era of Product Security, where AI agents bring security into the design stage of every software project and feature. Its flagship product, the Agentic Security Architect, autonomously conducts security design reviews and proactively identifies design flaws across development work. By embedding directly into engineering workflows, Prime enables organizations to accelerate reviews, cut manual effort and cost by more than 60%, and achieve nearly full coverage across planned development tasks.
“Modern product development is changing in front of our eyes,” said Michael Nov, Co-Founder and CEO of Prime Security. “We founded Prime to redefine how security fits into this new world, with agentic systems that operate starting at the design phase, not after development. Our mission is to build security that scales with engineering instead of slowing it down.”
After starting to commercialize the product earlier this year, Prime won the Black Hat 2025 Startup Spotlight this summer and is already working with dozens of customers including PayPal, Qualtrics, Bumble, ThoughtSpot, Redis Labs, and others with development teams of over 200 engineers who are seeing significant impact including:
- Up to 30x faster resolution of design-stage risks
- 100% of planned work receives security assessment versus 10-15% with manual reviews
- 50% reduction in time and cost spent on security reviews
“At PayPal, we know that security must evolve as fast as the threat landscape,” said Shaun Khalfan, CISO at PayPal. “Prime Security’s autonomous, design-stage reviews give us continuous and adaptive visibility across our engineering ecosystem, enabling us to identify and address risks earlier in the software development lifecycle. This capability helps us move with speed and confidence to deliver for our customers and strengthen trust in our business globally.”
By providing continuous, automated security assessment of all planned work, Prime empowers security teams to focus on strategic architecture while ensuring comprehensive coverage of every feature, enhancement, and change flowing through the development pipeline.
ABOUT PRIME SECURITY
Prime Security provides an agentic-powered platform that enables security teams to detect, prioritize, and mitigate risks at the software design phase. Founded in 2023 and headquartered in New York with offices in Tel Aviv, Prime integrates with leading engineering tools to deliver 100% coverage of development efforts without slowing engineering down. The company is SOC2 Type II certified and backed by Scale Venture Partners, Foundation Capital, Flybridge Capital Partners and PayPal Ventures. For more information, visit the website.
Media Contact:
Morgan Grandi
morgan@primesec.ai
Prime Security Is Now GA
Today, we’re announcing that Prime Security is officially Generally Available, the first AI Security Architect built to bring security into the design stage of every software project, without slowing development. Development velocity has gone through the roof (thanks, AI), but design-stage security reviews stayed manual, slow, and dependent on a handful of experts. Prime closes that gap.
Prime automates the entire design-review process: discovering design-stage risks across all planned development work, interpreting tasks and documents with full business context, and generating complete security reviews, risks, mitigations, data flows, and compliance ties, in minutes. It operates directly inside engineering workflows, giving teams near-total coverage without forms, questionnaires, or chasing down developers.
With GA, Prime is enterprise-ready: automated reviews for Jira, Confluence, PRDs, and AI-generated plans; risk identification and prioritization; mitigation recommendations aligned to frameworks like NIST, CIS, PCI, and HITRUST; and a self-serve Security Architect chat experience for engineers. Teams at Qualtrics, Yext, ThoughtSpot, and others are already using Prime to accelerate secure development at scale.
Security can’t rely on manual architecture work in an AI-accelerated world. GA is the next step toward Agentic Product Security, where autonomous AI agents continuously monitor, assess, and guide design-stage security. Prime is now ready for every team that needs to secure modern development without slowing it down.
Security Design Reviews vs. Threat Modeling (April 2026)
The Nuances of Design Stage Security
If you work in cybersecurity (or security adjacent) you are very familiar with the 2 main practices that help to identify and remediate security concerns before development starts; Threat modeling and Security Design Reviews. Both are practical capabilities, and while threat modeling has a variety of frameworks, design reviews are more of a delicate and tactical process that heavily relies on an intimate knowledge of the business. But have you ever felt like your security reviews are missing the mark? Maybe they’re too generic or don’t account for the unique risks your business faces. The challenge often lies in capturing that elusive business context. While threat modeling is a powerful tool, it often happens to be a hammer, and so reluctantly security has to see every design problem as a nail. This makes threat modeling a default approach even when a more nuanced method, like targeted security reviews, would be more effective. By harnessing Large Language Models (LLMs) to sift through unstructured data, we can finally bring the vital context needed to scale security reviews across the board and provide a supercharged version of this method to security practitioners.
Context: The Critical Factor
Traditional security checks often fall short because they can’t adapt to the specific nuances of your business, and threat modeling alone can’t address all the intricacies of secure development. This is where LLMs come into play. By leveraging new LLM empowered capabilities early in the design stage of the SDLC, we can enhance security reviews with deeper context and precision, making them more effective and efficient. This approach allows you to weave security into your systems right from the start, rather than relying on exhaustive modeling for every scenario.
Providing developers with business-driven, concrete security requirements upfront reduces friction and ensures the right tools are used at the right time. By leveraging security reviews at scale for ongoing, contextual feedback, development teams know exactly what’s expected before writing a single line of code, minimizing rework and keeping projects on track. It substantially reduces the dependency on sometimes very cumbersome threat modeling processes that can be an overkill for the task at hand.
Prime Security: Embedding Security before Development starts
At Prime, we focus on security design reviews because we know they’re the most practical and proactive way to secure products from the ground up. By providing the infrastructure to capture and integrate business context, Prime ensures that your security reviews are tailored to the specific needs of your organization. The result? A product that’s secure by design, allowing your teams to move fast without sacrificing security.
Building Prime Security
As security professionals and technical leaders we’ve experienced the main pain in developing products. The constant struggle of balancing development velocity with security needs. Through it all, one thing became clear, many security challenges could be prevented given the right context at the design phase of the SDLC. Too often, security comes in at the last minute, scrambling to apply fixes after development is complete, leaving both teams frustrated and out of sync.
Sure, security exists in the SDLC today, but it starts to scale when code is written. You can scan for dependencies, catch bugs, and identify vulnerabilities. But Product Security shouldn’t start with code scanning; it needs to start with design. It’s not just about applying processes or enforcing policies; it’s about influencing decisions before a single line of code is written. Security teams need actionable insight into what’s being built and why, from the earliest stages. But extracting that insight is challenging, scaling it across fast-paced teams is even harder, and making it stick while everyone’s sprinting to meet deadlines can feel nearly impossible.
That’s why we built Prime Security. To truly integrate security into modern development, it has to start at the design phase, not after. We’re not here to slow development down; we’re here to give security engineering teams superpowers so they can support developers to make smarter decisions, faster - embedding security directly into their workflows.
With our unique business and security context extraction engine, Prime Security automates risk assessments and generates tailored mitigation recommendations, ensuring that security isn’t just an afterthought, but a partner in the development process. Prime brings hard-won insights from security professionals right to the point where they’re needed most. This isn’t about adding friction; it’s about unlocking development velocity without compromising on security.
This is the future of Product Security: practical, scalable, and context-driven decisions, integrated from day one. With Prime, security and development teams can truly build securely from the start, setting a new standard for scalable, design-first security. We’ve lived through these challenges, and we’re here to solve them, for good.
Michael, Dimitry, Danny, Matan
