Introducing Surveyor™ for application security testing
Background
Engineers are constantly striving to be more efficient, using tooling, as the joke goes, to automate themselves out of a job. Technology improves lives through automation, whether through daily efficiency improvements to cars or the quest for better search results via Google rather than Ask Jeeves. This drive for efficiency is not new. Before the invention of the plow, farmers had to prepare the soil manually, a grueling, time-consuming process. A relatively simple tool, the plow reduced the effort and time required for tilling, allowing workers to cultivate larger areas, and ultimately leading to greater agricultural output and societal advancement.
Application Security Tools
Application Security has followed similar patterns in automating difficult tasks. Initial exploration of most vulnerabilities is a manual process. My early days in the field consisted of manual entry of the string ‘+OR+1=1– into login forms across the web. Given the state of SQL interactions at the time, this was an effective strategy for identifying SQL injection flaws in most applications. However, manual identification of these flaws took too long. Early practitioners developed scripts to quickly identify flaws. What followed was a standard list of patterns, dynamic scanners, and sqlmap for identification and exploitation, reducing the time it took to quickly evaluate any web application for SQL injection.
On the developer side, the same evolution occurred. Initial database interactions required developers to handwrite SQL statements using string-building techniques. This turned out to be inefficient, both from a usability and security perspective. Over time, frameworks and ORMs replaced string-building techniques, giving developers time to focus on other development activities.
Security Consulting
My own career has taken me through a range of roles: from a developer, to a security generalist, back to application security consultant, to security architect, and finally to a foundering of an application security boutique. There are very few application security tools that have not been exercised via command-line on my system. Early days exercising nikto, skipfish, and curl to find issues, followed by WebInspect and AppScan, to intruder and custom requests in Burp Suite Professional to expand into other vulnerability classes.
Each phase of my career has involved consultants, sometimes as a resource, sometimes as the resource engaged. This has led to stints installing or configuring security tools, advising internal and external resources on security programs, reviewing source code for vulnerabilities, and documenting every activity under the sun. The constant across the activities –reflecting the clarion call for automation – is the use of security tools.
Surveyor™
At Redpoint Security, we recognized early on that AI would change the way we do our job. Just like proxies, WAFs, SAST, and DAST tools, each technology shift requires us to be nimble. Our initial explorations into LLM use were naive and ineffective, but we learned from those experiments how to balance deterministic patterns with AI creativity.
Drawing on our decades of experience as consultants, we have designed Surveyor™ to improve our consultants’ ability to find critical vulnerabilities in running applications. By reducing the cognitive load needed to find “low-hanging fruit” and build context about an application, we can go deeper while reducing our dependence on traditional DAST tools.
While initially focused on client-side web application monitoring, Surveyor™ has now expanded into a full-blown DAST replacement that is improving daily. An expert tool, intended for expert use while giving customers real security insight into their running application.
It’s not for nothing that the thought of engineers automating themselves out of a job occurred to us as we’ve developed Surveyor. Our principal consultant Justin Larson has, over the years, joked that Insecure Direct Object Reference flaws pays our salaries (link: https://redpointsecurity.com/thoughts-on-the-new-owasp-top-ten/), so when one of Surveyor’s first successful indications of a possible vulnerability path turned out to be a kind of tricky IDOR, it looked like Surveyor’s lead developers had successfully uploaded their brain into a reasoning model-supported agent.
That late summer 2025 version of Surveyor told us that there was a suspicious pattern in the application behavior, and Redpoint Security testers were able to validate an IDOR vulnerability on that endpoint.
As it turns out, this finding could be attributed to both Justin and Justin 2.0 in Surveyor
Since these initial promising results from our development of Surveyor as a day-to-day tool for our dynamic application vulnerability testing, we’ve iterated on Surveyor’s success and refined its capabilities using agentic model improvements. Aaron has been collecting a running list of findings that have been aided by Surveyor, highlighting dodgy endpoints. We’re excited about what it will help us do next.
Want to see Surveyor™ in action? Reach out to set up a demo.
