DOCSEARCHbyAlgolia
Submit Docs

Probely Developer Documentation

website·Indexed 35 days ago

https://developers.probely.com

Documentation for the Probely API and CLI, featuring guides and references for managing targets, running vulnerability scans, handling findings, and configuring webhooks. Includes tutorials on target authentication, 2FA login sequences, and OpenAPI API scanning.

Tokens
243.3K
Snippets
748
Records
1.8K
Agent score
50%

What's inside Probely

  1. Overview of Snyk API & Web MCP Server

    The Snyk API & Web MCP Server acts as a bridge between Snyk's security automation and AI-native development tools using the Model Context Protocol (MCP). It enables AI agents to perform high-level security management tasks including:

    • Target Onboarding: Adding new web application and API scan targets to a Snyk account.
    • Automated Auth Configuration: Configuring authentication parameters for dynamic testing scans.
    • DAST Scan Execution: Triggering Dynamic Application Security Testing (DAST) scans on-demand.
    • Intelligent Triage: Summarizing findings, prioritizing vulnerabilities by severity or reachability, and suggesting fixes.

  2. Overview of Snyk API & Web (DAST) capabilities

    Snyk API & Web is a Dynamic Application Security Testing (DAST) suite designed for Agile teams to continuously scan web applications and APIs for security vulnerabilities. It allows developers to integrate security scanning into their workflows and manage the lifecycle of discovered vulnerabilities.

  3. Overview of Snyk API & Web Event Notifications

    Snyk API & Web provides a webhook system to notify users of important account and target events in real-time, eliminating the need for repeated polling.

    Supported Event Types:

    • Account Events: User creation/deletion, target creation/deletion, and target verification success/failure.
    • Target Events: Scan start/completion/cancellation/failure, and vulnerability finding detection/fixes.

    Webhook Registration Scopes:

    • Account Events Registration: The webhook receives notifications for all account events and all target events for every target associated with the account.
    • Target Events Registration: The webhook receives notifications only for target events related to a specific target.

  4. Partial Update Discovered Asset Response Schema

    The response for a partial update to a discovered asset (PATCH /discovery/assets/:id/) provides detailed status and metadata about the asset's discovery and scanning process. Key data includes:

    • Fingerprinter Status: Tracks the state (e.g., "started", "ended"), the number of detected technologies, and any warnings or errors.
    • Scanner Status: Provides the execution state, a progress list [scanned_urls, total_urls], and detailed warnings/errors.
    • Full Status: A detailed object containing timestamps (ts), internal IDs (iid, aid), and the specific module/stage of the scan.
    • Scanner State: Real-time metrics including average response time (averageRtt), counts of HTTP status codes (3xx, 4xx, 5xx), connection errors, timeouts, and total requests executed.
    • Stack: A list of detected technologies (e.g., "PHP", "Apache") used to fine-tune vulnerability tests.
    • Blackout Period: Configuration for temporary scan interruptions, including start/cease times (ISO 8601), enabled status, and active weekdays.
    • Asset Metadata: Includes owner labels, target labels, redirection info (redirect_from, redirect_to), and the user who last modified the asset (changed_by).

  5. Retrieve a specific API user by ID

    Retrieve detailed information about a specific API user by sending a GET request to /api-users/:id/. The id path parameter is required and must be a Base58 string identifying the user object.

    Response Schema (200 OK):

    • id (string): Unique Base58 identifier for the user.
    • name (string): Name of the user (max 60 characters).
    • active (boolean): Whether the user can authenticate to the API and Web interface. Defaults to true.
    • is_apiuser (boolean): Indicates if the user is an application (true) or a human (false).
    • changed_by (object): Details of the user who last modified this record, including their id, email, name, and the changed timestamp (ISO 8601 UTC).
    • labels (array): A list of labels associated with the user, each containing an id, name (max 255 chars), and color (RGB hex format, e.g., #00FF00).
    • user_roles (array): Roles assigned to the user, including role id, name, scope, and target details.
    • key (string): The API key associated with the user.
    • expiration_date (date-time): The expiration date of the API key.
    curl -X GET "https://{api-domain}/api-users/{id}/"

  6. Use Navigation and Login Sequences to crawl complex web areas

    Snyk API & Web allows you to record sequences of actions (such as multi-step forms) that the crawler can replay during target scans. This ensures the crawler can reach URLs in complex areas that would otherwise be inaccessible. Sequences are recorded in JSON format and can be managed as either Login Sequences (for authentication) or Navigation Sequences (for reaching specific app areas).

  7. Retrieve a specific finding for a target

    Use the GET /targets/:target_id/findings/:id/ endpoint to retrieve detailed information about a specific finding associated with a target. The response includes the global finding ID (formatted as <TARGET_ID>-<FINDING_ID>) and comprehensive target configuration details, including site settings, authentication methods (form, sequence, or basic auth), and OTP configurations.
    # Example request to retrieve finding 123 for target 'target_abc'
curl -X GET "https://api.probely.com/targets/target_abc/findings/123/"

  8. Understand the Finding object schema for Target Findings

    When retrieving findings for a target via the /targets/:target_id/findings/ endpoint, the response includes detailed information about each vulnerability finding. Key fields include:

    • id: A unique Base58 identifier for the finding.
    • new: Boolean indicating if the vulnerability was newly discovered in the current scan or found in previous scans.
    • review_status: The validation state of the finding. Possible values are notrequired, pending, rejected, and accepted.
    • review_reason: The user-provided justification for the review status.
    • created_at: Timestamp of when the finding was first created.
    • changed: ISO 8601 UTC timestamp of the last modification (e.g., "2023-08-09T13:27:43.8208302").
    • changed_by: An object containing the name and email of the user who last modified the finding.
    • comment: An optional comment associated with the object.
    • expiration_date, approver_name, and approval_date: Fields used for acceptance tracking. These may be required depending on account-level settings (e.g., 'Require expiration date on acceptance').

  9. List user roles via the Probely API

    Retrieve a paginated list of user roles using a GET request to /user-roles/. The response includes detailed information about the user, their assigned role, associated permissions, and the target or team scope.
    curl -X GET "https://api.probely.com/user-roles/"

  10. Retrieve account credit usage data

    Use the GET /account/credits/usage/ endpoint to retrieve a history of credit usage for the account. The response provides a paginated list of credit transactions, including the amount used, the resulting balance, and details about the scan and target that triggered the credit consumption.
    curl -X GET "https://api.probely.com/account/credits/usage/"

  11. Retrieve details for a specific scan

    Use the GET /targets/:target_id/scans/:id/ endpoint to retrieve detailed information about a specific scan associated with a target. The response includes the scan's unique identifier and comprehensive details about the target's configuration, including its site settings, authentication methods (form-based, sequence-based, or basic auth), and security configurations like mTLS or Message Level Encryption (MLE).
    curl -X GET "https://api.probely.com/targets/{target_id}/scans/{id}/" \
     -H "Authorization: Bearer <YOUR_TOKEN>"

  12. Manage users with User Labels

    User Labels provide a mechanism to attach short, descriptive pieces of information to users. This is primarily used to categorize users (e.g., marking a user as 'Outsource') to simplify filtering and general user management. Before creating custom labels, it is recommended to verify if the required information is already provided by the Snyk API & Web (such as teams, roles, or user targets).