News
featured articles
Product Security in the AI-Native SDLC: Dealing with the Necessary Evil
Ask any product security leader what's wrong with their application security testing and you'll hear the same answer: too many false positives. Look closely at those findings, though, and a different picture emerges: the findings themselves are technically true, but their actual impact, severity, or relevance is largely false. The tools found exactly what they were built to find: real vulnerabilities in code, infrastructure and design.
What the team couldn't do was “simply” fix them. The session timeout is longer than policy because an assisted-banking journey needs it. The amount field accepts negative values because reversals post that way. The upload endpoint accepts several file types because new customers must upload scanned identity documents to open an account. Each finding got marked accepted, exempt, approved, business-justified or waived. And because nobody was going to fix it, it got filed as a false positive.
Those findings aren't false positives. They're benign positives, the necessary evil every real product carries. In an AI-native SDLC, agents write and fix more of the code every month, and agentic security testing (AST) feeds findings straight back to them. That makes the difference impossible to ignore.
False positive vs. benign positive: correct detection, wrong label
So what is a benign positive? Microsoft implemented this in their ops flow already. Essentially, when an analyst closes an incident in Microsoft Sentinel, one of the classifications on offer is Benign Positive: the detection worked, and the activity turned out to be expected. Product security hasn’t borrowed the term, yet. This means we are still stuck with only 2 main bins:
- A false positive means the detection was wrong. The risk the rule protects against doesn't exist in this context, like a missing anti-forgery (CSRF) token on an API that doesn't use browser cookies, so that attack can't happen there.
- A true positive means the detection was right and the behavior is a defect.
A benign positive sits between them. The detection was right, the risk is real, and the business needs the behavior anyway. The test fits in two sentences. If the risk doesn't exist here, it's a false positive. If the risk exists but the business needs the behavior, it's a benign positive.
What gets lost when everything is a false positive
Filing a benign positive as a false positive feels harmless. The finding wasn't going to be fixed either way. But the label does three kinds of damage:
- The risk disappears. A false positive has no owner, no expiry date and no compensating control, because on paper there's nothing to compensate for. The long session is still open on the assisted-banking route, and nothing in the backlog says so anymore.
- The tool gets blamed for being right. Take a scanner that correctly flags 1,000 gaps, 800 of which the business keeps on purpose. It gets reported as 80% noise, as if only 20% of its findings were real. Teams learn to tune out correct detections, and the findings that genuinely need fixing have to fight through that skepticism. We covered what that does to developers in the Cutting Through ProdSec Noise blog.
- Someone eventually fixes one anyway. A new engineer, an audit push or a cleanup sprint closes the "easy" finding. The timeout drops to 15 minutes and older customers get logged out mid-transfer. The reversal endpoint starts rejecting negative amounts. Security loses credibility with the product team over a finding that was never a bug.
Why the AI-native SDLC makes benign positives impossible to ignore
Benign positives used to be a reporting problem. AI agents turn them into an engineering problem, and a far more visible one.
Route findings from agentic security testing straight back to a fix agent and it does what it was built to do: make the rule stop firing. It can't tell a benign positive from a defect, because the reason the behavior exists isn't in the code. So it either "fixes" the behavior and breaks a business flow, or a human rejects the change and the same finding returns on the next scan and the next pull request. Neither outcome looks like security working.
The same failure now happens before any finding exists. In vibe coding, security requirements reach the coding agent as instructions, and agents follow policy literally. Tell an agent that sessions expire after 15 minutes and it will apply that everywhere, including the one journey where the business approved 60. A rule a human would have applied with judgment now ships exactly as written, in every repository the agent touches.
How context-aware product security handles benign positives
A better label is only the start. What's missing is the context to decide what a correct finding should become. That context exists, but it's scattered.
It lives in design documents, product requirements and Jira tickets. It lives in the user flows and customer journeys the application supports, and in the business analysis behind them. It lives in security requirements, partner specifications, related source code in other services, and the memory of a few senior engineers. Only something that reads all of it can recognize a benign positive.
That's the approach we're taking at Prime. Before a correct finding turns into a ticket, Prime checks the finding against the code, the infrastructure, the user journeys and the business documents around it, using five questions. Was the deviation deliberate? Does a real business flow depend on it? Would the standard fix break current business logic? Is the deviation as narrow as the need? What limits the risk today?
The answers lead to one of four outcomes:
- Fix when the gap is a defect. An AI agent can do it only if the fix leaves business behavior unchanged.
- Narrow when the business needs the behavior in one place but it leaked everywhere. Keep it where it's needed and fix the rest.
- Compensate when the deviation can't shrink further. That means a scoped exception with an owner and an expiry, plus controls around it.
- Ask when the evidence doesn't settle it. One question goes to the product owner, in product terms, and the answer is reused.
Two rules sit underneath. First, benign positives go to the person who can decide what the product should do, usually a product or business owner, never straight to a fix agent.
Second, when a preventive control can't be put in place, fixed or narrowed, detective and corrective controls take over its job by design. Take the long session. If it can't be shortened, nothing stops an unattended session from being misused, so the goal becomes catching misuse fast. An alert fires when a transfer follows a long idle period, and the transfer is held until the customer confirms it. Detection and a quick response stand in for the block that couldn't be built.
None negotiable, or must-have list of controls, like encrypting card data and authenticating money movement, never gets an exception at all.
Five findings, five decisions
Let’s take a look at a few examples taken from an imaginary fintech. The first two come from cloud and data scanners, because benign positives aren't limited to code; the other three come from code.
The admin role the CNAPP flagged. A CNAPP tool correctly flags an IAM role with administrator rights that hasn't been used in months, and its standard fix is to remove it. Prime checks it against the approved design: it's the documented break-glass role for disaster recovery, owned by the platform team, so it's a benign positive, and removing it would leave no way in during an outage.
The public bucket the DSPM tool flagged. A DSPM tool correctly finds personal data in a public storage bucket but can't tell why it's there. Prime adds the context: if the business requires it by design, with the product manager who owns it, it's a benign positive; if not, it's a drift from the design to fix.
The 60-minute session. The standard says 15 minutes. The assisted-banking journey, where an older customer completes a transfer with a caregiver, needs longer. Prime narrows the deviation to that journey and keeps 15 minutes everywhere else. Around it go step-up authentication on transfers and new payees, a hard limit on total session length, and an alert when a sensitive action follows a long idle period.
The free-text field that can't be validated. Strict input validation would allowlist what a dispute note or payment memo may contain. But customers and investigators paste multilingual text, copied emails and evidence, so no allowlist fits. Prime compensates: limits on length and allowed characters stay, while the real protection moves to where the data is used. Queries are parameterized and output is encoded for its context. A content security policy backs that up, and injection patterns in those fields raise an alert.
The upload that accepts more than one file type. The scanner flags an endpoint that takes PDF, JPEG and TIFF files. New customers need all three to upload the identity documents required to open an account. Prime narrows the rule instead of dropping it: exactly those three types, checked by content rather than file extension. Uploads are virus-scanned, size-capped, stored outside the web root and re-rendered before anyone opens them.
What this means for product security leaders
Start with the pile you already have. Pull last quarter's false positives and sort them with the two-sentence test. If a large share turns out to be benign positives, two things are true at once. Your tools aren't as noisy as your metrics say, and your accepted risk is larger than your risk register says.
Then separate the two questions every finding raises. Whether a detection is correct is one field. What to do about it is another. Measure your tools on the first and run your program on the second.
Finally, keep benign positives away from automation until someone with authority has decided. An AI fix agent is a great tool for a missing parameterized query. It's the wrong tool for a behavior someone in the business chose on purpose. And whatever your coding agents are told to enforce should carry its exceptions with it.
From dismissal to decision
Calling a correct finding a false positive was always a shortcut. In an AI-native SDLC, where agents write and fix code at scale, it's a shortcut that breaks things. The detection was right. What was missing was the context to decide what the finding should become, and who should decide it.
At Prime, that context runs from the design before the code, through the code as it's written, to the system after it ships. It's what lets a benign positive become a scoped, owned decision instead of a quiet dismissal.
Ready to find out how many of your "false positives" are really benign positives? Learn more at primesec.ai.
Why Is There a Giant Inflatable Zeus Riding a Cybertruck in San Francisco?
Superman cape. Greek mythology. Tesla Cybertruck. OWASP Global AppSec 2026. We have some explaining to do.
First, we'd like to confirm that you did, in fact, see a giant inflatable Greek god riding a Tesla Cybertruck through San Francisco.
Yes, that's Zeus. The Greek god of thunder. Currently experiencing something of an identity crisis, judging by the Superman cape.
No, it's not a movie promotion. No, Tesla didn't suddenly discover Greek mythology. And no, Superman hasn't traded the Fortress of Solitude for Mount Olympus.
It's Prime Security.
We're at OWASP Global AppSec 2026, and apparently bringing another retractable banner wasn't going to cut it.
Now that we have your attention, let's talk about something considerably more absurd than a Greek god dressed as a superhero riding a Cybertruck: the way we're still securing software in the age of AI.
The gods have changed. The rules haven't.
AI agents are writing code, choosing dependencies, shaping architectures, and connecting systems at speeds that would have been unimaginable just a few years ago.
Meanwhile, much of Product Security is still operating on the assumption that humans write code, security tools scan it, and other humans sort through the findings.
More code. More scans. More alerts. More dashboards.
More of everything except actual understanding.
At Prime Security, we're building for a different reality. One where security understands the architecture, guides decisions before code is written, reviews code as it's created, and continuously validates what's actually exploitable.
Before the code. In the code. After the code.
So why Zeus? And why the Superman cape?
Greek mythology is full of powerful gods making terrible decisions with spectacular consequences.
Surprisingly relevant to modern software.
But we're not going to pretend a giant inflatable Greek god on a Cybertruck is some profound metaphor for our technology.
Sometimes you do something outrageous because you want people to look.
And once they're looking, you better have something worth saying.
Here's ours:
AI has changed who builds software. It's time to change who secures it.
Zeus may have an identity crisis. Product Security doesn't have that luxury.
Think you can handle the gods? Play the game.
The Vulnerabilities You Will Never Fix
Security teams tolerated noisy scanners for twenty years. False positive rates that would get a tool thrown out of any other engineering discipline became routine in AppSec, and everyone made peace with it, because a human could always work the queue. Slowly. Painfully. But the queue got worked.
That peace is ending, and I hear it in every conversation with a security leader. Their scanners didn't get worse. The code got faster.
The number of vulnerabilities never mattered
False positive rate is easy to measure, so it became the number vendors compete on. Run a bake-off, count the bad findings, pick a winner.
Except nobody tolerated the rate because it was fine. They tolerated it because a human could still clear the queue. That was the only number that ever mattered: not how many findings a SAST scanner produced, but whether the team could get to the end of them. That worked at 100 PRs a week. Put the same scanner on 300 PRs and the same rate buries the team, while the number on the vendor's slide hasn't changed at all.
To be clear, finding vulnerabilities is good. The problem is what the scanner calls a vulnerability. A SQL injection pattern in a function nobody can reach is not a vulnerability, it's a bug. Software is full of bugs. Any codebase of real size has thousands of them nobody will ever fix, and nobody loses sleep over that. The scanner takes a few hundred of those bugs, labels them critical, and puts them in a queue your team is now accountable for.
Email security went through this already (to be fair, it’s going through this again now). Keyword spam filters flagged "free" and "win," caught plenty of real mail, and nobody cared while inboxes were small. Then volume exploded, the same error rate produced an unrecoverable pile of mistakes, and keyword matching died. Bayesian filtering replaced it. SAST ran the identical arc: untuned tools shipped false positive rates above 90 percent, teams hired humans to triage, and the arrangement held for one reason only. Code volume stayed inside what humans could process.
We have more code now.
Cursor says enterprise customers are pushing 25 percent more PRs and the PRs are twice as big. Microsoft says engineers with coding agents merge 24 percent more per day. I don't need the studies. I sit with product security leaders every week and the number they give me is their own: double, sometimes triple, in under a year, with the same three people on the AppSec team.
So teams are trying to solve it.
The first move is always headcount or another tool. I've watched it a dozen times and I've never seen it close the gap, because you get one more person and the engineering org gets Cursor.
The scanner they bought in 2021 is still running. Accuracy is improving with AI overlays, just not fast enough, so a lot of ProdSec teams default to building something homegrown that "cleans up" or "validates" scanner output. They are now paying twice. Once for the scanner, and again in tokens to make its results usable.
And the results are the same. The scanner still has no idea whether the thing it flagged can be reached. Cleaning the queue faster just gets you to the bottom of the same queue, and the real one you were worried about is still somewhere in it.
So what matters today? Attacks.
Once the queue is the constraint, what's in it matters more than how long it is. The only findings worth an engineer's time are the ones an attacker can actually use.
Knowing that takes context a scanner never has: how the system is designed, where the code runs, what data it touches, which components talk to each other, and whether there's a real path from entry point to payload. A scanner flags a line. It cannot tell you if the line is reachable.
That is what Prime is built to answer. Prime keeps shared context across architecture, code, and infrastructure and reasons to exploitability before anything hits the queue. Findings are attack paths, not flagged lines. Customers see 100 criticals become 3. The 3 get fixed. The other 97 were never going to be, no matter how many people were working the queue.
So what's next for product security leaders?
Stop running bake-offs on false positive rate. The number is real. It is also the wrong number. It tells you how clean the queue is, not whether your team will ever reach the bottom of it, and the bottom is where the problem lives.
Ask a different question. How many of these findings can an attacker actually use, and how does that number move when my engineers ship twice the code next year? If the answer goes up with volume, the tool is counting bugs and calling them vulnerabilities.
Finding them was never the problem. The scanner found every one. It also found the 3,000 bugs sitting on top of them, and your team is going to work that queue top to bottom until the day someone outside the company finds the real one first.
See how Prime uses persistent context to identify real exploit paths and reduce security noise at primesec.ai.
External sources worth linking
- Cursor for EnterpriseSource for the PR volume (+25%) and average PR size (+100%) statistics cited in the 'Code Volume and Change Frequency' section.cursor.com
- Microsoft Study Finds AI Coding Agents Lift Pull Requests by 24%Source for the Microsoft research stat on merged pull requests per engineer per day.techrepublic.com
- SAST False Positives: 91% Are Noise. Here's the FixSource for untuned-vs-tuned SAST false-positive rate ranges cited in the historical section.pixee.ai
- The History of Spam Email: Origins, Evolution, and ImpactSource for the early-2000s spam-as-share-of-email-traffic claim used in the historical parallel.spaceship.com
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
