A security team can spend its whole morning staring at a number. Seven hundred vulnerabilities. Twenty marked critical. One patch window. The number tells them how much work exists, but almost nothing about which mistake an attacker could use first. Ridge Security Technology, a company from Milpitas, California, has made a business of answering the second question.
Its software runs controlled offensive tests against a customer's own systems. It discovers assets, probes weaknesses, attempts to validate exploitability and records the route an attack could take. The finding is meant to arrive with evidence that an engineer can inspect and a security leader can use to rank the repair queue. The product's promise is appealing precisely because the queue is never empty.
- RidgeBot handles broad, repeatable penetration testing and vulnerability validation.
- RidgeGen pursues deeper, multi-step attack paths with AI agents and independent checks.
- RidgeSphere lets large organizations and service providers manage many RidgeBot installations.
- The buyer is usually a security team trying to decide what to fix first, and to prove the fix held.
The objection that started a company
Co-founders Nick Mo and Lydia Zhang came from the defensive side of cybersecurity. Mo had worked at Juniper, Netscreen and Cisco; Zhang had been in product management at Cisco and in a firewall company. In a 2020 interview, Mo described an uncomfortable result of that experience: even after teams spent heavily on defensive products, breaches still happened. The failure that bothered them was not a single firewall or a single customer. It was the assumption that buying defenses showed whether those defenses would survive an actual attacker.
Zhang put the founding thought more bluntly: To catch a criminal, we have to think like a criminal.
RidgeBot was designed to work through several steps of a penetration test rather than hand an analyst a collection of disconnected scans. The company profile lists 2020 as its founding year, although the founders said in that early interview that they started the venture in late 2019. The distinction matters less than the change in method: use software to keep testing after the annual consultant's report has been filed.
“To catch a criminal, we have to think like a criminal.”Lydia Zhang, co-founder and president
A scanner raises its hand. RidgeBot tries the door.
A conventional vulnerability scanner is good at finding versions, signatures and known misconfigurations. It may still leave an analyst to determine whether a particular flaw is reachable, whether another control blocks it and whether it leads anywhere valuable. RidgeBot's central move is to automate more of that investigation. It profiles a target, identifies a weakness, tries a controlled exploit and displays the resulting attack chain. The company's published methodology describes a library of more than 6,000 proof-of-concept exploits.
Ridge calls this a route to “zero false positives.” Read that as a description of its reporting rule, not as a universal guarantee about all cyber risk. A finding that has been demonstrated is more actionable than a guess; a test can still miss a flaw it never examined. Scope, credentials and the chosen test posture determine what the machine can see. That is why the practical question for a buyer is not only how many findings appeared. It is which ones another analyst can replay, and what the product was allowed to touch.
The 20,000-device problem
One of Ridge's more concrete examples is an unnamed national retailer with more than 100 stores and over 20,000 IP devices. Its estate included an ecommerce platform, payment systems and connected equipment such as printers and cameras. Ridge says RidgeBot identified critical vulnerabilities in three months and saved the equivalent of 1.5 years of manual effort. Those numbers come from a company case study, without the customer named or an independent audit of the savings. Even with that limit, the shape of the problem is familiar: too many devices for a small team to test deeply by hand, and too many changes for one annual snapshot to stay useful.
Other published cases and customer pages describe finance, government, healthcare, telecom and transportation. The common buyer is the person who needs to turn a large, changing estate into a defensible order of work: a CISO, a vulnerability manager, a security operations team or a managed security service provider. RidgeSphere is built for the last group. It gives a provider a central console to manage multiple RidgeBot deployments, licenses and reports across clients. That is a business model as well as a feature: Ridge can sell through partners and marketplaces while those partners package ongoing testing as a service.
The second speed
The company's newer RidgeGen product tackles a different kind of work. RidgeBot is presented as the broad, regular sweep; RidgeGen is the deeper investigation of multi-step attack chains, including weaknesses that do not fit a familiar CVE. On Ridge's current site, the distinction is explicit: breadth across the estate, depth on important targets. It is a sensible division of labor. A company cannot spend the same level of human or machine attention on every server, application and API.
RidgeGen's most interesting feature may be its restraint. Ridge says one set of agents searches for potential risks while another independently reproduces findings before they are shown. Its SafeBox design keeps credentials out of a language model's prompt and memory; safety policies are enforced outside the model's discretion. The product offers different testing postures, from non-intrusive production checks to more aggressive, explicitly authorized work in non-production environments. Autonomy without a boundary would be an odd thing to sell a security team. Here the boundary is part of the pitch.
The company has also moved findings closer to the repair workflow. In 2026 it announced an integration that sends RidgeBot's validated attack insights into CrowdStrike Falcon Next-Gen SIEM. Its technology partner page describes connections with tools from Tenable, Rapid7, Microsoft and others. That placement matters: a beautifully rendered attack path does little if it remains in an isolated console while the people who can fix it work elsewhere.
What a buyer should copy
The useful lesson is a testing habit, even for teams that never buy Ridge's software. Choose a small set of high-value assets. Define what an authorized test may do. Ask for a reproducible path from exposed entry point to consequence. Put the evidence in the system where remediation gets assigned. Then rerun the test after a fix, because a closed ticket is an administrative event and a closed attack path is a technical one.
The price of Ridge's platform is not publicly listed; enterprise licensing, cloud marketplace access and partner delivery suggest a sale shaped around deployment and scope. Buyers should count more than the license. They need time to approve tests, tune safe operating boundaries, investigate results and repair the confirmed weaknesses. Automated testing reduces repeat work; it does not patch a network by itself. It also cannot claim to have examined assets it was never given access to. That limitation is worth remembering whenever a dashboard offers a reassuringly tidy percentage.
Ridge has collected recognition, including a Frost & Sullivan product innovation award in 2026 and mentions in Gartner's security operations research. Awards can attract a meeting. The more durable test is whether the product changes the Tuesday morning meeting in which twenty urgent alerts compete for one patch window. If a demonstrated attack path wins that argument, Ridge's central idea has done its job.