# Documentation URL: https://docs.dryrun.security/ DryRun Security is an AI-native application security platform that reviews every pull request and repository scan for vulnerabilities in real time. It builds an intelligence layer on top of all scan data, surfacing trends, patterns, and risks across your entire codebase and development organization. These docs cover setup, scanning, code security intelligence, platform administration, and integrations. AppSec Engineers Surface top-level risk across your organization, review findings in depth, and run targeted security reviews on any repository. Developers Connect your repositories, understand PR findings as they appear, and triage false positives without leaving your workflow. Admins Configure repository scanning rules, manage notification channels, customize finding interpretation, and integrate via the API and MCP. Products PR Scanning Every PR is reviewed by DryRun Security's AI engine, which posts contextual findings directly in your code review. Repository Scanning with DeepScan Scan an entire codebase on demand to uncover vulnerabilities that predate PR-level analysis. Secrets Scanning Catch API keys, tokens, and hardcoded passwords in diffs before they are merged into protected branches. IaC Scanning Scan Terraform configurations for security misconfigurations and insecure defaults in pull requests. SCA Identify known CVEs and license issues in your open-source dependencies with DeepScan. Remediation Accept AI-generated fixes for common vulnerability patterns and verify the remediation in a single step. Code Security Intelligence Code Security Intelligence An intelligence layer built on top of all finding data and trends, surfacing feature ships, vulnerability trends, architecture risks, developer patterns, shadow AI usage, incident investigation, and more. Platform & Integrations Finding Tuning with Feedback Tune findings, dismiss false positives, and track triage decisions across your organization. PR Blocking Prevent PRs from merging when findings exceed the severity or policy thresholds you define. Custom Code Policies Write organization-specific security rules in plain language and enforce them on every scan. DryRun Skill Connect your AI coding assistant to DryRun Security findings for contextual security guidance while you write code. Webhooks Stream scan events and finding data to any HTTP endpoint for custom automation and reporting pipelines. MCP Expose DryRun Security data to AI coding assistants and agents through the Model Context Protocol. --- # Quick Start URL: https://docs.dryrun.security/quick-start Install DryRun Security on GitHub or GitLab and start scanning pull requests in minutes. Getting Started DryRun Security is an AI-native application security platform that reviews every pull request for vulnerabilities in real time. This guide helps you install DryRun Security on GitHub or GitLab, run your first scan, and configure the platform to match your workflow. Deployment Rollout Best Practices Follow these steps to get the most out of DryRun Security: Step Action Description 1 Install DryRun Security Connect your repositories on GitHub or GitLab so every pull request is automatically reviewed. 2 DeepScan Run a full-repository scan to establish your baseline security posture. 3 Review findings in the Risk Register Examine and prioritize vulnerabilities surfaced across your repositories. 4 Triage false positives as needed Suppress findings that are not applicable so future scans stay focused on real risks. 5 Configure context Provide repository-level context so DryRun Security's analysis is tailored to your codebase. 6 Create Custom Code Policies Define organization-specific security rules written in plain English. 7 Configure integrations and notifications Route alerts to Slack, webhooks, or other channels your team already uses. 8 Enforcement Configure blocking rules to prevent PRs from merging when findings exceed your defined severity or policy thresholds. 9 Unlock the power of Code Security Intelligence Query the intelligence index to track features, trends, and risks across your organization. Supported Platforms Platform Supported Versions Setup Guide GitHub GitHub.com (Cloud) GitHub Installation GitHub GitHub Enterprise Server (On-Premises) GitHub Enterprise Server Installation GitLab GitLab.com (Cloud) GitLab Installation Installation Requirements Before installing DryRun Security, confirm the account performing the installation has the required permissions for your platform: Platform Who Can Install Access Granted GitHub Organization admin, or Enterprise admin if an enterprise account is in use GitHub App with read access to code and metadata, and read/write access to checks, issues, and pull requests GitLab System Administrator or Group Owner API access via a scoped Group Access Token GitHub Installation Authorize and Install the DryRun Security GitHub Application Note: You must be signed in as an organization admin (or an enterprise admin, if your organization is part of a GitHub Enterprise account) to install the GitHub App. Navigate to https://app.dryrun.security and click the Log in with GitHub button. Log in to the GitHub account where DryRun Security will be installed. Authorize the DryRun Security GitHub Application by clicking the Authorize DryRunSecurity button. Note: This is a standard authorization screen for all applications in GitHub. You'll be redirected to the DryRun Security portal. Click the Install button. Click the Install button on the DryRunSecurity GitHub Application page. Choose the GitHub repositories DryRun Security will run by selecting All Repositories or Only selected repositories. After step one your installation may be paused for up to 2 business days as we activate your account. Once your account has been activated, you'll see the Installation Complete message the next time you visit https://app.dryrun.security. Congratulations! Installation is complete. At this point DryRun Security will run checks on your repository as code is committed to Pull Requests. GitHub Enterprise Server Installation DryRun Security supports on-premises GitHub Enterprise Server (GHES) installations. Setup requires a brief coordination with the DryRun Security team before installation can proceed. Step 1 - Initial Setup To get started, email hi@dryrun.security with your Enterprise Profile URL (e.g., https://github.yourcompany.com/enterprises/your-enterprise). DryRun Security will verify that your GitHub Enterprise Server is reachable at the provided URL before installation can proceed. Once confirmed, DryRun Security will follow up with next steps. Note: If your instance is not yet publicly accessible to DryRun Security over HTTPS, reach out and we can discuss connectivity options for your environment before moving forward. Step 2 - Create the GitHub App DryRun Security will send you a link to begin installation. When you open it, you will see a Webhook Secret and a Create GitHub App button. Copy the Webhook Secret shown on the page - you will need to paste it into the GitHub App during creation Click Create GitHub App - this opens the GitHub App creation page in your GHES instance with DryRun Security's configuration pre-filled Paste the Webhook Secret into the Webhook Secret field in the GitHub App creation form Click Create GitHub App on GitHub to complete the creation Note: Depending on your GHES version, you may see a radio button at the bottom of the creation page to install this app for Any organization and any user. If present, select this option to ensure the app is available across your enterprise and not limited to the user creating it. Return to the DryRun Security setup page and click I've created my App - Continue to Step 2 Step 3 - Enter App Credentials Step 2 of the DryRun Security setup asks for credentials from the GitHub App you just created. In your GHES GitHub App settings page: Copy the App ID and Client ID shown at the top of the page Click Generate a new client secret and copy the value Scroll to the bottom of the settings page and click Generate a private key - this downloads a .pem file Return to the DryRun Security setup page and fill in the App ID, Client ID, and Client Secret fields, then upload the .pem file. Click Submit. Once complete, you can install DryRun Security on your repositories. Step 4 - Install on Repositories Navigate to https://app.dryrun.security and select your corporate organization from the org picker. The org picker may default to your personal GitHub account - make sure the correct enterprise organization is selected before proceeding. Click the Install button. Click the Install button on the DryRunSecurity GitHub Application page. Choose the GitHub repositories DryRun Security will run by selecting All Repositories or Only selected repositories. After installation your account may be paused for up to 2 business days as we activate your account. Once your account has been activated, you'll see the Installation Complete message the next time you visit https://app.dryrun.security. Congratulations! Installation is complete. DryRun Security will run checks on your repositories as code is committed to Pull Requests. GitLab Installation DryRun Security for GitLab.com enables fast, contextual code reviews that help your team spot unknown risks before they start. This guide will walk you through connecting your GitLab environment to DryRun Security by: Creating a GitLab Group Access Token with the correct scopes. Installing DryRun Security via the DryRun Security Dashboard. Once installed and activated, you'll get immediate visibility into security risks across your GitLab projects, without slowing development down. Create a Group Access Token This section describes creating a Group Access Token that will be used during the installation of DryRun Security. Creating a Group Access Token requires System Administrator or Group Owner permissions. Generating the Group Access Token Log in to gitlab.com. Navigate to the Group where DryRun Security will be installed. Go to Settings > Access Tokens. Click Add new token. Add a token name, set the role to at least Maintainer, and select the api scope. Click Create group access token. Copy the token and save it for later use. Done! The Group Access Token can be used to install DryRun Security. Install DryRun Security via the Dashboard Navigate to https://app.dryrun.security and click the Log in with GitLab button. Authorize the DryRun Security OAuth Application. Important: Choose the User or Group where DryRun Security will run from the User/Group Selector. This is usually a Group. Click the Add Token button or navigate to Settings > GitLab. Enter the Group Access Token created earlier and click Save Token. Verify the User/Group for the Installation and click Confirm to confirm API access. Install on Projects by clicking + next to the Project and then click Save Projects. Note: Use a service account or group access token when connecting DryRun Security to GitLab. A personal access token is tied to an individual user account. If that account is deactivated or loses access, the integration stops working and DryRun Security will no longer be able to scan merge requests. Installing with a personal access token also causes scan results and comments to appear attributed to that individual user rather than a shared service identity. Activation Your installation may be paused for up to 2 business days as we activate your account. We'll notify you as soon as your account has been activated. Once your account has been activated, you'll see the Installation Complete message the next time you log in to the portal at https://app.dryrun.security. Congratulations! Installation is complete. Note: At this point the DryRun Security application will run and analyze changes as code is committed to the Project(s). Managing Repositories and Organizations After installation, you can connect additional organizations, add repositories, or adjust which repositories DryRun Security scans from the Repositories page in the dashboard. Log into app.dryrun.security and navigate to Repositories. Click + Add. GitHub displays a list of all organizations you are an admin of. Select an organization: New organization - Selecting an org where DryRun Security is not yet installed begins a fresh installation on that org, using the same flow as the initial setup. Existing organization - Selecting an org where DryRun Security is already installed opens the Repository Access screen, where you can switch between All repositories and Only selected repositories, or add and remove individual repositories. Changes take effect immediately -- repositories added to the selection begin receiving PR scan coverage right away. References PR Code Reviews - understand how DryRun Security analyzes your pull requests. Configurations - customize which agents and policies run on each repository. Custom Code Policies - create custom security rules in plain English. --- # PR Scanning URL: https://docs.dryrun.security/pr-scanning Understand how DryRun Security automatically analyzes your pull requests for security vulnerabilities. How It Works DryRun Security analyzes code changes every time a pull request is opened or updated. Its security agents inspect the diff, evaluate the surrounding context, and report findings directly on the PR - before the code is merged. Each finding is evaluated for impact and exploitability and tagged with a severity: Critical, High, Medium, or Low. Scanning runs automatically with no manual steps required: open a PR and DryRun Security handles the rest. Results appear as a summary comment on the pull request, inline comments on specific lines, and a pass/fail check status that integrates with your branch protection rules. This keeps security feedback inside the developer workflow where it can be acted on immediately. Supported Platforms DryRun Security integrates natively with GitHub, GitLab, and GitHub Enterprise Server (GHES), covering both cloud-hosted and self-managed source code platforms: Platform Trigger Check Status Inline Comments GitHub Pull request opened or synchronized GitHub Checks API PR review comments on affected lines GitLab Merge request opened or updated GitLab pipeline status Merge request discussion comments GitHub Enterprise Server (GHES) Pull request opened or synchronized GitHub Checks API PR review comments on affected lines What Gets Analyzed When a pull request is opened, DryRun Security retrieves the diff along with relevant surrounding code context - imported modules, authentication middleware, framework conventions, and any configured security policies. Analysis is scoped to the changed regions and the code paths that flow through them. DryRun Security also reads the repository's agents.md file, if present. This allows teams to provide context and instructions that guide the security analysis - such as project-specific conventions, known safe patterns, or areas of particular concern. The following security agents run on every PR scan: Cross-Site Scripting Analyzer General Security Analyzer IDOR Analyzer Mass Assignment Secrets Analyzer Server-Side Request Forgery Analyzer SQL Injection Analyzer Any custom code policies created by your team All findings are filtered to the changed regions of the pull request. Pre-existing issues in unchanged code are excluded from the results so developers can focus on what they introduced. Check Status & Feedback DryRun Security reports results through two channels: a summary comment on the pull request with an overview of all findings, and individual check statuses that integrate with your branch protection rules. Each check corresponds to a specific security agent or policy. The check status reflects the outcome of that agent's analysis: Status Meaning Success No findings at or above the configured severity threshold. The PR is clear to merge. Failure One or more findings meet or exceed the blocking threshold. The PR cannot be merged until issues are resolved. When findings are detected, inline comments are posted directly on the affected lines of code with a description of the vulnerability and remediation guidance. For details on enforcing merge gates with check statuses, see PR Blocking. If you are seeing noisy or irrelevant findings, you can tune your findings to reduce noise and focus on the issues that matter most to your team. Configuration PR scanning behavior is controlled through configurations in the DryRun Security dashboard. Each configuration can be applied to one or more repositories, and a default configuration covers any repository not assigned to a specific one. Setting Default What It Controls Security Agents All enabled Which code security analyzers (XSS, SQLi, IDOR, Secrets, etc.) run on PRs Custom Code Policies None attached Organization-specific rules written in plain English, enforced on every PR PR Blocking Disabled Whether findings at a given severity fail the check status and prevent merge Blocking Threshold High Minimum severity level (Critical, High, Medium, Low) that triggers a failed check PR Issue Comments Enabled Whether DryRun Security posts a summary comment and inline findings on the PR Notifications Disabled Alerts sent via Slack or webhook when findings are detected Configurations follow an inheritance model: the default configuration applies to all repositories, and repository-specific configurations override it. This lets you set organization-wide baselines while customizing behavior for individual repositories or teams. See PR Scanning Configuration for a full walkthrough of creating and managing configurations. How PR Scanning Differs From DeepScan DryRun Security offers two scanning modes. PR Scanning analyzes changes as they arrive in pull requests. DeepScan performs a full-repository analysis to find vulnerabilities in existing code. The two modes are complementary: Aspect PR Scan DeepScan Scope Changed files and surrounding context in the PR Entire repository codebase Trigger Automatic on PR open or update Manual (dashboard or API) or scheduled Speed Seconds to minutes, depending on diff size Minutes to hours, depending on repo size Differential Analysis Yes - only new findings from the PR are reported No - all findings in the codebase are reported Results Location PR comments, inline annotations, check statuses, and the DryRun Security dashboard DryRun Security dashboard and Risk Register Best For Catching new vulnerabilities before merge Baseline assessment, audits, and legacy code review Supported Languages PR scanning supports the same languages and frameworks as DeepScan. For the full list, see Language and Framework Support. Vulnerability Categories PR scanning can detect a broad set of vulnerability categories. For the complete system-wide reference, see the Vulnerability Coverage Matrix. --- # SCA URL: https://docs.dryrun.security/sca Dependency scanning and supply chain risk detection - identify vulnerable third-party packages, assess blast radius, and generate SBOMs. What Is SCA Software Composition Analysis (SCA) identifies the third-party libraries and open-source packages your application depends on and checks whether any carry known security vulnerabilities. The majority of code in any production service comes from the open-source ecosystem, making dependency risk one of the most important areas to monitor. DryRun Security checks each dependency against known vulnerability databases, matching specific CVEs to affected version ranges across all major package ecosystems. How Scanning Works DryRun Security runs SCA through two paths: DeepScan - When a DeepScan runs, whether triggered manually from the dashboard or programmatically via the API, SCA runs as part of that scan, analyzing dependency manifests and lock files across the entire codebase at that point in time. This is the on-demand path for getting a current snapshot of supply chain risk whenever you need it. Automatic background scanning - DryRun Security also scans active repositories automatically in the background, entirely independent of DeepScan. These background scans discover new SCA findings as they appear (for example, newly introduced dependencies or newly disclosed CVEs) and update the status of existing findings as manifests and lock files change, all without requiring a manual trigger. Scan frequency is based on PR activity, so the most active repositories are kept up to date most often. See Scan Schedule below. Reachability Analysis Finding a vulnerable dependency is only the first step. DryRun Security evaluates how each vulnerable package is actually used within your codebase to determine whether the vulnerability is reachable from a real code path. A vulnerable function in a library used only for unrelated functionality presents a meaningfully different risk profile than one called directly with user-supplied input. Reachability context surfaces alongside each SCA finding, giving your team the information needed to prioritize remediation based on actual exploitability rather than CVSS scores alone. Scan Schedule Automatic SCA scans are scheduled based on repository PR activity over the last 30 days: ActivityFrequency High activityDaily Moderate activityWeekly to bi-weekly Low activityMonthly Inactive (fewer than 3 PRs in 30 days)No automatic scan Repositories that fall below the activity threshold do not receive automatic scans. Trigger a DeepScan manually, from the dashboard or via the API, to get current SCA findings for an inactive repository. What’s Checked DryRun Security scans package manifests and lock files across all major ecosystems: JavaScript / Node.js - package-lock.json, yarn.lock Python - requirements.txt, Pipfile, pyproject.toml, poetry.lock, uv.lock Ruby - Gemfile, Gemfile.lock Java / Kotlin - pom.xml, gradle.lockfile, buildscript-gradle.lockfile, gradle/verification-metadata.xml Go - go.mod Rust - Cargo.lock .NET - *.csproj, deps.json, packages.config, packages.lock.json PHP - composer.lock Note: For Gradle projects, SCA requires a committed dependency lock file. Standard Gradle build files (build.gradle, settings.gradle) are not used for dependency resolution. gradle.lockfile and buildscript-gradle.lockfile are supported at any directory level; gradle/verification-metadata.xml is only read from the repository root. Viewing Findings SCA findings are available in several places in the DryRun Security dashboard: the Risk Register (filter by SCA agent type to see all dependency findings across repositories, alongside PR scan and DeepScan results), Repository pages (SCA findings for a specific repository are visible from that repository’s detail page), the DeepScan page (SCA findings from a DeepScan run are included in the results and can be filtered separately), and the dedicated Dependencies view described below. Dependencies View The Dependencies page provides a dedicated CVE-centric view of all SCA findings across your organization's repositories. Four severity cards at the top give an immediate count of Critical, High, Medium, and Low findings. Each row in the findings table represents a unique combination of vulnerable package and CVE, with the repository where it was detected and the current CVSS score. Findings Table The findings table shows all SCA findings across your connected repositories, sorted by CVSS score by default. Each row includes: Risk - the severity level: Critical, High, Medium, or Low Package - the package name and ecosystem, such as pypi or npm CVE - the associated CVE identifier CVSS - the CVSS score for the vulnerability Repository - the repository where the vulnerable package was detected Status - the current lifecycle status of the finding All columns are sortable. The search bar and filter controls let you narrow results by repository, severity, or other criteria. Finding Detail Clicking any row opens a detail panel with two tabs. CVE Details shows the full vulnerability context: the package name and ecosystem, CVSS score and vector string, the affected and patched versions, the specific files in the repository where the vulnerable package is declared, first and last detection timestamps, the branch where the finding was observed, a description of the vulnerability, and links to external advisories including NVD, GitHub Security Advisories, and the package maintainer's security pages. Impacted Repositories lists every repository in your organization where the same vulnerable package version appears. This view makes it straightforward to assess the blast radius of a single CVE across your entire codebase before beginning remediation. The Dependencies view is a sibling to the Risk Register, sharing the same underlying SCA data. The Risk Register is the primary triage surface for managing finding status across all finding types. The Dependencies view focuses on supply chain risk specifically, with CVE-centric detail and cross-repository impact assessment. SBOM SCA findings feed into SBOM (Software Bill of Materials) generation. DryRun Security generates a complete inventory of your software dependencies from both DeepScan and automatic background scans, retrievable via the DryRun Security API for compliance and audit purposes. --- # Repository Scanning with DeepScan URL: https://docs.dryrun.security/deepscan DeepScan analyzes your entire codebase, not just recent pull requests, to find vulnerabilities that accumulate over time. What Is DeepScan? DryRun Security's standard PR Code Review analyzes changes as they arrive in each pull request. This is highly effective for catching new vulnerabilities before they merge, but it doesn't address risk that was already present in the codebase before DryRun Security was installed - or vulnerabilities that were introduced gradually across many small commits. DeepScan solves this by triggering a full-repository analysis. Rather than examining a diff, DeepScan ingests and analyzes the complete codebase, tracing data flows across files, identifying vulnerable patterns in legacy code, and surfacing risks that would never appear in a PR-only workflow. When to Use DeepScan DeepScan is most valuable in several scenarios: Initial onboarding - Run a DeepScan when first connecting a repository to DryRun Security to establish your baseline security posture. After a security incident - Use DeepScan to sweep a repository for related vulnerabilities after a finding is reported. Compliance and audit preparation - Generate a comprehensive findings report for auditors or regulators who need evidence of security review. Periodic security reviews - Schedule DeepScans on a regular cadence to catch drift and regression that PR-level analysis might miss across long periods. Major refactors or dependency upgrades - When significant portions of the codebase change outside of a single PR, DeepScan ensures the full scope of changes is reviewed. Triggering a DeepScan A DeepScan can be started from the DeepScan page by selecting a repository and branch. DryRun Security pre-selects the repository's default branch automatically, so most scans require only a repository selection to proceed. Any branch can be targeted when a different scope is needed. Once a scan starts, the DeepScan page updates in real time to show which analysis phase is running, from initial codebase profiling through security domain reviews to report generation. Findings are published as they are validated and will begin appearing before the scan completes. DeepScans can also be triggered programmatically. See the DryRun API page for endpoint details. DeepScan Workflow Understand the codebase - Profile the app’s language, frameworks, components, and data stores. Gather security-relevant info - Map routes, auth files, configs, and authorization patterns. Plan the review - Generate a targeted attack plan for each security domain. Run the reviews - Analyze each domain (auth, injection, crypto, config, SCA, etc.). As each finding is validated, it is published to the dashboard in real time. Clean up the report - Calibrate severities, remove hallucinations, deduplicate, and add exec summary and recommendations. Publish and triage - When the scan completes, the full report is finalized. Findings can be triaged and annotated as they appear during the scan and after it completes. DeepScan Findings Findings are published to the dashboard as they are validated during the scan, so you can begin reviewing and triaging before the scan finishes. Once the scan completes, the full report is finalized. There are two ways to review findings: Option 1 - Risk Register Filter the Risk Register by DeepScan to see all findings surfaced by DeepScan across repositories. This gives a unified view alongside PR scan findings for triage and prioritization. Option 2 - DeepScan Page From the DeepScan page, click on a previously scanned repository to see findings from the latest scan. A severity summary at the top shows counts across Critical, High, Medium, and Low. Previous scans can be reviewed by date, and findings can be filtered by risk level, SCA, or dismissed status. Clicking on an individual finding opens a pop-out module with the finding detail, the DeepScan summary, and any artifact files. The Scan Details view provides the full scan report and includes a report download option. Vulnerability Categories DeepScan detects a broad set of vulnerability categories across your codebase. For the complete list of all finding types surfaced by DeepScan, PR scanning, and SCA, see the Vulnerability Coverage Matrix. Supported Languages DeepScan supports a wide range of languages and frameworks. For the full list including PR scanning and SCA ecosystem coverage, see Language and Framework Support. Git Behavioral Analysis DryRun Security constructs a Git Behavioral Graph before its AI agent reads a single line of code - analyzing commit history across five behavioral axes to steer the scanner toward the code that matters most. The techniques described here are grounded in Adam Tornhill's Your Code as a Crime Scene (2nd ed., Pragmatic Programmers, 2024). DryRun Security engineered these forensic principles into a pipeline that steers an AI agent with deterministic precision. Read the full blog post for additional context. Why Git History Matters for Security Traditional static analysis lacks a fundamental dimension of context: the human element. Vulnerabilities are rarely just syntactical errors - they are the byproduct of diffuse ownership, shifting requirements, and knowledge decay. The Git Behavioral Graph provides a deterministic, high-signal heuristic to prioritize the agent's attention before it reads any code. The Five Behavioral Axes Code churn - Files with high revision counts and many distinct contributors historically correlate with vulnerability density. The pipeline quantifies this as a normalized churn score. Contributor coupling - When many authors touch the same file, implicit knowledge can be lost. The ratio of unique contributors to total revisions produces a diffuse-ownership signal. Temporal coupling - Files that change together frequently suggest hidden dependencies. If a change to auth_middleware.py always accompanies changes to session_handler.py, a change to one without the other is suspicious. Recency weighting - Recent changes carry more risk than ancient stable code. The pipeline applies exponential decay weighting so churn from last week outweighs churn from last year. Complexity hotspot scoring - Combining churn and contributor metrics with code complexity produces composite hotspot scores that identify the files most likely to harbor latent vulnerabilities. --- # Secrets Scanning URL: https://docs.dryrun.security/secrets-scanning How DryRun Security detects hardcoded credentials, API keys, tokens, and other secrets in your codebase. The Secrets Analyzer Hardcoded credentials are among the most common and most exploitable security vulnerabilities in modern software. API keys, database passwords, authentication tokens, and private keys committed to source code are routinely discovered by attackers scanning public repositories - and by insiders with unintended access to private ones. DryRun Security's Secrets Analyzer is a specialized agent that runs on every pull request, examining code changes for signs of embedded credentials. Unlike tools that rely solely on pattern matching, the Secrets Analyzer goes a critical step further: it attempts to validate detected secrets to determine whether they are real and currently active. This verification step is a key differentiator - rather than flooding teams with alerts for every string that resembles a credential, DryRun Security confirms which secrets pose a genuine risk by testing them against the services they are meant to authenticate with. The analyzer also operates contextually, evaluating whether a candidate secret is genuine based on its surrounding context, variable naming, usage patterns, and code structure. Combined with active validation, this approach dramatically reduces false positives while ensuring that truly dangerous credentials are caught before they reach production. What Secrets Detection Covers The Secrets Analyzer detects a wide range of credential types, including: API keys and access tokens for cloud providers (AWS, GCP, Azure) and third-party services Database connection strings with embedded credentials Private keys (RSA, EC, SSH) Authentication tokens and session secrets OAuth client secrets Webhook secrets and signing keys Generic high-entropy strings that exhibit the statistical properties of cryptographic secrets --- # IaC Scanning URL: https://docs.dryrun.security/iac-scanning DryRun Security scans Terraform configurations for security misconfigurations and insecure defaults in pull requests. Overview DryRun Security provides Infrastructure as Code scanning focused on Terraform configurations. When a pull request modifies .tf files, DryRun Security analyzes the changes for security misconfigurations and flags findings as part of its PR scanning workflow. What It Detects IaC scanning identifies common Terraform security issues including: Overly permissive IAM policies - Roles granting broader access than required, violating least privilege Exposed resources - Security groups, firewall rules, or storage buckets with unintended public access Insecure defaults - Unencrypted data stores, disabled logging, or missing audit trails Subdomain takeover risks - Dangling DNS records or CDN configurations that could be claimed by an attacker Beyond the built-in IaC checks, teams can use Custom Code Policies to monitor additional infrastructure concerns. Custom policies let you enforce specific configuration requirements, flag unapproved resource types, or define any other infrastructure rules that matter to your organization. This extends IaC coverage to match your team's specific infrastructure security requirements. How Findings Appear IaC findings are reported the same way as other DryRun Security results: as comments on pull requests and as entries in the Risk Register dashboard. Each finding includes the affected resource, a description of the risk, and guidance on remediation. --- # Language and Framework Support URL: https://docs.dryrun.security/language-support Languages, frameworks, and package ecosystems supported across all DryRun Security scanning capabilities. DryRun Security supports a broad range of languages, frameworks, and package ecosystems across its scanning capabilities. Coverage varies by scanning mode: PR scanning and DeepScan analyze source code, while SCA analyzes dependency manifests and lock files. PR Scanning and DeepScan Both PR scanning and DeepScan support the same set of programming languages and frameworks. The scanner automatically detects the language and framework in use during analysis and tailors its review accordingly. Language Frameworks and Runtimes JavaScript / TypeScriptNode.js, React, Angular, Vue PythonDjango, Flask, FastAPI JavaSpring, Jakarta EE Go RubyRails, Sinatra PHPLaravel, Symfony C#.NET Kotlin Swift Rust SCA: Dependency Ecosystems Software Composition Analysis (SCA) runs as part of DeepScan and scans package manifests and lock files across all major package ecosystems. Each dependency is checked against known vulnerability databases, matching specific CVEs to affected version ranges. Ecosystem Manifest and Lock Files JavaScript / Node.jspackage-lock.json, yarn.lock Pythonrequirements.txt, Pipfile, pyproject.toml, poetry.lock, uv.lock RubyGemfile, Gemfile.lock Java / Kotlinpom.xml, gradle.lockfile, buildscript-gradle.lockfile, gradle/verification-metadata.xml Gogo.mod RustCargo.lock .NET*.csproj, deps.json, packages.config, packages.lock.json PHPcomposer.lock Automatic Language Detection DryRun Security automatically detects languages and frameworks in use during scanning. No manual configuration is required: the scanner profiles the repository structure, file extensions, and framework conventions to tailor its security analysis to your specific stack. For SCA, the scanner identifies all manifest and lock files present in the repository and checks each dependency against the appropriate vulnerability database for that ecosystem. --- # Vulnerability Coverage Matrix URL: https://docs.dryrun.security/vulnerability-coverage-matrix All finding types detectable by DryRun Security across PR scanning, DeepScan, and SCA, with CWE mappings. DryRun Security detects vulnerabilities across three scanning modes: PR scanning, DeepScan, and SCA. The categories below represent the full set of finding types surfaced across all scanning sources. CWE mappings are provided as reference anchors for each category. All Finding Types Category Description Example CWEs API Query InjectionImproper handling of user-controlled input in API queries that allows attackers to manipulate backend queries or filters.CWE-943, CWE-74 Authentication BypassFlaws that allow users to bypass authentication mechanisms and gain access without valid credentials.CWE-287, CWE-306 Missing Authorization ChecksEndpoints or functions that fail to enforce authorization, allowing users to access resources they should not.CWE-862 Business Logic FlawErrors in application logic that can be abused to gain unintended outcomes, even when traditional security controls are in place.CWE-840 Cache PoisoningManipulation of cache entries to serve malicious or incorrect content to other users.CWE-444, CWE-113 Configuration InjectionInjection of untrusted input into configuration files, environment variables, or runtime settings.CWE-15, CWE-20 Cryptographic WeaknessUse of weak, broken, or outdated cryptographic algorithms, keys, or practices.CWE-327, CWE-326 Cross-Site Request Forgery (CSRF)Actions performed on behalf of an authenticated user without their consent due to missing or weak CSRF protections.CWE-352 CSV InjectionInjection of spreadsheet formulas into CSV exports that execute when opened in spreadsheet software.CWE-1236 Email Header InjectionManipulation of email headers through unsanitized input, potentially enabling spam or phishing attacks.CWE-93 Excessive PrivilegesUsers, services, or tokens granted more permissions than required for their intended function.CWE-250, CWE-269 Hardcoded CredentialsCredentials such as passwords, API keys, or tokens embedded directly in source code.CWE-798, CWE-259 HTTP Header InjectionInjection of malicious content into HTTP headers due to improper input validation.CWE-113, CWE-93 Insecure Direct Object Reference (IDOR)Direct access to internal objects using user-controlled identifiers without proper authorization checks.CWE-639, CWE-284 Information DisclosureExposure of sensitive data such as secrets, internal paths, stack traces, or system details.CWE-200, CWE-209 Insecure Client StorageSensitive data stored insecurely on the client side, such as in local storage or cookies.CWE-922, CWE-312 Insecure DefaultsUnsafe default configurations that weaken security if not explicitly changed.CWE-276, CWE-1188 Insecure DeserializationDeserializing untrusted data in a way that allows code execution or data manipulation.CWE-502 Insecure File UploadFile upload functionality that allows malicious files or unrestricted file types.CWE-434 Insecure TransportUse of unencrypted or improperly secured network communication channels.CWE-319, CWE-295 Intent RedirectionUnvalidated or unsafe redirection logic that can be abused to send users to unintended destinations specifically in mobile applications.CWE-601 Language Version RiskUse of outdated or unsupported programming language versions with known security issues.CWE-1104 LLM Tool MisuseUnsafe or unintended use of large language model tools, including insecure prompt handling or tool invocation.CWE-20, CWE-74, CWE-1426 Log InjectionInjection of untrusted input into logs that can mislead monitoring systems or hide malicious activity.CWE-117 Mass AssignmentAutomatic binding of user input to object properties without restricting sensitive fields.CWE-915 Memory Safety IssueUnsafe memory operations that can lead to crashes, data corruption, or code execution.CWE-119, CWE-787, CWE-416 Network ExposureUnintended exposure of internal services, ports, or network resources.CWE-668 Open CORS PolicyOverly permissive Cross-Origin Resource Sharing policies that allow unintended access.CWE-942 Open RedirectRedirects that accept untrusted input, enabling phishing or malicious redirection attacks.CWE-601 Path TraversalManipulation of file paths to access files or directories outside the intended scope.CWE-22 Privilege EscalationFlaws that allow users or processes to gain higher privileges than intended.CWE-269, CWE-284 Prompt InjectionManipulation of LLM prompts that alters behavior, bypasses safeguards, or leaks sensitive data.CWE-77, CWE-74, CWE-913, CWE-1427 Prototype PollutionModification of object prototypes that can impact application logic or security.CWE-1321 Remote Code Execution (RCE)Flaws that allow attackers to execute arbitrary code on the host system.CWE-94, CWE-78 Resource ExhaustionOperations that can be abused to consume excessive CPU, memory, or other resources.CWE-400 SQL Injection (SQLi)Injection of malicious SQL queries through unsanitized input.CWE-89 Server-Side Request Forgery (SSRF)Ability to make server-side requests to internal or unintended external resources.CWE-918 Subdomain TakeoverDangling or misconfigured subdomains that can be claimed by attackers, as defined by Infrastructure as Code (IaC).CWE-668, CWE-284 Supply Chain RiskRisks introduced through third-party libraries, dependencies, or external services.CWE-1104, CWE-829 Terminal Escape InjectionInjection of terminal control characters that can manipulate terminal output or behavior.CWE-150, CWE-74 Time-of-Check Time-of-Use (TOCTOU)Race conditions where system state changes between validation and use.CWE-367 Timing Side ChannelInformation leakage through measurable differences in execution time.CWE-208 UI SpoofingUser interface elements designed to deceive users into taking unintended actions.CWE-451 User EnumerationAbility to determine valid users based on application responses.CWE-203, CWE-204 Vulnerable DependencyUse of third-party dependencies with known security vulnerabilities.CWE-937, CWE-1104 XML InjectionInjection of malicious XML content that alters processing or behavior.CWE-91 Cross-Site Scripting (XSS)Injection of malicious scripts that execute in a user’s browser.CWE-79 XML External Entity (XXE)XML parsing vulnerabilities that allow access to internal files or services.CWE-611 --- # Reporting URL: https://docs.dryrun.security/reporting The Reporting page provides a real-time view of your organization's security posture across every repository and pull request DryRun Security monitors, with overview metrics and trend charts scoped to a configurable time window. Overview The Reporting page provides a real-time view of your organization's security posture across every repository and pull request DryRun Security monitors. All metrics are scoped to a configurable time window - 24 hours, 7 days, 30 days, or 90 days - so security and engineering teams can evaluate both current state and longer-term trends. Overview Metrics Six summary tiles appear across the top of the Reporting page, giving an at-a-glance picture of activity and risk across the selected period. PRs Scanned The total number of pull requests DryRun Security analyzed in the selected window. This is your coverage signal - every PR that entered review was evaluated for security issues across the repositories connected to your account. Total Findings The cumulative number of security findings identified across all scanned PRs during the period. This represents the full volume of security signals your team is working through, spanning all severity levels and vulnerability classes. Merged PRs The total number of PRs merged during the period. Read alongside PRs Scanned and Merged PRs w/ Risk, this provides a clear picture of code velocity relative to security outcomes. Merged PRs w/ Risk PRs authored by a developer and merged while carrying at least one unresolved finding. This is a direct measure of residual risk entering your codebase. A low count relative to total merged PRs indicates your team is consistently resolving findings before code ships. Improvement Rate The percentage of scanned PRs flagged as improved during the selected period. A PR is considered improved when a finding identified in one scan is no longer present in the next scan of that same PR - meaning the developer addressed it within the review cycle, before merge. A high improvement rate indicates findings are being caught and fixed at the point of introduction rather than carried forward. Hardcoded Credentials A dedicated count of credential-related findings - API keys, tokens, secrets, and similar sensitive values - across all scanned PRs. Hardcoded credentials represent one of the highest-impact risks in any codebase and are surfaced separately so they remain visible regardless of overall finding volume. Charts Findings Over Time A stacked line chart tracking findings at each severity level - Critical, High, Medium, and Low - across the selected time window. Each line moves independently, so you can see whether risk is shifting between severity tiers over time, not just whether the total is going up or down. Findings by Repository A ranked view of which repositories are generating the most findings. This helps security and platform teams understand where risk is concentrated and prioritize remediation effort across the portfolio. Severity Distribution A breakdown of active findings by severity - Critical, High, Medium, and Low - with a count and percentage for each tier. The center of the chart shows the total. Use this to assess whether your open risk is weighted toward high-severity issues that need immediate attention or spread across lower-severity findings. Findings by Class A ranked breakdown by vulnerability type - such as Hardcoded Credentials, Cross-Site Scripting, SQL Injection, and others. Recurring patterns within a class often point to a shared dependency, an architectural pattern, or a training gap, making this view useful for identifying systemic issues beyond individual findings. Developer Activity A per-developer breakdown showing PRs opened and the subset of those PRs merged with at least one unresolved finding. This view helps AppSec and engineering leads understand how security habits are distributed across the team and where additional guidance may be needed. --- # Risk Register URL: https://docs.dryrun.security/risk-register One view to see, search, and act on all security risk across your organization. The Risk Register is the working space for AppSec engineers, designed to surface findings that need action taken. It aggregates findings from three sources: the PR Scanner, which reviews every pull request for vulnerabilities in real time; DeepScan, which performs full-repository security analysis on demand; and SCA, which continuously monitors third-party dependencies for known CVEs. Findings range from critical vulnerabilities and secrets exposures to policy violations and dependency risks. Because these findings represent real or potential security issues in your codebase, the Risk Register provides a single place to review, triage, and act on them before they become incidents. Common Workflows Reviewing Merged Risk Filter by “merged” PR status. This shows findings DryRun Security identified as containing a vulnerability but that were merged anyway, meaning the vulnerability lives in the codebase. These represent accepted or overlooked risk and should be reviewed to determine if remediation is needed. Triaging Open PRs Filter by “open” PR status. This surfaces findings on pull requests that are still open and have not been merged to main yet. Because the PR is still open, there is still time to fix the issue before it reaches production. These findings should be prioritized and actioned first. Draft PRs are also surfaced here. DryRun Security scans draft PRs and surfaces findings in the Risk Register, but does not post comments to the SCM until the PR is marked ready for review. Reviewing Dismissed Findings Filter to show dismissed findings. AppSec engineers can see who dismissed each finding and take appropriate follow-up action: override the dismissal if the finding represents real risk, reach out to the developer to help educate them, or stay informed about what is being marked as “won’t fix”, “nit pick”, or “false positive”. This workflow supports both risk oversight and developer security education. Search and Filter The Risk Register provides several ways to narrow your view: Search - A full-text search box lets you search across finding titles, file paths, repository names, PR titles, PR numbers, and other fields 30D date filter - Quickly scope findings to the last 30 days, or adjust the date range to match your review period Filter - Opens advanced filtering options to narrow by risk level, agent type (including Code Policy), status, and more Triage - Select one or more findings and triage them in bulk with a reason and optional context Findings Table The main findings table shows all findings with the following columns: ColumnDescription RiskSeverity label (Critical, High, Medium, Low) with color coding. Sortable. TypeThe vulnerability or finding description (e.g., "Authorization Bypass in Next.js", "Token Validation Check", "client-side-trust") FileThe file path where the finding was detected (e.g., package-lock.json, app/api/generate-vi..., firestore.rules) RepoThe repository name where the finding originated DetectedTimestamp showing when the finding was first detected (e.g., 03/18/26 16:51:18) AgentWhich agent produced the finding - SCA, Code Policy, DeepScan, or a specific Security Analyzer StatusThe status of the pull request associated with the finding: open, merged, draft, or closed Each row has a checkbox for bulk selection, and findings are paginated (e.g., "Showing 1-20 of 203 entries") with page navigation at the bottom. Clicking a finding row expands the inline detail view. This shows the full finding description alongside a code snippet at the exact location of the finding. For findings where DryRun Security has gathered support evidence, that context appears in the detail view alongside the finding. For DeepScan findings, the inline view includes application details surfaced during the scan, such as relevant framework context, data flows, and authentication patterns that informed the finding. --- # Code Security Intelligence URL: https://docs.dryrun.security/code-security-intelligence DryRun Security builds an intelligence layer on top of vulnerability findings and scan data, enabling actionable security workflows across your codebase and development organization. Overview DryRun Security takes vulnerability scanning to the next level by building an intelligence layer on top of all the finding data and trends from PR scanning, DeepScan, and SCA. This intelligence layer is actionable and enables AppSec teams to do meaningful security work beyond just reviewing individual findings, surfacing trends, patterns, risks, and insights across the entire codebase and development organization. Every pull request DryRun Security reviews, every DeepScan, and every SCA scan contributes to a structured, queryable intelligence index. This index powers a range of security workflows that would otherwise require manual data collection, spreadsheet tracking, and cross-referencing multiple tools. Intelligence Workflows The intelligence layer enables a range of security workflows. Each workflow draws on the findings and scan data DryRun Security continuously collects across your repositories. Workflow What It Shows Example Use Case Feature Ships Security posture of features shipped in a sprint or release, with risk annotations and PR links Summarize the security status of features shipped this sprint for a release review Resolved Risk Pull requests from the last 30 days that were merged after an identified risk was resolved, with links to the PR and the resolution Confirm that all findings identified in last sprint’s merged PRs were addressed before a release Vulnerability Trends Trending vulnerability patterns and coverage data across repos over time, including OWASP Top 10 mapping Compare critical finding counts quarter over quarter to measure security program effectiveness Architecture Risks Structural risk patterns in the codebase, including trust boundary changes, auth drift, and data flow modifications Identify new unauthenticated endpoints or service-to-service communication paths added this month Developer Trends Which teams or repos have recurring finding patterns, remediation velocity, and code change activity Determine which teams would benefit most from targeted security training based on finding patterns Shadow AI AI and LLM usage detected across the codebase: tool fingerprints, code pattern analysis, and volume anomalies Audit all AI-generated code contributions in security-critical paths for governance reporting Incident Response Queryable record of code changes, findings, and triage decisions for rapid incident investigation Trace which PR introduced a vulnerable dependency and assess blast radius during an active incident Application Summary Security profile of a specific service or application: open findings, scan coverage, and risk trends Generate an application security profile for a new team member onboarding onto a service Security Reviews Contextual security analysis results, business logic detection, and multi-model verification insights Investigate which findings required cross-file analysis to detect and would be missed by pattern matchers New Feature/Repo Review Precedent-based risk assessment for new features or repositories using historical findings Before building a new payment integration, review security findings from similar past implementations PR Variant Analysis Deep investigation of individual PR findings using the Insights AI assistant Click “Investigate” on a finding to explore its security implications interactively How to Access Insights Users interact with these intelligence capabilities through the Insights page, accessible from the top-level navigation in the DryRun Security app, in two ways: AI Assistant The Insights page has an AI assistant chat interface. Users can interact with it to generate security reports, feature ship summaries, risk assessments, and more, all grounded in real DryRun Security findings data. Simply describe what you want (e.g., “Create a security summary for the features shipped this week”) and the assistant generates it from your actual scan data. Example prompts: “What features shipped this sprint and what are their security implications?” “Show me the top vulnerability trends across my repos for the past quarter” “Which repos need the most attention right now?” “Generate an incident response summary for this vulnerability” “What AI coding tools are being used across our organization?” “Summarize the security posture of repo X” “Which PRs in the last 30 days were merged after a risk was resolved?” Because DryRun Security continuously scans every pull request and repository, these responses are grounded in real findings from your codebase, not generic checklists. They pull from live data, so the answers reflect your current state. Saved Queries Users can create and save custom queries in the Insights page for questions they return to regularly. For example: A report on new critical findings across all repositories A developer trend summary highlighting teams with the most new findings A risk overview comparing finding rates period over period A sprint-aligned feature ship summary for release reviews Saved queries stay available in the Insights page and can be run any time by selecting them from the query list. MCP Integration AppSec engineers and AI coding tools can also access the intelligence layer programmatically via DryRun Security's MCP integration. This enables AI coding assistants and agents to query findings, trends, and risk data directly from the development environment. See MCP Integration for setup instructions. --- # PR Scanning Configuration URL: https://docs.dryrun.security/pr-scanning-configuration Learn how DryRun Security configurations control scanning behavior, comments, blocking, and notifications across your repositories. DryRun Security configurations control how scanning, commenting, PR blocking, and notifications behave across your repositories. You can define one set of settings that applies to every repository in your organization, or create separate configurations for different repository groups, each with its own behavior. How Configurations Work The Configuration page in Settings has two parts: a Default Configuration and a list of Saved Configurations. The Default Configuration is always active and applies to every repository in your organization that DryRun Security monitors. It does not require any repository assignment. If you want consistent scanning behavior across your entire organization, edit the Default Configuration directly. Saved Configurations let you override the default for specific repositories. When you create a new configuration and assign repositories to it, those repositories move out of the Default Configuration scope and are governed exclusively by the new configuration. The Default Configuration continues to apply to all repositories not assigned to a saved configuration. A repository can only belong to one configuration at a time. If you only need one set of scanning rules for your entire organization, there is no need to create additional configurations. General Settings The General tab contains the core controls for PR scanning behavior. The Default Configuration and all saved configurations share the same settings. The one exception is the Repositories selector, which only appears on saved configurations: for a saved configuration you define which repositories it governs, while the Default Configuration applies to all unassigned repositories automatically. You can assign as many repositories as needed to a saved configuration; once assigned, those repositories move out of the Default Configuration scope. Issue Comments Issue Comments control whether DryRun Security posts a review summary to pull requests after scanning. Enable issue comments is the primary toggle. With comments enabled, DryRun Security posts a summary comment on each pull request after analysis, making findings visible to developers directly in their code review workflow. This is the recommended setting, as it is the primary way developers see and interact with DryRun Security findings. With comments disabled, DryRun Security still scans every pull request and records findings in the Risk Register, but does not post any comment to the SCM. The findings remain accessible in the DryRun Security dashboard, but developers will not see them in the pull request itself. Default comment behavior: When a pull request is scanned and has no findings, DryRun Security does not post a comment. A pull request with no DryRun Security comment means the scan ran and found nothing. Developers can confirm the scan ran by checking the status checks on the pull request. If a scan detects findings that are then resolved in a subsequent commit, DryRun Security automatically deletes the comment. Comments only appear when there are active findings to report. Show comment for no findings changes this behavior in two ways. First, when a scan completes with no findings, DryRun Security posts a comment confirming that no issues were detected. Second, when findings from a previous scan are resolved in a later commit, DryRun Security updates the comment rather than deleting it, so the pull request continues to show a DryRun Security comment reporting no active findings. PR Blocking PR Blocking allows DryRun Security to send a failing status check to your SCM when findings meet or exceed a configured severity threshold, preventing the pull request from being merged until those findings are resolved. Enable PR blocking activates this behavior for the configuration. When enabled, the Minimum blocking risk dropdown defines the threshold. Selecting High causes any High or Critical finding to produce a failing status check. Selecting Medium causes Medium, High, and Critical findings to block. Lower thresholds block at a broader range of severities. PR blocking requires branch protection to be configured in your SCM to enforce the status check. This applies to both GitHub Cloud and GitHub Enterprise Server (GHES) repositories. See PR Blocking for full setup instructions. Notifications The Notifications tab controls how DryRun Security delivers finding alerts and daily activity digests to your team's existing services via webhook. Finding Notifications Enable notifications activates outbound webhook delivery for this configuration. When enabled, DryRun Security sends a notification to the configured webhook endpoint whenever a PR scan produces findings at or above the minimum severity threshold. Webhooks defines where notifications are delivered. You must select a webhook endpoint that has already been created. If you have not set one up yet, configure it in Webhooks settings first and then return here to select it. See Webhooks for setup details. Minimum Severity sets the threshold for triggering a notification. Options are None, Critical, High, Medium, and Low. This is a waterfall threshold: selecting High triggers notifications for High and Critical findings; selecting Medium triggers notifications for Medium, High, and Critical findings. Selecting None triggers a notification when a scan completes with no risk detected, which is useful for teams that want confirmation of a clean scan alongside findings-based alerts. When a notification is triggered, DryRun Security sends a summary of the findings along with a link back to the dashboard. Deduplicate Notifications Deduplicate notifications is off by default. With deduplication disabled, DryRun Security sends a notification on every PR scan that produces findings at or above the minimum severity. When a developer pushes a new commit to an open PR, a new scan runs and a new notification fires, even if the findings have not changed. On active pull requests this can become noisy. With deduplication enabled, DryRun Security compares the highest severity on the current scan to the highest severity from the previous scan on the same PR. If the severity has not increased, no new notification is sent. If the severity has increased, for example a PR that previously had a High finding now also has a Critical, a new notification is triggered because the risk level of the PR has changed. Daily Digest Enable daily digest activates a once-daily summary of scanning activity across all repositories in this configuration. The digest is generated by DryRun Security's AI and captures a snapshot of what was analyzed during the day, including new vulnerabilities introduced, changes to authentication-related code, and other notable activity patterns across the scanned repositories. The daily digest is delivered to a webhook endpoint. You can select the same webhook used for finding notifications or choose a different endpoint. Context The Context tab lets you attach context documents to a configuration, supplementing DryRun Security's built-in contextual scanning with additional security and environmental information about your repositories. Context documents are Markdown files that describe security-relevant details about your repositories: custom authentication patterns, internal libraries, known trusted code paths, or other environmental information that helps DryRun Security's AI produce more accurate and relevant findings. They are created and managed on the Repository Context page. Once a context document exists, select it from the Add context document dropdown. The selected context is applied to every repository covered by this configuration during scanning. For more on how contextual scanning works and how to create context documents, see Repository Context. Code Policies The Code Policies tab lets you attach Custom Code Policies to this configuration. Code policies are custom security rules written in plain English that run as additional checks on top of DryRun Security's built-in Code Security Agents. They are created and managed on the Custom Code Policies page. A configuration supports up to seven code policies. Select from your organization's available policies using the Add Code Policy dropdown. Each attached policy runs on every repository in this configuration. Each attached policy has three configuration options: Blocking controls whether a violation of this policy sends a failing status check to your SCM. This works differently from the severity-based PR blocking setting on the General tab. Severity-based PR blocking evaluates findings from Code Security Agents against a minimum severity threshold. Code policy blocking is binary: if this policy produces any finding, a failing check is sent regardless of severity. Branch protection must be enabled in your SCM for the check to prevent merging. Silent mode controls whether this policy's findings appear in the DryRun Security PR comment posted to the developer. With silent mode on, the policy still runs on every scan, findings still appear in the Risk Register, and if blocking is enabled the failing status check is still sent. Silent mode only suppresses the policy's output from the PR comment visible to the developer. This is useful for testing a new policy against real PRs before surfacing its findings to developers. Risk level defines the severity assigned to every finding this policy produces. Options are Critical, High, Medium, and Low. All findings from this policy are assigned this severity label uniformly. Code Security Agents The Code Security Agents tab lists every built-in analyzer that DryRun Security runs on pull requests. Each analyzer can be configured independently with Blocking and Silent mode controls. AnalyzerDescription Cross-Site Scripting AnalyzerDetects XSS vulnerabilities across rendering contexts General Security AnalyzerBroad-spectrum analyzer covering auth gaps, crypto, debug artifacts, and more IDOR AnalyzerSurfaces broken object-level authorization Mass AssignmentDetects unsafe model binding patterns Secrets AnalyzerCatches committed credentials, API keys, and tokens Server-Side Request Forgery AnalyzerIdentifies SSRF via user-controlled outbound requests SQL Injection AnalyzerTraces data flow to detect unsafe query composition Blocking can be enabled per analyzer. This is distinct from the severity-based PR blocking on the General tab, which fires when any finding across all agents meets or exceeds a minimum severity threshold. Per-analyzer blocking is binary: if this analyzer finds anything on a PR, a failing status check is sent to your SCM regardless of the finding's severity. Branch protection must be enabled in your SCM for the check to prevent merging. For most teams, severity-based blocking on the General tab is the recommended approach. Per-analyzer blocking is available for situations where a specific class of vulnerability should always block, independent of how it is scored. Silent mode suppresses this analyzer's findings from the PR comment posted to the developer. With silent mode on, the analyzer continues to run and its findings are still recorded in the Risk Register. If blocking is also enabled, the failing status check is still sent. Only the PR comment is affected: if the silent analyzer was the only one to produce findings on a given PR, the PR comment will not surface those findings even though they are visible in the Risk Register. Once all settings across the tabs are configured, click Save. The configuration takes effect on the next scan of each repository assigned to it. --- # Custom Code Policies URL: https://docs.dryrun.security/custom-code-policies Create custom security rules in plain English using Custom Code Policies. Custom Code Policies DryRun Security's Custom Code Policies let you define and enforce security policies in your codebase using natural language instead of complex scripting or specialized rule languages. Rather than writing regex patterns or static analysis rules, you describe what you care about in plain English and the LLM reasons through the code to evaluate it. The key advantage of Custom Code Policies is that they are agentic. The LLM does not simply pattern-match against your code. Instead, it reasons about the code in context. It can follow function calls, trace data flow, understand business logic, and make judgments that traditional static analysis tools cannot. This means your policies can go far beyond what is possible with grep-style rules or AST matchers. Custom Code Policies can be laser-focused on a unique function or structure specific to your application. Because you control the context (through the Question, Background, and Guidance fields), you can guide the analysis to look exactly where it matters and reason about the patterns that are unique to your codebase. When a pull request is opened, DryRun Security's Policy Enforcement Agent runs all configured Custom Code Policies for the repository. The Policy Enforcement Agent can run up to 7 code policies per repository. Results appear in the PR comment and in the GitHub Checks area, with the option to block merges when a policy has findings. Use Cases 1. Identifying specific vulnerabilities unique to your codebase Custom Code Policies can find security issues that generic scanners miss, including vulnerabilities tied to your application's specific architecture, patterns, or business logic. Because the LLM reasons through your code agenetically, it can identify risks that only make sense in the context of how your application actually works. For example, a Custom Code Policy could detect an authentication bypass that only exists because of how your specific auth model chains middleware, or flag an injection risk in a custom query builder that is unique to your application. These are the kinds of vulnerabilities that generic scanners overlook because they lack the context of your particular codebase. 2. Monitoring for non-vulnerability changes Custom Code Policies are not limited to security vulnerabilities. They can detect any type of change you want to monitor, including compliance checks, procedural guardrails, and architectural standards. For example, you can create policies that detect when a regulated data model is modified, flag the use of deprecated internal APIs, or monitor for changes to configuration files that require a review process. This makes Custom Code Policies a flexible tool for enforcing organizational standards beyond traditional security scanning. Creating a Policy Using the AI Assistant The AI assistant provides a chat interface where you simply explain the type of vulnerability or change you want to monitor for. The assistant will ask you clarifying questions to understand your intent and gather the context needed. When you're ready, tell it to create the policy and it will automatically fill out all the related fields for you. This is the recommended approach for most users. Manual Creation For users who prefer direct control over every field, policies can be created manually: Log in to the DryRun Security portal at https://app.dryrun.security. Navigate to the Code Policies section. You'll see a list of previously saved Code Policies. Click Add New Code Policy. You'll see the Code Policy Builder, which can be used to evaluate and save a Custom Code Policy. Enter a Name for the policy. Choose a Repository and Pull Request to evaluate. Enter the Custom Code Policy details: Question (required): A natural language question that identifies whether a specific change relates to the policy. For example, "Does this change expose any sensitive data?" Background (optional): Background information or examples that may be used to refine the evaluation. For example, "We are concerned about..." Guidance (optional): Additional information on actions to take when the policy condition is met. Click Run to see the results of the Code Policy evaluation. Once the policy is returning expected results, click Save to save it for use in a Repository configuration. To apply the Code Policy to one or more repositories, click Configure and follow the steps in Configure Repositories. Field Usage Question The question field is the prompt given to the LLM that triggers it to begin investigating for the vulnerability. This field should contain a series of things you want the model to check for or validate against. Think of it as the investigation directive: it should be specific enough to focus the analysis but broad enough to cover the relevant variations of the issue you want to catch. Background The background field provides context that loads alongside the question, giving the LLM the background information it needs to properly assess the code it is reviewing for this vulnerability type. Use this field to provide factual details about your app’s function, architecture, authentication handling, data flow, or other dynamics. Do not tell the LLM what you want it to do here. Just provide factual details about your application so the model has the context it needs to make accurate assessments. Guidance The guidance field contains the instructions that the LLM will deliver to your development team when a vulnerability is identified by the code policy. This text appears as a comment in your SCM (GitHub, GitLab, etc.) on the relevant PR, so it should be written as actionable remediation instructions, telling developers exactly what to fix and how. --- # Repository Context URL: https://docs.dryrun.security/repository-context Repository context lets teams share application-specific knowledge with DryRun Security's agents - covering architecture decisions, accepted patterns, and security controls that exist outside the code itself. DryRun Security automatically scans active repositories in the background to build and maintain repository context, keeping PR analysis working from up-to-date knowledge of your codebase without any configuration required. You can also add your own context to give DryRun Security's agents a deeper understanding of application-specific details that exist outside the code itself, covering architecture decisions, accepted patterns, and security controls. DryRun Security supports two ways to do this: a context managed in the dashboard, or an AGENTS.md file committed directly to the repo. Note: Dashboard context and AGENTS.md do not apply to Code Policies. To add context to a Code Policy, use the Background field in the Code Policy configuration directly. Context in the Dashboard The DryRun Security dashboard includes a Context section where you can create and manage context without committing anything to the repository. A context is a settings file that captures the security-relevant details of your application - similar to the Security Review Guidelines section of an AGENTS.md - and can be applied to one or many repositories at once through a configuration. Once a context is saved, it can be applied to a configuration. To create a context: Log in to the DryRun Security dashboard at app.dryrun.security Select Context from the left-hand navigation Create a new context, give it a name, and add your repository context Once saved, apply it to a configuration under Settings > Configurations - or follow the prompt to go there directly from the Context section AGENTS.md AGENTS.md is a format supported by the Agentic AI Foundation, a Linux Foundation Project. The file is intended to be "a predictable place to provide the context and instructions to help AI coding agents work on your project." DryRun Security supports AGENTS.md for both core analyzer products: the Code Review Agent and the DeepScan Agent. DryRun Security's agents will look for and review this file to apply the additional context it provides during analysis. Some teams prefer AGENTS.md over the dashboard context because it keeps context management in the repository itself. Developers can review and update it alongside the code, without needing to log in to the DryRun Security dashboard. Note: The Code Review Agent checks for AGENTS.md in the root. The DeepScan Agent can discover both root and nested AGENTS.md files. To best leverage this, add a Security Review Guidelines section to your AGENTS.md with any context related to design assumptions, areas of particular security interest, or other relevant points for an agentic security reviewer. When to Use Context Repository context works best when DryRun Security needs more information about your application to assess findings accurately. If a class of finding keeps appearing because DryRun Security is not aware of a specific pattern, architectural decision, or security control in your codebase, adding context is the right fix. It teaches the system how your application works so that every future scan benefits from that understanding - rather than managing each instance of that finding one at a time. Good candidates for a context update: A vulnerability class that keeps surfacing because of a known, accepted pattern in your codebase (e.g., intentionally public routes, TLS handled upstream) Authorization or authentication behavior that does not follow standard patterns but is correct by design Security controls that exist outside the code and are not visible to a scanner (e.g., WAF rules, middleware, infrastructure-level protections) If DryRun Security already has the right context but a specific finding is incorrect or not relevant to your team, that is outside the scope of repository context. The finding tuning page covers how to mark findings as false positives. What to Include Both methods support the same types of context. The following are useful starting points for a Security Review Guidelines section: Structure of a monolith, and how authorization works between components Collections of routes or controllers that do not follow typical authorization patterns by design Specific security requirements coding assistants need to validate against during code generation Assumptions about security-impacting configurations not clear in code (e.g., TLS offloading, WAF rules) Specific security patterns that must be followed, with examples of allowed and disallowed code snippets Example Security Review Guidelines Section ## Security Review Guidelines ### Device Trust for internal routes All routes that are prefixed with /abc123 are to be recognized as internal-only routes, and require the use of trusted devices issued by the enterprise. Device trust is recognized by an Okta device token, and these routes are verified within Okta for proper authorization scopes from the IdP and authorization server, which will not be checked by the application layer specifically. Row or object-level authorization issues related to this pattern only for these internal routes can be ignored as accepted. ### Intentionally Public Routes Some controllers have embedded routes with authentication and authorization decorators disabled or skipped on purpose for public facing content. The routes are intended to allow anonymous access to these features ONLY IF the specific controller action does not perform edits or require write access. Validate the read- only nature of these endpoints and flag any actions that enable write behavior when the authentication decorations are skipped. ### Ignore HTTPS related issues on cookies and configuration files This application is always deployed to a kubernetes cluster as a mesh service. TLS offloading is provided in front of the application. Ignore any issues related to Cookies missing Secure flags, requiring HTTPS in build configurations, or certificate requirements in this application. --- # Finding Tuning with Feedback URL: https://docs.dryrun.security/finding-tuning Tune security findings and reduce false positives with feedback from developers and AppSec engineers. Developers and AppSec engineers can dismiss findings directly from the PR thread or the Risk Register dashboard. Every dismissal is logged for audit. Dismissals marked as False Positive or Won’t Fix / Nitpick also feed back into the model, improving scan accuracy over time. Dismissal Statuses Status Description Available From LLM Learning False Positive The finding is not real or does not apply to the codebase. DryRun Security fingerprints the pattern and suppresses it in future scans. Context provided improves detection accuracy across similar patterns over time. PR comment and Risk Register Yes Won’t Fix / Nitpick The finding is valid but below the bar the team cares about, or the team has decided not to fix it. Feeds back into the model to reduce similar noise over time. PR comment and Risk Register Yes Accepted Risk The team knowingly accepts the risk and will not remediate it. Removed from the active view and SCM comment. Documented in the audit trail with the reason and who accepted it. Risk Register No In Progress A fix is planned but not yet applied. Removed from the active view and SCM comment. DryRun Security resolves it once the fix is applied. Risk Register No Resolved The finding has been addressed. Removed from the active view and SCM comment. Risk Register No False Positive and Won’t Fix / Nitpick dismissals feed into the Code Security Knowledge Graph, building a model of your codebase’s specific patterns and risk profile. Scan accuracy improves continuously as your team triages findings. From the PR Developers can dismiss findings directly from the pull request thread without leaving their workflow. Dismissals sync to the Risk Register for AppSec review. To mark a finding as a false positive: @dryrunsecurity FP [issue ID] details why To mark a finding as a nitpick: @dryrunsecurity NIT [issue ID] details why When a developer submits a dismissal, DryRun Security removes the finding from the active list, regenerates the PR summary comment, logs the decision for the audit trail, and feeds the signal back into the system. If a finding is incorrectly blocking a merge via branch protection rules, developers can dismiss it directly in the PR thread. DryRun Security automatically removes the block without requiring AppSec intervention. The dismissal is logged so AppSec can review it afterward. From the Risk Register AppSec engineers manage dismissals from the Risk Register, which provides a centralized view across all repositories and scan types. Select one or more findings using the checkboxes, then click Dismiss to choose a status and optionally add context. Dismissing a finding as False Positive or Won’t Fix / Nitpick from the Risk Register also removes the associated failed SCM check on the pull request, clearing the block automatically. Accepted Risk, In Progress, and Resolved dismissals do not automatically clear the SCM check. From the Risk Register, AppSec teams can also: Override dismissals when a finding represents real risk that was incorrectly dismissed Monitor dismissal patterns across the organization to identify trends Use the audit trail to confirm all triage decisions are intentional and documented Dismissed Findings View dismissed findings in the Risk Register using the Dismissed filter. Each entry shows the dismissal status, reason, who dismissed it, and when. Use the Restore button to return a finding to the active queue if the dismissal needs to be revisited. When a finding is valid but mitigating circumstances exist: Sometimes your team knows DryRun Security is right about a finding, but another layer of protection already addresses it. Rather than marking it as a false positive, the right resolution is to update your AGENTS.md with the context that explains why. This tells DryRun Security about the mitigating control so it does not raise the same class of issue again, without misrepresenting the finding as invalid. See Repository Context for details. --- # PR Blocking URL: https://docs.dryrun.security/pr-blocking Configure DryRun Security to block pull requests when critical vulnerabilities are detected. Overview DryRun Security can be configured to block pull requests from being merged when security findings exceed your defined thresholds. PR Blocking integrates with your source code management platform’s native branch protection features to enforce security gates in your development workflow. How It Works When PR Blocking is enabled, DryRun Security reports its scan results as a required status check on each pull request. If findings meet or exceed the configured severity threshold, the check is marked as failed, preventing the PR from being merged until the issues are resolved. PR Blocking can be configured at three levels within a Configuration: Severity-based blocking (General tab): the primary mechanism. Enabling PR blocking and setting a Minimum blocking risk threshold sends a failing status check when any Code Security Agent produces a finding at or above that severity. This is a waterfall threshold - setting it to High blocks on High and Critical findings; Medium blocks on Medium, High, and Critical. Per-analyzer blocking (Code Security Agents tab): enabling Blocking on a specific analyzer sends a failing status check whenever that analyzer produces any finding, regardless of severity. Per-policy blocking (Code Policies tab): enabling Blocking on a specific Custom Code Policy sends a failing status check whenever that policy produces any finding, regardless of severity. For most teams, severity-based blocking is the recommended approach. Per-analyzer and per-policy blocking exist for cases where a specific analyzer or policy should always gate merges. Configuring PR Blocking Enabling PR Blocking requires two steps: configuring the blocking threshold in DryRun Security, and configuring branch protection in your SCM to require the DryRun Security status check before merging. Step 1 - Configure blocking in DryRun Security Blocking is enabled from the PR Scanning Configuration page. The General tab controls severity-based blocking across all analyzers. The Code Security Agents and Code Policies tabs let you enable blocking on individual analyzers or policies. See PR Scanning Configuration for a full walkthrough of each option. Step 2 - Configure branch protection in your SCM Once blocking is enabled in DryRun Security, your SCM must be configured to require the corresponding status check before a PR can merge. There are two approaches depending on how broadly you want to apply the rule. Configure Blocking on GitHub These steps apply to both GitHub.com and GitHub Enterprise Server (GHES). Best Practice: Organization Rulesets For teams scanning all repositories, configuring branch protection at the organization level is the recommended approach. An organization ruleset can be configured to apply to all repositories, including new ones added in the future, without requiring per-repo configuration. In your organization settings, navigate to Repository > Rulesets. Click New ruleset and give it a name. Set Enforcement status to Active. Optionally configure scope exclusions for users or teams that should be exempt from the rule. Under Repository targeting, set the scope -- you can target all repositories, by name pattern, by visibility, language, fork status, and more. Under Target branches, choose which branches are protected -- default branch, all branches, or by pattern. Enable Require status checks to pass before merging. Under Status checks that are required, click Add checks, enter DryRun as the check name, and select DryRunSecurity as the source. Adding Classic Branch Protection to a Specific Repository To apply branch protection at the repository level -- for example, to target only a subset of repositories -- use a classic branch protection rule. On GitHub, navigate to the main page of the repository. Under your repository name, click Settings. In the Code and automation section of the sidebar, click Branches. Click Add classic branch protection rule. Under Branch name pattern, type the name of the branch to protect (e.g., main). Enable Require status checks to pass before merging. Search for and select the DryRun Security checks you want to require: Check nameWhat it covers Cross-Site Scripting AnalyzerXSS vulnerabilities across rendering contexts General Security AnalyzerAuth gaps, crypto issues, debug artifacts, and more IDOR AnalyzerBroken object-level authorization Mass AssignmentUnsafe model binding patterns Secrets AnalyzerCommitted credentials, API keys, and tokens Server-Side Request Forgery AnalyzerSSRF via user-controlled outbound requests SQL Injection AnalyzerUnsafe query composition Code PoliciesAll custom code policies configured for your team When a Custom Code Policy has Blocking enabled, it appears as a single check under Code Policies. When a Code Security Agent has blocking enabled, it appears under the agent’s name (e.g., Secrets Analyzer). Click Create. Configure Blocking with GitLab Merge Request Rules When DryRun Security scans a merge request and blocking is enabled, it reports a failed pipeline status on that MR. Enabling Pipelines must succeed in GitLab prevents a merge from completing when any pipeline job fails, including DryRun's scan. Unlike GitHub, GitLab does not support selecting specific checks. The setting applies to all pipeline jobs. Best Practice: Group-level Settings Configuring the setting at the group level applies it to all projects in the group, including new ones added in the future. In your group, go to Settings > General. Expand Merge requests. Under Merge checks, enable Pipelines must succeed. Enable Skipped pipelines are considered successful to prevent MRs from being blocked when a pipeline is skipped rather than failed. Save changes. Targeting Specific Projects To apply the requirement to individual projects: In the project, go to Settings > Merge requests. Under Merge checks, enable Pipelines must succeed. Enable Skipped pipelines are considered successful. Save changes. Override Workflow When a finding is dismissed as False Positive or Won’t Fix / Nitpick, DryRun Security automatically clears the failing SCM check on the associated pull request. The block lifts as soon as the dismissal is processed, whether submitted from the PR thread or the Risk Register. Dismissals marked as Accepted Risk, In Progress, or Resolved do not clear the SCM check. The pull request remains blocked until the finding is dismissed as False Positive or Won’t Fix / Nitpick. All dismissal decisions are logged in the Risk Register for audit purposes. --- # Permissions URL: https://docs.dryrun.security/permissions Understand the two-role permission model in DryRun Security and how SCM platform roles map to Admin and Developer access. Overview DryRun Security uses your SCM platform (GitHub or GitLab) for authentication. Because DryRun already knows your SCM role at login, it maps that role directly to a DryRun permission level with no additional setup required. GitHub Enterprise Server (GHES) follows the same permission model as GitHub Cloud. Anywhere this page refers to GitHub, it applies equally to GHES. DryRun uses a two-role model: Admin and Developer. To give a user more access, you can either elevate their permissions in the SCM, or request an Admin Override (see the Admin Override section below). Permissions Matrix Note: Developers can only view findings, repositories, and pull requests for repositories they have membership access to in GitHub or GitLab. All other access listed below applies to the full platform. FeatureAdminDeveloperDetails Install✓✗Install DryRun Security on GitHub or GitLab organizations and repositories. Risk Register✓✓Central view of security findings across repositories, organized by severity and status. Developers see findings only for repos they have membership access to. Repositories✓✓View repositories connected to DryRun Security and their scan status. Developers see only repos they have membership access to. Pull Requests✓✓View pull requests and their associated security findings. Developers see only PRs for repos they have membership access to. Dismiss Findings✓✓Dismiss a finding from the DryRun dashboard or directly from the SCM PR comment. DeepScan: View✓✓View DeepScan runs, reports, and findings for repositories. DeepScan: Trigger✓✗Initiate a new DeepScan run on a repository on demand. Code Policies: View✓✓View existing custom code policies configured for the account. Code Policies: Configure✓✗Create, edit, and manage custom code policies used during scanning. Insights & AI Assistant✓✗AI-powered security insights and a chat assistant for querying findings and trends. Daily Digest✓✗Automated daily summary of new findings, trends, and security posture changes. Configurations: View✓✓View PR scanner behavior, blocking rules, and policy enforcement settings. Configurations: Edit✓✗Edit PR scanner behavior, blocking rules, and policy enforcement settings. Integrations: View✓✓View connected integrations including Slack, webhooks, and AI coding integrations (MCP/IDE). Integrations: Configure✓✗Set up and manage Slack, webhook, and AI coding integrations (MCP/IDE). Access Keys✓✗Generate and manage API access keys for programmatic access to DryRun Security. Install / Uninstall Repos✓✗Add or remove repositories from DryRun Security scanning. SCM Role Mapping DryRun Security automatically maps SCM roles to DryRun roles at login. No manual configuration is required. SCM PlatformSCM RoleDryRun Role GitHubAdminAdmin GitHubMemberDeveloper GitLabOwnerAdmin GitLabMaintainerAdmin GitLabDeveloperDeveloper Admin Override An account administrator can request that a developer be promoted to Admin within the platform. This setting is not self-serve and is managed by our team. The override applies only within DryRun Security and does not change the user's role in GitHub or GitLab. To request an override, contact us at hi@dryrun.security. --- # MCP URL: https://docs.dryrun.security/mcp Connect AI assistants to DryRun Security insights using the Model Context Protocol for natural language queries about your security data. The DryRun Security Insights MCP (Model Context Protocol) server gives AI assistants direct access to your organization's security data. Once connected, your AI coding tool can query findings, trends, pull request context, and Code Security Intelligence results in natural language, without leaving your development environment. What You Can Do With the Insights MCP connected, your AI assistant can: Generate summaries of recent security activity across your repositories Query findings for a specific pull request or file Ask natural language questions about your security posture (for example: "Have any new payment integrations been introduced in the last week?") Access Code Security Intelligence trends and agent stats Surface pull requests from the last 30 days that were merged after an identified risk was resolved Track security posture changes over time For the full list of Code Security Intelligence capabilities, see Code Security Intelligence. Supported Clients The following AI coding tools support the DryRun Security Insights MCP: ToolConnection method CursorHTTP MCP config CodexHTTP MCP config Claude CodeCLI (claude mcp add) Claude DesktopSettings > Connectors WindsurfHTTP MCP config VS CodeHTTP MCP config For step-by-step setup instructions for each tool, go to Settings > Integrations in the DryRun Security dashboard, or see DryRun Skill. Authentication The MCP server uses API key authentication. Pass your API key as a Bearer token in the Authorization header. Before connecting, generate an API key from Settings > Access Keys in the DryRun Security dashboard. See API Access Keys for instructions. The MCP server URL is: https://insights-mcp.dryrun.security/api/insights/mcp Configuration Claude Code (CLI) claude mcp add --transport http dryrun-security https://insights-mcp.dryrun.security/api/insights/mcp --header "Authorization: Bearer <your-api-key>" HTTP JSON Config (Cursor, Windsurf, VS Code, Codex) { "mcpServers": { "dryrun-security": { "type": "http", "url": "https://insights-mcp.dryrun.security/api/insights/mcp", "headers": { "Authorization": "Bearer <your-api-key>" } } } } Claude Desktop Navigate to https://claude.ai Select Settings Select Connectors Click Add custom connector Enter the URL: https://insights-mcp.dryrun.security/api/insights/mcp Select Add Replace <your-api-key> with the key from Settings > Access Keys. See API Access Keys. DryRun Remediation Skill In addition to the MCP connection, you can install the DryRun Security remediation skill into your AI coding tool. The skill enables the tool to automatically detect findings and generate fixes. See DryRun Skill for installation instructions. Verifying the Connection Once configured, confirm the DryRun Security Insights tool is available in your AI assistant's toolset. Try asking: "What is my insights summary for the past week?" If you encounter any issues, reach out at hi@dryrun.security. --- # DryRun API URL: https://docs.dryrun.security/dryrun-api Programmatic access to DryRun Security findings, scans, configurations, and insights via the Simple API. DryRun Simple API The DryRun Simple API provides programmatic access to your organization's security data: findings, scans, deepscans, configurations, repositories, and insights. Swagger UI: https://simple-api.dryrun.security/api-docs/index.html OpenAPI (v3.0) spec: https://simple-api.dryrun.security/api-docs/v1/swagger.yaml Base URL: https://simple-api.dryrun.security/v1 Authentication For information on creating and managing API keys, see the API Access Keys page. All API requests require a valid API key sent in the Authorization header using the Bearer scheme. Quick Start Most endpoints are scoped to an account. You will need: account_id - provided by the DryRun Security platform (e.g., 12345678-1234-1234-1234-1234567890ab) repository_id - a UUID for a repository Typical workflow: List your accessible accounts. Pick an account, then list repositories in that account. Use repository IDs to fetch scans and findings. Step 1: List accounts curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts" Example response: { "data": [ { "account_id": "22222222-2222-2222-2222-222222222222", "org_name": "SampleOrg", ... } ] } Step 2: Get repositories curl -X 'GET' \ -H 'Authorization: Bearer $DRYRUN_API_KEY' \ 'https://simple-api.dryrun.security/v1/accounts/22222222-2222-2222-2222-222222222222/repositories' Example response: { "data": [ { "id": "11111111-1111-1111-1111-111111111111", "name": "some-demo-repo-name", ... } ] } Step 3: Get findings for a repository curl -X 'GET' \ -H 'Authorization: Bearer $DRYRUN_API_KEY' \ 'https://simple-api.dryrun.security/v1/accounts/22222222-2222-2222-2222-222222222222/repositories/11111111-1111-1111-1111-111111111111/findings' Example response: { "data": [ { "id": "00000000-0000-0000-0000-000000000000", "dashboard_url": "https://app.dryrun.security/risk-register/44444444-4444-4444-4444-444444444444", "severity": "error", "type": "Missing Authorization and IDOR in User Deletion", "description": "The new DELETE /users/{id} endpoint is registered without any authentication or authorization middleware...", "filename": "backend/main.go", "line_start": 516, "line_end": 553, "created_at": "2026-03-03T00:00:00Z" }, ... ] } Endpoint Reference Accounts GET /v1/accounts List all accounts accessible by the API key. Retrieve all accounts that the authenticated API key has access to, including organization information. Responses 200 - accounts listed Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts" Repositories GET /v1/accounts/{account_id}/repositories List all repositories for an account. Retrieve all repositories associated with the specified account. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID Responses 200 - repositories listed Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/repositories" Scans GET /v1/accounts/{account_id}/repositories/{repository_id}/scans List PR scans for a repository. List PR scans for a repository. Supports filtering by PR number, date range, severity, result, PR status, and the user who initiated the scan. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID repository_idpathyesstringRepository ID pr_numberquerynointegerFilter by pull request number date_fromquerynostring (ISO 8601)Return scans on or after this date date_toquerynostring (ISO 8601)Return scans on or before this date severityquerynostringFilter by highest severity finding: critical, high, medium, low, none resultquerynostringFilter by scan result: pass or fail initiated_byquerynostringFilter by the username or email of the user who triggered the scan pr_statusquerynostringFilter by pull request status. Comma-separated values: open, draft, closed, merged Response Fields FieldTypeDescription scan_idstringUnique identifier for the scan dashboard_urlstringLink to the scan results in the DryRun Security dashboard pr_numberintegerPull request number pr_titlestringTitle of the pull request pr_statusstringCurrent status of the pull request: open, draft, closed, or merged scan_datestring (ISO 8601)Date and time the scan was completed initiated_bystringUsername or email of the user who triggered the scan statusstringScan status: pass or fail summarystringShort plain-text summary of scan results vulnerability_summaryobjectCounts of findings by severity: critical, high, medium, low risk_thresholdstringThe highest-severity finding that caused the scan to fail, if applicable severitystringHighest-severity finding on the scan: none, low, medium, high, critical. Null if the scan is still in progress. pull_request_dashboard_urlstringLink to the pull request in the DryRun Security dashboard. Responses 200 - scans listed Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/repositories/{repository_id}/scans?pr_number=42" GET /v1/accounts/{account_id}/repositories/{repository_id}/scans/{id} Get detailed PR scan results including findings. Get detailed results for a specific PR scan, including all findings. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID repository_idpathyesstringRepository ID idpathyesstringScan ID Response Fields FieldTypeDescription severitystringHighest-severity finding on the scan: none, low, medium, high, critical. Null if the scan is still in progress. pull_request_dashboard_urlstringLink to the pull request in the DryRun Security dashboard. Responses 200 - scan found Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/repositories/{repository_id}/scans/{id}" Findings GET /v1/accounts/{account_id}/repositories/{repository_id}/findings List all PR findings for a repository. List all PR findings for a repository. Each finding includes a dashboard_url linking to the finding in the DryRun Security dashboard, and a pull_request_dashboard_url linking to the associated pull request. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID repository_idpathyesstringRepository ID Responses 200 - findings listed Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/repositories/{repository_id}/findings" GET /v1/accounts/{account_id}/all_findings List all findings across PR scans, DeepScans, SCA, and code policies for an account. List all findings across PR scans, DeepScans, SCA, and code policies for an account. By default, returns only findings from the latest scan. Results are sorted by newest first. Each finding includes a state field indicating its current status: open (present in the latest scan and not triaged), dismissed (triaged with a category such as false positive or accepted risk), or resolved (no longer present in the latest scan). For triaged findings, the response also includes a triage object with the category (false_positive, wont_fix, accepted_risk, in_progress) and category_name. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID daysqueryyesintegerFilter to findings from the last N days (1-365) finding_typequerynostringFilter by finding type. One of: deepscan, pullrequest, sca, code_policy, all. Defaults to 'all' severityquerynostringFilter by severity (comma-separated: critical, high, medium, low) repository_idquerynostringFilter by repository ID branchquerynostringFilter SCA and DeepScan findings by branch name. When omitted, returns findings from the default branch. Does not affect PR or code policy findings. all_resultsquerynobooleanWhen true, returns all findings including historical scans. Defaults to false (latest scan only). pagequerynointegerPage number (default: 1) per_pagequerynointegerResults per page (default: 50, max: 100) Responses 200 - findings listed Example response { "data": [ { "id": "00000000-0000-0000-0000-000000000000", "finding_type": "pullrequest", "dashboard_url": "https://app.dryrun.security/risk-register/44444444-4444-4444-4444-444444444444", "severity": "high", "type": "Missing Authorization and IDOR in User Deletion", "description": "The DELETE /users/{id} endpoint is registered without authentication or authorization middleware...", "filename": "backend/main.go", "line_start": 516, "line_end": 553, "repository_name": "some-demo-repo-name", "state": "open", "triage": null, "created_at": "2026-03-03T00:00:00Z" } ] } Response Fields FieldTypeDescription idstringFinding ID, used with the triage endpoints finding_typestringSource of the finding: deepscan, pullrequest, sca, code_policy dashboard_urlstringLink to the finding in the DryRun Security dashboard severitystringFinding severity: critical, high, medium, low typestringFinding type or title labelstringClassifier label (e.g. auth_bypass, sqli, idor) descriptionstringFinding description filenamestringFile path where the finding was detected line_startintegerStarting line number line_endintegerEnding line number repository_namestringRepository name pr_numberintegerPull request number (for pullrequest findings only) pull_request_dashboard_urlstringLink to the pull request in the DryRun Security dashboard. Applies to pullrequest type findings only. created_atstring (ISO 8601)When the finding was detected statestringDerived finding state: open (from latest scan, not triaged), dismissed (triaged), resolved (not in latest scan) triageobjectTriage details if triaged, otherwise null. Includes category (false_positive, wont_fix, accepted_risk, in_progress) and category_name. Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/all_findings?days=30" Finding Triage POST /v1/accounts/{account_id}/findings/{finding_id}/triage Set a triage category for a finding. Set a triage category for a finding to track its resolution status. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID finding_idpathyesstringFinding ID Request Body { "triage_category": "false_positive" } Valid values for triage_category: false_positive, wont_fix, accepted_risk, in_progress. Responses 200 - triage category set Example (curl) curl -X POST \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"triage_category": "false_positive"}' \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/findings/{finding_id}/triage" GET /v1/accounts/{account_id}/findings/{finding_id}/triage Get the triage status for a finding. Retrieve the current triage status for a specific finding. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID finding_idpathyesstringFinding ID Responses 200 - triage status returned Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/findings/{finding_id}/triage" DELETE /v1/accounts/{account_id}/findings/{finding_id}/triage Remove the triage category from a finding. Remove the triage category from a finding, resetting its triage status. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID finding_idpathyesstringFinding ID Responses 200 - triage category removed Example (curl) curl -X DELETE \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/findings/{finding_id}/triage" Deepscans GET /v1/accounts/{account_id}/deepscans List all deepscans for an account. Retrieve all deepscans associated with the specified account. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID Responses 200 - deepscans listed Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/deepscans" GET /v1/accounts/{account_id}/repositories/{repository_id}/deepscans List deepscans for a repository. Retrieve all deepscans for a specific repository. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID repository_idpathyesstringRepository ID Responses 200 - deepscans listed Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/repositories/{repository_id}/deepscans" POST /v1/accounts/{account_id}/repositories/{repository_id}/deepscans Trigger a new DeepScan for a repository. Trigger a DeepScan Trigger a new DeepScan for a repository. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID repository_idpathyesstringRepository ID Responses 202 - DeepScan queued Example (curl) curl -X POST \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/repositories/{repository_id}/deepscans" GET /v1/accounts/{account_id}/repositories/{repository_id}/deepscans/{deepscan_id}/results List findings for a specific deepscan. Retrieve all findings from a specific deepscan run. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID repository_idpathyesstringRepository ID deepscan_idpathyesstringDeepScan ID Responses 200 - deepscan results listed Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/repositories/{repository_id}/deepscans/{deepscan_id}/results" GET /v1/accounts/{account_id}/repositories/{repository_id}/deepscans/{deepscan_id}/sca_results List SCA findings for a specific DeepScan run. List SCA findings for a specific DeepScan run. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID repository_idpathyesstringRepository ID deepscan_idpathyesstringDeepScan ID severityquerynostringFilter by severity (comma-separated). Valid values: critical, high, medium, low Response Fields id, dashboard_url, title, description, severity, package_name, package_version, package_ecosystem, cve_id, cvss_score, fixed_version, remediation, locations, references, created_at Responses 200 - SCA results listed Example (curl) curl \ -H "Authorization: Bearer <your-api-key>" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/repositories/{repository_id}/deepscans/{deepscan_id}/sca_results" SBOM GET /v1/accounts/{account_id}/repositories/{repository_id}/deepscans/{deepscan_id}/sbom Get the CycloneDX SBOM for a specific DeepScan run. Get SBOM for a specific DeepScan. Retrieve SBOM metadata and a time-limited download URL for the CycloneDX SBOM generated during a specific DeepScan run. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID repository_idpathyesstringRepository ID deepscan_idpathyesstringDeepScan ID Responses 200 - SBOM metadata and download URL returned 404 - DeepScan not found Response fields FieldTypeDescription deepscan_idstring (uuid)ID of the DeepScan that produced this SBOM repository_idstring (uuid)Repository ID branchstringBranch scanned (nullable) commit_shastringCommit SHA at time of scan (nullable) formatstringSBOM format, e.g. cyclonedx component_countintegerTotal number of components in the SBOM generated_atstring (date-time)When the SBOM was generated (nullable) vulnerability_summaryobjectCounts of vulnerable components by severity: critical, high, medium, low, total download_urlstring (uri)Time-limited URL to download the SBOM file download_url_expires_atstring (date-time)Expiry time for the download URL Example response { "data": { "deepscan_id": "11111111-1111-1111-1111-111111111111", "repository_id": "22222222-2222-2222-2222-222222222222", "branch": "main", "commit_sha": "abc123def456", "format": "cyclonedx", "component_count": 142, "generated_at": "2026-06-01T00:00:00Z", "vulnerability_summary": { "critical": 1, "high": 3, "medium": 7, "low": 4, "total": 15 }, "download_url": "https://...", "download_url_expires_at": "2026-06-01T01:00:00Z" } } Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/repositories/{repository_id}/deepscans/{deepscan_id}/sbom" GET /v1/accounts/{account_id}/repositories/{repository_id}/deepscans/sbom Get the latest SBOM for a repository. Retrieve SBOM metadata and a time-limited download URL for the most recent CycloneDX SBOM generated for a repository, without requiring a specific DeepScan ID. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID repository_idpathyesstringRepository ID Responses 200 - SBOM metadata and download URL returned Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/repositories/{repository_id}/deepscans/sbom" Configurations GET /v1/accounts/{account_id}/configurations List configurations for an account. Retrieve all configurations associated with the specified account. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID Responses 200 - configurations listed Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/configurations" POST /v1/accounts/{account_id}/configurations Create a new configuration. Create a new configuration for the specified account. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID Request Body { "configuration": { "name": "string", "configuration": { "comment": "disabled", "show_scan_confirmation": false, "risk_threshold": 0, "analyzers": {}, "code_policies": [ { "id": null, "enabled": null, "silent": null, "blocking": null } ], "notifications": { "enabled": false, "deduplicate": false, "integrationNames": [null] } } }, "repositories": [ "00000000-0000-0000-0000-000000000000" ] } Responses 201 - configuration created Example (curl) curl -X POST \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"configuration": {"name": "My Config", "configuration": {"comment": "disabled", "risk_threshold": 0, "analyzers": {}}}, "repositories": []}' \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/configurations" POST /v1/accounts/{account_id}/configurations/assign_repositories Assign a configuration to multiple repositories. Assign a configuration to one or more repositories by ID, name, or pattern. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID Request Body { "configuration_id": "00000000-0000-0000-0000-000000000000", "repository_ids": [ "00000000-0000-0000-0000-000000000000" ], "repository_names": [ "string" ], "repository_pattern": "string" } Responses 200 - repositories assigned Example (curl) curl -X POST \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"configuration_id": "CONFIG_ID", "repository_ids": ["REPO_ID"]}' \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/configurations/assign_repositories" POST /v1/accounts/{account_id}/configurations/bulk_update Bulk update multiple configurations. Apply the same updates to multiple configurations at once. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID Request Body { "configuration_ids": [ "00000000-0000-0000-0000-000000000000" ], "updates": { "comment": "disabled", "show_scan_confirmation": false, "risk_threshold": 0, "analyzers": {}, "code_policies": [ { "id": "00000000-0000-0000-0000-000000000000", "enabled": false, "silent": false, "blocking": false } ], "notifications": { "enabled": false, "deduplicate": false, "integrationNames": ["string"] } } } Responses 200 - configurations updated Example (curl) curl -X POST \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"configuration_ids": ["CONFIG_ID_1", "CONFIG_ID_2"], "updates": {"risk_threshold": 5}}' \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/configurations/bulk_update" GET /v1/accounts/{account_id}/configurations/{id} Get a single configuration. Retrieve details for a specific configuration. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID idpathyesstringConfiguration ID Responses 200 - configuration found Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/configurations/{id}" PUT /v1/accounts/{account_id}/configurations/{id} Update a configuration. Update an existing configuration. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID idpathyesstringConfiguration ID Request Body { "configuration": { "name": "string", "configuration": { "comment": "disabled", "show_scan_confirmation": false, "risk_threshold": 0, "analyzers": {}, "code_policies": [ { "id": null, "enabled": null, "silent": null, "blocking": null } ], "notifications": { "enabled": false, "deduplicate": false, "integrationNames": [null] } } } } Responses 200 - configuration updated Example (curl) curl -X PUT \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"configuration": {"name": "Updated Config", "configuration": {"risk_threshold": 5}}}' \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/configurations/{id}" PATCH /v1/accounts/{account_id}/configurations/{id} Partially update a configuration. Apply a partial update to an existing configuration. Only the fields provided in the request body are updated. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID idpathyesstringConfiguration ID Request Body { "configuration": { "name": "string", "configuration": { "comment": "disabled", "show_scan_confirmation": false, "risk_threshold": 0, "analyzers": {}, "code_policies": [ { "id": null, "enabled": null, "silent": null, "blocking": null } ], "notifications": { "enabled": false, "deduplicate": false, "integrationNames": [null] } } } } Responses 200 - configuration updated Example (curl) curl -X PATCH \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"configuration": {"configuration": {"risk_threshold": 5}}}' \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/configurations/{id}" DELETE /v1/accounts/{account_id}/configurations/{id} Delete a configuration. Permanently delete a configuration. This action cannot be undone. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID idpathyesstringConfiguration ID Responses 200 - configuration deleted Example (curl) curl -X DELETE \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/configurations/{id}" Analyzers GET /v1/accounts/{account_id}/analyzers List available analyzers. Retrieve all enabled and visible analyzers. Use the slug field as the key in configuration analyzer settings. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID Responses 200 - analyzers listed Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/analyzers" Custom Policies GET /v1/accounts/{account_id}/custom_policies List all Custom Code Policies for an account. Retrieve all Custom Code Policies associated with the specified account. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID Responses 200 - custom policies listed Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/custom_policies" Insights GET /v1/accounts/{account_id}/insights Retrieve the daily insights digest. Retrieve the daily insights digest for an account. Supports an optional date query parameter in YYYY-MM-DD format. Parameters NameInRequiredTypeDescription account_idpathyesstringAccount ID datequerynostringDate in YYYY-MM-DD format Responses 200 - insights returned Example (curl) curl \ -H "Authorization: Bearer $DRYRUN_API_KEY" \ "https://simple-api.dryrun.security/v1/accounts/{account_id}/insights?date=2026-01-15" Conventions IDs and scoping: account_id is required for most endpoints. repository_id is required for repository-scoped endpoints. Response shape: Most list endpoints return a top-level data array. Errors: If an item is not found, endpoints return 404 with {"error": "not found"}. Support If you have questions about authentication, account access, or expected responses, contact DryRun Security support and include the endpoint URL you called, the HTTP status code, and the request_id header (if present). --- # Compliance & GRC URL: https://docs.dryrun.security/compliance-grc Compliance reporting, audit readiness, and SBOM generation. Compliance and Audit Readiness Overview DryRun Security provides the evidence trail that compliance and audit workflows require. Every PR review, finding, remediation, and policy enforcement action is tracked and accessible through the platform's reporting capabilities. SOC2 Type II Certification DryRun Security is SOC2 Type II certified. This means the platform itself has been independently audited for security, availability, and confidentiality controls. Your data is handled according to the same standards your organization is working to meet. Audit Evidence Generation The platform automatically generates evidence that auditors and regulators commonly request: Findings history - complete record of every vulnerability found, when it was found, and when it was resolved Remediation timelines - time-to-fix metrics for each finding, broken down by severity and category Policy enforcement records - which Custom Code Policies were evaluated, what they found, and how findings were resolved Scan coverage - which repositories were scanned, how frequently, and what percentage of PRs received security review DeepScan reports - point-in-time full-repository security assessments for baseline evidence Dashboard and Reporting The Security Dashboard provides real-time metrics that map to common compliance requirements: Vulnerability trends over time (are things getting better or worse?) Open findings by severity and category Mean time to remediation Policy compliance rates across repositories Coverage gaps (repositories not yet connected) Use the intelligence index to generate custom audit-ready reports by asking natural language questions like "show me a chart of risky alerts by repo for last quarter." Risk Register as Audit Trail The Risk Register serves as the central audit trail for all findings. Every finding includes: The specific code change that introduced the vulnerability Which analyzer detected it and why The remediation status and any associated PR that fixed it Triage records with notes explaining why a finding was marked as acceptable risk This level of traceability satisfies auditors who need to understand not just what vulnerabilities exist, but how the organization identified and responded to them. SBOM and AI-BOM DryRun Security generates Software Bills of Materials (SBOM) that document the third-party components in your codebase. SBOMs are increasingly required by regulation (Executive Order 14028, EU Cyber Resilience Act) and by enterprise customers who need supply chain transparency. DeepScan for Compliance Assessments Run a DeepScan to generate a point-in-time security assessment of an entire repository. This is useful for: Initial onboarding - establishing a security baseline when connecting a repository Pre-audit preparation - generating comprehensive findings reports ahead of an audit Regulatory submissions - providing evidence of security review for compliance certifications Periodic assessments - quarterly or annual full-repository reviews beyond continuous PR scanning SBOM Generation What Is an SBOM? A Software Bill of Materials (SBOM) is a formal inventory of all the components in a software product - every library, package, framework, and dependency, along with version information and provenance data. SBOMs have become an important tool for supply chain security, enabling organizations to quickly determine whether they're affected when a new vulnerability is disclosed in a widely-used library. Regulatory frameworks and government procurement requirements increasingly mandate SBOM production. Executive Order 14028 in the United States requires SBOM from software vendors selling to the federal government. Similar requirements are emerging in the EU and other jurisdictions. Even organizations not subject to regulatory mandates benefit from the visibility SBOMs provide into their software supply chain. SBOM with DryRun Security DryRun Security generates SBOMs as a natural output of its dependency scanning capability. Because DryRun Security already analyzes your dependency manifests and lock files on every scan, the data needed for SBOM production is continuously maintained and up to date. SBOMs can be exported in industry-standard formats, enabling integration with vulnerability management platforms, procurement systems, and compliance tools that consume SBOM data. AI-BOM: Bill of Materials for AI Components As AI-generated code and AI-powered libraries become prevalent in modern software, a new challenge emerges: understanding what AI components are present in your software and what their provenance is. DryRun Security generates AI-BOMs - bills of materials specifically tracking AI-originated components and AI library dependencies. An AI-BOM captures: AI and ML libraries present in the codebase and their versions Model dependencies and third-party AI service integrations Sections of code identified as AI-generated (via DryRun's AI coding visibility capability) Compliance and Audit Readiness SBOM and AI-BOM data produced by DryRun Security can be provided directly to auditors, customers, or regulators as evidence of supply chain visibility and control. Combined with DryRun Security's continuous vulnerability scanning and risk trending, this provides the documented, traceable security program that compliance frameworks require. --- # Dashboard URL: https://docs.dryrun.security/dashboard The Security Dashboard provides a real-time view of your organization's security posture across every repository and pull request DryRun Security monitors, with overview metrics and trend charts scoped to a configurable time window. Overview The Security Dashboard provides a real-time view of your organization's security posture across every repository and pull request DryRun Security monitors. All metrics are scoped to a configurable time window - 24 hours, 7 days, 30 days, or 90 days - so security and engineering teams can evaluate both current state and longer-term trends. Overview Metrics Six summary tiles appear across the top of the dashboard, giving an at-a-glance picture of activity and risk across the selected period. PRs Scanned The total number of pull requests DryRun Security analyzed in the selected window. This is your coverage signal - every PR that entered review was evaluated for security issues across the repositories connected to your account. Total Findings The cumulative number of security findings identified across all scanned PRs during the period. This represents the full volume of security signals your team is working through, spanning all severity levels and vulnerability classes. Merged PRs The total number of PRs merged during the period. Read alongside PRs Scanned and Merged PRs w/ Risk, this provides a clear picture of code velocity relative to security outcomes. Merged PRs w/ Risk PRs authored by a developer and merged while carrying at least one unresolved finding. This is a direct measure of residual risk entering your codebase. A low count relative to total merged PRs indicates your team is consistently resolving findings before code ships. Improvement Rate The percentage of scanned PRs flagged as improved during the selected period. A PR is considered improved when a finding identified in one scan is no longer present in the next scan of that same PR - meaning the developer addressed it within the review cycle, before merge. A high improvement rate indicates findings are being caught and fixed at the point of introduction rather than carried forward. Hardcoded Credentials A dedicated count of credential-related findings - API keys, tokens, secrets, and similar sensitive values - across all scanned PRs. Hardcoded credentials represent one of the highest-impact risks in any codebase and are surfaced separately so they remain visible regardless of overall finding volume. Charts Findings Over Time A stacked line chart tracking findings at each severity level - Critical, High, Medium, and Low - across the selected time window. Each line moves independently, so you can see whether risk is shifting between severity tiers over time, not just whether the total is going up or down. Findings by Repository A ranked view of which repositories are generating the most findings. This helps security and platform teams understand where risk is concentrated and prioritize remediation effort across the portfolio. Severity Distribution A breakdown of active findings by severity - Critical, High, Medium, and Low - with a count and percentage for each tier. The center of the chart shows the total. Use this to assess whether your open risk is weighted toward high-severity issues that need immediate attention or spread across lower-severity findings. Findings by Class A ranked breakdown by vulnerability type - such as Hardcoded Credentials, Cross-Site Scripting, SQL Injection, and others. Recurring patterns within a class often point to a shared dependency, an architectural pattern, or a training gap, making this view useful for identifying systemic issues beyond individual findings. Developer Activity A per-developer breakdown showing PRs opened and the subset of those PRs merged with at least one unresolved finding. This view helps AppSec and engineering leads understand how security habits are distributed across the team and where additional guidance may be needed. --- # Webhooks URL: https://docs.dryrun.security/webhooks Manage webhook destinations for DryRun Security finding notifications. Supports Slack and generic HTTP endpoints. The Webhooks page manages the endpoints DryRun Security sends finding notifications to. Each webhook has a unique slug used to reference it in PR Scanning Configurations. DryRun Security supports two types: Slack webhooks, which deliver findings as formatted channel messages, and generic webhooks, which send a JSON payload to any HTTP endpoint. When Webhooks Fire DryRun Security triggers a webhook in two scenarios: PR findings - When a PR scan detects findings that meet or exceed the minimum severity threshold defined in the PR Scanning Configuration, the webhook fires for every repository covered by that configuration. Webhooks are PR-specific: DeepScan and SCA findings do not trigger webhook notifications. Daily digest - A webhook endpoint can also serve as the delivery target for the daily digest. See Daily Digest in PR Scanning Configuration for details. Both triggers are configured in the Notifications tab of a PR Scanning Configuration. Adding a Webhook Click Add Webhook, give the webhook a name, and paste in the endpoint URL. The name becomes the webhook's slug and is how you reference it in configurations. DryRun Security detects the type automatically based on the URL: Slack - If the URL is a Slack incoming webhook URL, the type is set to Slack. DryRun Security formats the payload as a Slack Block Kit message so it renders correctly in your channel, including the repository name, PR title, severity level, and a direct link to the pull request. Generic - For any other URL, the type is set to Generic and DryRun Security sends the standard JSON payload described in the Payload Format section below. Click Save. The webhook appears in the Destinations list and is ready to assign to configurations. Managing Webhooks Each row in the Destinations list has three actions: Test - Sends a sample payload to the endpoint to confirm the connection is working Edit - Update the webhook name or URL Delete - Remove the webhook permanently Adding to a Configuration A webhook only fires for repositories it has been assigned to in a configuration. To activate a webhook, open PR Scanning Configuration, go to the Notifications tab for the relevant configuration, and select the webhook by slug as the notification endpoint. The Notifications tab is also where you configure a daily digest. See PR Scanning Configuration for full details. Payload Format Generic Payload DryRun Security sends an HTTP POST with a JSON body to your endpoint when a scan completes. The body includes PR context, scan metadata, and the full list of findings. { "dashboard_url": "https://app.dryrun.security/pull-requests/00000000-0000-0000-0000-000000000000", "github_url": "https://github.com/org/repo/pull/123", "risk_threshold": "high", "org": "your-org", "repo_name": "your-repo", "repo_full_name": "your-org/your-repo", "pr_number": 123, "pr_title": "Add payment endpoint", "pr_status": "open", "branch": "feature/payments", "commit_author": "developer", "issue_status": "open", "run_time": "2026-06-09T16:48:44.960558Z", "results": [ { "id": "00000000-0000-0000-0000-000000000001", "finding_type": "pullrequest", "type": "Missing Authorization on Payment Endpoint", "filename": "src/payments/handler.py", "line_start": 42, "line_end": 58, "description": "The POST /payments endpoint does not verify the caller's identity...", "risk": "high" } ] } Top-level fields FieldTypeDescription dashboard_urlstringLink to the PR in the DryRun Security dashboard github_urlstringLink to the pull request in your SCM risk_thresholdstringHighest risk level among all findings in this scan: critical, high, medium, or low. Returns passing when no findings meet the configured Risk Level threshold. orgstringOrganization name repo_namestringRepository name repo_full_namestringFull repository identifier in org/repo format pr_numberintegerPull request number pr_titlestringPull request title pr_statusstringPull request status: open or closed branchstringBranch the pull request was opened from commit_authorstringAuthor of the triggering commit issue_statusstringWhether any open findings remain: open or resolved run_timestring (date-time)Timestamp of when the scan completed resultsarrayList of findings from this scan. Empty when no findings are present. Result fields FieldTypeDescription idstring (uuid)Unique finding ID finding_typestringSource of the finding: pullrequest, code_policy, deepscan, or sca typestringFinding name filenamestringFile where the finding was detected line_startintegerStarting line of the affected code line_endintegerEnding line of the affected code descriptionstringFull finding description riskstringRisk level of this finding: critical, high, medium, or low Slack Payload When the type is Slack, DryRun Security sends a formatted Block Kit message rather than the generic JSON payload. Each Slack notification includes the repository name, pull request title, severity level, and a direct link to the pull request in the DryRun Security dashboard. --- # Jira Integration URL: https://docs.dryrun.security/jira-integration Connect DryRun Security to Jira using automation middleware for automated ticket creation and deduplication. Overview DryRun Security does not have a native Jira integration today, but admins can connect DryRun Security to Jira using an automation middleware tool, either Tines or Zapier. DryRun Security sends a webhook when a finding is detected on a PR scan. The middleware receives the webhook, unpacks the finding details, checks Jira for an existing ticket for that finding, and either creates a new ticket or updates the existing one. When a PR is scanned and a finding is returned, DryRun Security sends a POST request with a JSON payload containing the event type, timestamp, repository, pull request number, and a finding object with id, severity, category, title, file, line, and description. See the Webhooks page for the full payload structure and configuration details. Prerequisites DryRun Security webhook configured (see Webhooks) A Jira project with API access (Jira API token and project key) A Tines or Zapier account Jira Field Mapping Map DryRun Security finding fields to Jira ticket fields as follows: Jira FieldValue from DryRun Summary[DryRun] {finding.title} in {finding.file}:{finding.line} DescriptionFull finding description, repository, PR number, severity, file path, finding ID Labelsdryrun-security, {finding.severity}, {finding.category}, {finding.id} (used for deduplication) PriorityCritical → Highest, High → High, Medium → Medium, Low → Low Note: The finding.id label is used as the deduplication key to check whether a ticket already exists. Tines Workflow Tines is a security automation platform. Use it to receive DryRun Security webhooks and automate Jira ticket creation with deduplication logic. Create a Webhook action in Tines: Add a “Webhook” action as the trigger. Tines will generate a unique URL. Copy this URL and use it as the DryRun Security webhook destination in Settings > Integrations. Add a Filter action: Filter on event == "new_finding" to ensure the workflow only runs for new findings (not scan completions or resolved findings). Search Jira for an existing ticket: Add an HTTP Request action to call the Jira REST API: GET {JIRA_BASE_URL}/rest/api/3/search ?jql=project={PROJECT_KEY} AND labels="{finding.id}" AND statusCategory != Done Authorization: Basic {base64(email:api_token)} This checks whether a ticket already exists for this specific finding by searching for its unique ID in labels. Add a Branch (condition) action: Check the issues array in the Jira search response: If issues.length > 0 → ticket exists → go to Step 5 If issues.length == 0 → no ticket → go to Step 6 Add a comment to the existing Jira ticket. HTTP Request action: POST {JIRA_BASE_URL}/rest/api/3/issue/{issues[0].id}/comment Body: { "body": "DryRun Security flagged this finding again on PR #{pull_request} in {repository} at {timestamp}." } Create a new Jira ticket. HTTP Request action: POST {JIRA_BASE_URL}/rest/api/3/issue Body: { "fields": { "project": { "key": "{PROJECT_KEY}" }, "summary": "[DryRun] {finding.title} in {finding.file}:{finding.line}", "description": { "type": "doc", "version": 1, "content": [ { "type": "paragraph", "content": [{ "type": "text", "text": "PR: #{pull_request} | Repository: {repository}" }] }, { "type": "paragraph", "content": [{ "type": "text", "text": "Severity: {finding.severity} | Category: {finding.category}" }] }, { "type": "paragraph", "content": [{ "type": "text", "text": "File: {finding.file}:{finding.line}" }] }, { "type": "paragraph", "content": [{ "type": "text", "text": "Finding ID: {finding.id}" }] }, { "type": "paragraph", "content": [{ "type": "text", "text": "{finding.description}" }] } ] }, "issuetype": { "name": "Bug" }, "labels": ["dryrun-security", "{finding.severity}", "{finding.id}"], "priority": { "name": "{mapped priority}" } } } Workflow diagram: Webhook → Filter (new_finding) → Search Jira → Branch → [Comment on existing ticket | Create new ticket] Zapier Workflow Zapier is a no-code automation platform. Use it to build the same DryRun Security → Jira workflow without writing code. Create a new Zap and choose “Webhooks by Zapier” as the trigger: Select “Catch Hook” as the trigger event. Zapier generates a webhook URL. Copy it and configure it as the DryRun Security webhook destination in Settings > Integrations. Test the trigger: Use DryRun Security’s Test button in the webhook configuration to send a sample payload. This lets Zapier detect the field structure from the finding payload. Add a Filter step: Insert a “Filter” action and set the condition: event (exactly) new_finding. This ensures the Zap only continues for new findings. Add a “Find Issue” Jira action: Choose the Jira Cloud app and select “Find Issue.” Configure the search using JQL: project = {PROJECT_KEY} AND labels = "{finding.id}" AND statusCategory != Done Map finding.id from the DryRun Security payload as the label value. Add a “Paths” step (two branches): Path A: Ticket exists (Find Issue returned a result): Add a Jira “Add Comment to Issue” action. Set the Issue ID from the Find Issue result. Comment body: DryRun Security flagged this finding again on PR #{pull_request} in {repository}. Path B: No ticket (Find Issue returned no result): Add a Jira “Create Issue” action. Map fields from the DryRun Security payload: Summary: [DryRun] {finding.title} in {finding.file}:{finding.line} Description: PR: #{pull_request} | Repository: {repository} | Severity: {finding.severity} | File: {finding.file}:{finding.line} | Finding ID: {finding.id} | {finding.description} Labels: dryrun-security, severity value, finding ID Priority: map from severity Issue Type: Bug Turn on the Zap: Once all steps are configured and tested, enable the Zap. --- # API Access Keys URL: https://docs.dryrun.security/api-access-keys Create and manage API access keys for programmatic access to DryRun Security. Overview API access keys allow you to authenticate with the DryRun API for programmatic access to DryRun Security. Use API keys to integrate DryRun Security into your CI/CD pipelines, custom tooling, or automation workflows. Creating an API Key Navigate to Settings > Access Keys in the sidebar at app.dryrun.security. The Access Keys page provides two sections: API Keys - Create and manage API keys for your applications. Click + Generate New API Key to create a new key. Your API Keys - View and manage your existing API keys. You can revoke any key at any time. Keep your API keys secure. Treat API keys like passwords. Never share them in public repositories, client-side code, or unsecured locations. If a key is compromised, revoke it immediately from the Access Keys page. The API key must be scoped to at least one account. One API key can be used to access more than one account. After creating the key, copy it to a safe place - it will not be shown again. Using API Keys Send your API key in the Authorization header using the Bearer scheme: Authorization: Bearer dryrunsec_********************** Key Management Rotate keys regularly - Generate a new key and revoke the old one periodically. Use descriptive names - Name keys after their use case for easy identification. Revoke unused keys - Delete keys that are no longer in use from the API Keys settings page. Never commit keys to source control - Use environment variables or secret management tools. Rate Limits API keys are subject to rate limits to ensure platform stability. Current limits are displayed in the API Keys settings page. If you need higher limits, contact DryRun Security support. --- # Remediation URL: https://docs.dryrun.security/remediation Automated remediation guidance and fix verification for security findings. DryRun Security integrates with AI coding tools to turn security findings into automated fixes. When a vulnerability is detected, an AI coding tool connected to DryRun Security can read the finding in context, understand the affected code, and generate a targeted fix - without requiring the developer to manually triage or research the issue. Why Remediation Matters Connecting remediation directly to the detection workflow delivers measurable value across your development organization: Speed of deployment - Fixing vulnerabilities faster means shipping faster Reduced time-to-remediation - Vulnerabilities are resolved quickly rather than sitting in backlogs Developer productivity - Developers spend less time on manual security fixes and more time building features Consistent remediation - AI-powered fixes follow security best practices every time Shift-left at scale - Security fixes happen as part of the development workflow, not as a separate process How Remediation Works with AI Coding DryRun Security enables remediation by integrating with AI coding tools. Supported tools include: Claude Code Codex Cursor GitHub Copilot Windsurf VS Code Remediation is enabled by: Creating an API key from the DryRun Security dashboard (see API Access Keys) Connecting your AI coding tool to the DryRun Security MCP (Model Context Protocol) server Installing the DryRun Security remediation skill: see the DryRun Skill page for instructions Once connected, the AI coding tool can read DryRun Security findings and automatically generate fixes in the context of your codebase. --- # DryRun Skill URL: https://docs.dryrun.security/dryrun-skill The DryRun Security skill gives your AI coding tool the context it needs to author, review, and remediate code securely. AI coding tools are fast, but they operate in a silo. Left to their defaults, they may skip pull requests, ignore organizational best practices, and even when a PR is opened, they will not check for security findings unless explicitly told to. The DryRun Security skill closes that gap, giving the AI the context it needs to follow proper PR workflow and treat security findings as a required step in the process. For findings from DeepScan and SCA scans, the DryRun Finding Remediation skill provides an additional workflow for actioning vulnerabilities outside of an open pull request. Works with Claude Code, Codex, Cursor, Windsurf, and VS Code. The PR Workflow The DryRun Security skill equips your AI coding tool with the context it needs to author, review, and remediate code securely across the lifecycle of a pull request. Note: For most AI coding tools this workflow is packaged as a single skill. For Claude Code, it is split across two skills: dryrun-pr-review covering Author and Review, and dryrun-remediation covering Remediate. The workflow and experience are the same either way. Author The skill instructs the AI coding tool to open a pull request rather than push changes directly to the main branch. This is what makes DryRun Security scanning possible. DryRun Security analyzes pull requests in real time. If code is pushed directly to main, there is no pull request to scan and no opportunity to catch vulnerabilities before they land. Review The skill gives the AI coding tool awareness that DryRun Security will scan the open pull request and post findings as a comment in GitHub or GitLab. After the PR is opened, the AI polls for that comment, waits for findings to be posted, and presents each one to the developer. After every commit to the branch, the AI re-polls for new findings and presents them, keeping the developer informed throughout the lifecycle of the PR. Remediate When the developer wants to fix a finding, the skill gives the AI coding tool additional context to work from: how DryRun Security identified the vulnerability, background on the vulnerability class, OWASP guidance, and relevant framework documentation. This context helps the AI produce a fix that is accurate, minimal, and appropriate for the codebase. To start the Author and Review workflow, describe your change and include a prompt to open a pull request: [Describe the change you want]. When ready, open a pull request. To invoke Remediate, paste the DryRun Security finding directly: Fix this DryRun Security finding: [paste the finding comment] DeepScan and SCA Workflow DryRun Security also offers a skill (dryrun-finding-remediation) that extends remediation beyond open pull requests. Where the PR workflow surfaces findings on an active PR, Finding Remediation queries DryRun Security directly for vulnerabilities from DeepScan and SCA scans, including findings already merged into the main branch. The AI then opens a new pull request with the fix applied against the current state of the codebase. Requires an API access token set as an environment variable named DRYRUN_API_KEY. See the API Access Keys page for setup instructions. To invoke DryRun Finding Remediation: Help me review the findings for this repo's DeepScan Installation Install instructions for each tool are available in the DryRun Security dashboard under Settings > Integrations. For DryRun Finding Remediation, set your API access token in your environment before installing the skill: DRYRUN_API_KEY=your_token_here See the API Access Keys page for instructions on generating a token.