Introducing Continuous Coverage: test Every change with Sybil. Table of contents Key Takeaways: * RunSybil launches Continuous Coverage: Customers now can easily test application changes as fast as teams ship, because periodic pentests aren't enough. * Black-box or white-box, your choice: Enable GitHub to read recent merges, or your Attack Surface to re-crawl endpoints without code. Sybil supports one or both. * You set the pace and keep control: Choose how often Sybil checks for changes, how often it tests them, and whether each test waits for your approval or runs automatically. In the last week, your team has merged hundreds of PRs, rebuilt the billing flow, and shipped untested endpoints. AI-assisted development has made that pace the new normal, and a pentest once or twice a year can't keep up. Worse, scanners are noisy, leaving you buried in triage. Even then, finding vulnerabilities is only half the job. Someone still has to fix them. Today RunSybil Inc. is announcing Continuous Coverage to solve this disconnect. Instead of treating security testing as an isolated event that happens once a quarter, or worse, once or twice a year, RunSybil is turning testing into an automated, continuous response to the code you ship. With this new feature, which is available to all customers today, Sybil tests what changed, proves what's actually exploitable, and helps you fix it. Connect your code or start from a URL. Continuous security testing works either way. How Continuous Coverage works. To start, Sybil maps your application end to end, including its endpoints, user roles, and data flows. Then it tests all of it, creating a baseline. Sybil learns how your app works, and every subsequent test builds on that knowledge instead of starting from zero. Automated scoping guides setup. Sybil helps you identify what should be in scope so testing focuses on real risk, skips the noise, and never touches assets you didn't mean to include. Continuous Coverage works in black-box testing, white-box testing, or both. From there, every cycle runs the same loop: * Detect: As often as daily, Sybil reads code merged in GitHub, re-crawls your live app for new and changed endpoints, or a combination of the two. * Plan: Sybil groups what changed by the part of the app it affects, like billing or team permissions. It also ranks each area by risk, and explains why it's worth testing. * Test: On your cadence, Sybil rolls every change since the last run into a single test. You approve it first or let it run automatically. Every finding is validated as exploitable before it reaches you, so you get a short list of real issues, not a backlog of maybes. * Fix: Findings go to Linear, Jira, or GitHub Issues with remediation guidance. For white-box apps, with just a click of a button, Sybil can also open a pull request with the fix. Your team reviews and merges it, clicks Retest, and Sybil confirms the fix in under an hour. Detection and testing run on separate schedules. Sybil can check for changes every day without kicking off a test, and nothing found in between gets dropped. It all rolls into the next test. Black box or white box: you choose. Black box: The Attack Surface signal. With the Attack Surface signal, Sybil re-crawls your application on the interval you choose, signed in as one of your test accounts or unauthenticated, and compares the result with the previous crawl. Sybil groups new endpoints by area of the application and marks each area with a count of what's new, so you can see exactly how your attack surface has changed. You choose which areas, pages, and endpoints go into the next test. This is how an attacker first meets your application: they see what is reachable, and they notice what's new. The Attack Surface signal continuously gives your team that same view, without any code access, and Sybil tests what changed inside the scope you approved. White box: the GitHub signal. With the GitHub signal, Sybil reads every commit merged since it last tested a branch, along with the code around it. Sybil tracks changes across customer-facing surfaces, including new endpoints, authentication and permission logic, and data flows, weighing each one against the access checks and trust boundaries in your code. Sybil groups what it finds into change areas. Each area has a risk level from low to critical, a short explanation of what changed and how it could be exposed, and the changed files behind it. When nothing in a set of changes affects security, Sybil says so and explains why. Code isn't the only context Sybil can use. The Knowledge Base holds what code doesn't spell out: architecture notes, business rules, trust boundaries and known constraints. Write entries in Sybil, or connect Notion to import the pages you share with Sybil. Sybil's testing agents search the Knowledge Base. For example, when testing a billing update, an agent checks your documented rules for which users are authorized to view specific invoices. Which Signal to Use The two signals see different things. A re-crawl finds new pages and endpoints the way an outsider would, but it can't see a permission check that changed behind an endpoint that already existed. A diff can. Teams that connect code get both views. Teams that can't share code still get continuous coverage of the attack surface an attacker would see first. Set your cadence. Continuous Coverage separates looking for changes from testing them: * Signal checks: Sybil checks your repositories and re-crawls your attack surface on intervals you set, from every day to once a month. A check updates the Continuous tab. It doesn't start a test. * Testing cadence: Testing is done on your schedule, starting on the date, time, and timezone you choose. In each cycle, Sybil packages the changes you selected into one test. You also can set up blackout testing dates. When something can't wait, users can manually resync GitHub changes and run a test ahead of schedule. If a draft is still waiting for review when new changes arrive, Sybil adds them to that draft instead of starting another one. Coverage can be as predictable or ad-hoc as your team needs. Schedule recurring tests, trigger an immediate check for a high-priority enterprise fix, or switch between the two whenever priorities shift. You stay in control. Automatic testing only helps if you trust what it will do. Continuous Coverage has two review modes: * Queue a draft, I'll approve: Sybil packages each cycle's test as a draft and notifies you. Nothing runs until someone on your team reviews it and starts it. This is the default. * Just run it: Sybil packages the test and starts it automatically. In either mode, you can deselect any change area, exclude whole repositories, and edit the test's focus areas before it runs. A recommendation tells Sybil where to focus, but it never widens what Sybil is allowed to test. Every team handles human oversight differently. Sybil lets you customize exactly where actions pause for human review and where they run hands-off, keeping testing as gated or automated as you want. Continuous Coverage tests run through the same pipeline as every other Sybil test. They stay inside your configured scope and your organization's test limits, pause outside the set testing windows, and reuse the accounts you approved for your baseline test. Every cycle is logged for auditing, including its approval status and detected risks, like "3 changes worth testing: 1 high, 2 medium." See what's changing in your applications. For existing teams: Continuous Coverage is live today. Navigate to the Continuous tab on any application with a completed baseline test to set your cadence and review mode. For new teams: If you are ready to test your application, setup takes less than an afternoon. Schedule a demo. Faq. How do I get started with Continuous Coverage? With a subscription, Continuous Coverage kicks off by evaluating the application broadly, with no specific focus areas (besides scope limits defined by the user). Continuous Coverage uses that information as the baseline and reuses its accounts, source code, and knowledge base. Do I need to connect source code? No. The Attack Surface signal re-crawls your application and finds new endpoints without any code access. Connecting a repository adds the GitHub signal and its diff-based recommendations. Can Sybil change its code or open pull requests? Only with human approval. Code analysis for Continuous Coverage is read-only. Sybil can't automatically write files or run anything in your repositories. Can Sybil test something RunSybil Inc. didn't approve? No. Continuous Coverage tests use your configured scope and the accounts from your baseline test. Recommendations only decide where Sybil focuses inside that scope. Can RunSybil Inc. review tests before they run? Yes. Choose Queue a draft, I'll Approve It, and every cycle waits for your sign-off. You can also deselect individual change areas before Sybil packages and begins the test.

Changelog: October 2026. Table of contents Key Takeaways: October 2026 Product Updates * New Attack Surface View: Group application areas, visualize endpoint discovery and reachability, and monitor endpoints first observed in the last 30 days. * Jira Ticketing Integration: Push vulnerability findings directly into Jira workflows with automatic ticket updates after retesting. * Redesigned Test Creation: Launch tests quickly using Basic, Change, or Advanced templates; set up recurring runs; and run change tests with GitHub PR-level visibility. * Notification Inbox: Added a centralized organization inbox to manage unread notifications. Get full visibility into your application's Attack Surface. Track every endpoint Sybil sees across your entire stack. With the new surface view, you can map application areas, trace reachability and discovery paths, and flag endpoints detected in the last 30 days. Search and filter the catalog to inspect any target in seconds. Push vulnerability findings to Jira through its new Integration. Following its recent ticketing integrations for Linear and GitHub, RunSybil Inc. has added full Jira support. This allows teams to receive findings directly in their existing workflow without stepping into the RunSybil UI. When findings are rediscovered on subsequent tests, they update existing tickets accordingly, keeping noise at a minimum for remediation teams. Launch the right test for the job. RunSybil Inc. has redone the test creation experience to be quick and intuitive, stripping away unnecessary complexity. Choose a Basic, Change, or Advanced template. Then review the scope and resources before launch. Schedule it for one run, or set a recurring cadence. More updates and enhancements. * Notification Inbox: The notification bell now shows a centralized inbox with unread counts and controls to mark notifications read or unread. * Finding Status History: Finding history now shows status changes, closures, and reopenings, making it easier to follow remediation and retest outcomes. * Pre-test Readiness Checks: Through the platform, you can run key tests, like making sure your application is accessible and that credentials work, before the test launches. * See Remaining Tests: The toolbar shows how many tests your organization has left, with a breakdown of completed and remaining tests for clarity. * Attack Fronts Export: Export a complete audit log of HTTP requests made during a test, making compliance reviews and test validation easier. * Notion Knowledge Base Integration: Connect Notion to Sybil to give agents additional application context during pentesting. Coming up on its roadmap. * Knowledge Base Integrations: RunSybil Inc. is continuing to evaluate knowledge base sources beyond Notion to help teams run more efficient, context-aware evaluations If you're interested in this capability, RunSybil Inc.'d love to hear from you. Reach out to your customer success manager. * Resilient Egress Architecture: Work continues on dedicated, per-engagement backup IPs to ensure blocked or overloaded connections do not disrupt your testing. * Remediation Features: RunSybil Inc. already offer copy/paste ready remediation prompts for Codex, Claude, and Cursor. RunSybil Inc. is looking to enhance the remediation experience with automatic retesting triggered by actions like closed tickets and variant retesting. Wrapping up. That's all for this month! RunSybil Inc. hope these updates make your experience with RunSybil even better. As always, your feedback is what drives its roadmap. If you have any suggestions, questions, or just want to say hi, feel free to reach out. Faq. Recent product questions RunSybil Inc. want to surface: 1. Can RunSybil tell me about parts of my attack surface I don't know about? As RunSybil explores the applications you've put in scope, it can reveal pages and API endpoints you may not have known were there. The attack surface view shows what Sybil has learned across your applications. Within an application, you can explore endpoints by feature area, see how pages and requests relate, and track when Sybil first observed an endpoint. You can also inspect how an endpoint was discovered and whether it appears publicly reachable or requires authentication. 2. Is RunSybil a Bug Bounty Platform? RunSybil hunts for vulnerabilities the same way that Bug Bounty researchers do, but entirely through agentic automation. RunSybil customers have told RunSybil Inc. that its platform has replaced their Bug Bounty budgets. 3. Is AI pentesting the same as vulnerability scanning? No. A vulnerability scanner matches known signatures and reports anything that might be vulnerable, which creates a lot of false positives. AI pentesting attempts to exploit what it finds and only reports verified issues. Scanners tell you what could be wrong. AI pentesting tells you what an attacker can actually do. 4. How is AI pentesting different from DAST? DAST tools send known malicious payloads at a running app and flag suspicious responses. They don't understand your app's logic, so they miss authorization flaws and produce false positives. AI pentesting explores the app like a user or an attacker would, learns its roles and data model, and proves exploitation end to end.