Alerting integrations support notifications as part of scanning and asset discovery, and include Slack, Microsoft Teams, Email, and custom Webhooks. Navigate to Scans → Configurations → Alerting to configure your alerts.
ProjectDiscovery supports scan notifications through Slack. To enable Slack notifications provide a name for your Configuration, a webhook, and an optional username.
Choose from the list of Events (Scan Started, Scan Finished, Scan Failed) to specify what notifications are generated. All Events are selected by default
ProjectDiscovery supports notifications through Microsoft Teams. To enable notifications, provide a name for your Configuration and a corresponding webhook.
Choose from the list of Events (Scan Started, Scan Finished, Scan Failed) to specify what notifications are generated.
ProjectDiscovery supports custom webhook notifications, allowing you to post events to any HTTP endpoint that matches your infrastructure requirements.
The integrations under Ticketing support ticketing functionality as part of scanning and include support for Jira, GitHub, GitLab, and Linear. Navigate to Scans → Configurations → Ticketing to configure your ticketing tools.
ProjectDiscovery provides integration support for GitHub to create new tickets when vulnerabilities are found.
Provide a name for the configuration, the Organization or username, Project name, Issue Assignee, Token, and Issue Label. The Issue Label determines when a ticket is created. (For example, if critical severity is selected, any issues with a critical severity will create a ticket.)
The severity as label option adds a template result severity to any GitHub issues created.
Deduplicate posts any new results as comments on existing issues instead of creating new issues for the same result.
ProjectDiscovery provides integration support for GitLab to create new tickets when vulnerabilities are found.
Provide your GitLab username, Project name, Project Access Token and a GitLab Issue label. The Issue Label determines when a ticket is created.
(For example, if critical severity is selected, any issues with a critical severity will create a ticket.)
The severity as label option adds a template result severity to any GitLab issues created.
Deduplicate posts any new results as comments on existing issues instead of creating new issues for the same result.
ProjectDiscovery supports integrations with all popular cloud providers to automatically sync externally facing hosts for vulnerability scanning. This comprehensive approach ensures all your cloud resources with external exposure are continuously monitored, complementing our external discovery capabilities. The result is complete visibility of your attack surface across cloud environments through a simple web interface.
ProjectDiscovery’s AWS integration allows the platform to automatically discover and monitor cloud assets across your AWS accounts. By connecting AWS to ProjectDiscovery, security teams and DevOps engineers gain continuous visibility into EC2 instances, S3 buckets, DNS records, and other resources without manual inventory. This integration leverages ProjectDiscovery’s open-source Cloudlist engine to enumerate assets via AWS APIs. In short, it helps ensure no cloud asset goes unnoticed, enabling proactive security monitoring and easier management of your attack surface.
By covering these services, ProjectDiscovery can map out a broad range of AWS assets in your account. (Support for additional services may be added over time.)
AWS Integration Methods
ProjectDiscovery supports three methods to connect to AWS, each suited for different use cases and security preferences:
Single AWS Account (Access Key & Secret) – Direct credential-based authentication using an IAM User’s Access Key ID and Secret Access Key to connect one AWS account. Choose this for quick setups or single-account monitoring.
Multiple AWS Accounts (Assume Role) – Use one set of credentials to assume roles in multiple accounts. This method is ideal for organizations with multiple AWS accounts (e.g. dev, prod, etc.). You provide one account’s credentials and the common role name that exists in all target accounts.
Cross-Account Role (Role ARN) – Use a dedicated IAM role with an External ID for third-party access. This option lets you create a cross-account IAM role in your AWS account and grant ProjectDiscovery access via that role’s Amazon Resource Name (ARN). This is the most secure integration method, as it follows AWS best practices for third-party account access.
Prerequisites
Before configuring the integration, make sure you have:
AWS Account – Access to an AWS account where you can create IAM identities
Admin Access to IAM – Permissions to create IAM users and roles
ProjectDiscovery Account – Access to ProjectDiscovery’s Cloud platform
Basic AWS IAM Knowledge – Understanding of IAM users, access keys, and roles
Create a Read-Only IAM User: In the AWS IAM console, create a new IAM user for ProjectDiscovery integration. Assign programmatic access (which generates an Access Key ID and Secret Access Key).
Attach Required Policies: Grant the user read-only permissions to the AWS services you want to monitor. You can use AWS-managed policies like AmazonEC2ReadOnlyAccess, AmazonS3ReadOnlyAccess, etc. for each service (see the Required Permissions section below).
Configure in ProjectDiscovery:
Select Single AWS Account (Access Key & Secret)
Enter your AWS Access Key ID and AWS Secret Access Key
Optionally provide a Session Token (only for temporary credentials)
Give the integration a unique name
Select the AWS services you want to monitor
Tip: Use an IAM user with minimal read-only permissions and rotate keys periodically for security.
After configuring the integration, it’s important to verify that ProjectDiscovery is successfully connected and enumerating your AWS assets:
Check Asset Discovery: In the ProjectDiscovery platform, navigate to the cloud assets or inventory section. After a successful integration, you should start seeing resources from your AWS account(s) listed (for example, EC2 instance IDs, S3 bucket names, etc., corresponding to the integrated accounts). It may take a short while for the initial discovery to complete. If you see those assets, the integration is working.
Test with a Known Resource: As a quick test, pick a known resource (like a specific EC2 instance or S3 bucket in your AWS account) and search for it in ProjectDiscovery’s asset inventory. If it appears, the connection is functioning and pulling data.
Troubleshooting Errors: If the integration fails or some assets are missing, consider these common issues:
Incorrect Credentials: Double-check that the Access Key and Secret (if used) were entered correctly and correspond to an active IAM user. If you recently created the user, ensure you copied the keys exactly (no extra spaces or missing characters).
Insufficient Permissions: If certain services aren’t showing up, the IAM policy might be missing permissions. For example, if S3 buckets aren’t listed, confirm that the policy includes s3:ListAllMyBuckets. Refer back to the Required Permissions and make sure all relevant actions are allowed. You can also use AWS IAM Policy Simulator or CloudTrail logs to see if any AccessDenied errors occur when ProjectDiscovery calls AWS APIs.
Assume Role Failures: In multi-account or cross-account setups, a common issue is a misconfigured trust relationship. If ProjectDiscovery cannot assume a role, you might see an error in the UI or logs like “AccessDenied: Not authorized to perform sts:AssumeRole”. In that case, check the following:
The trust policy of the IAM role (in target account) trusts the correct principal (either your primary account’s IAM user/role ARN for multi-account, or ProjectDiscovery’s external account ID for cross-account) and the External ID if applicable.
The role name or ARN in the ProjectDiscovery config exactly matches the one in AWS (spelling/case must match).
The primary credentials (for multi-account) have permission to call AssumeRole.
External ID Mismatch: For cross-account roles, if the external ID in ProjectDiscovery and the one in the IAM role’s trust policy do not match, AWS will deny the assume request. Ensure you didn’t accidentally copy the wrong value or include extra spaces. It must be exact.
AWS CloudTrail Logs: As an additional verification, you can check AWS CloudTrail in your account. When ProjectDiscovery connects, you should see events like DescribeInstances, ListBuckets, etc., being called by the IAM user or assumed role. For cross-account roles, you will see an AssumeRole event from ProjectDiscovery’s AWS account ID, and subsequent calls under the assumed role’s identity. This audit trail can confirm that the integration is working as intended and using only allowed actions.
If all checks out, ProjectDiscovery is now actively monitoring your AWS environment. New resources launched in AWS should be detected on the next scan cycle, and any changes to your cloud footprint will be reflected in the platform. Make sure to regularly review the integration and update the IAM permissions if you start using new AWS services.
ProjectDiscovery’s GCP integration allows the platform to automatically discover and monitor cloud assets across your GCP account. The integration supports two discovery approaches to accommodate different organizational structures and permission models.
ProjectDiscovery supports monitoring multiple GCP organizations simultaneously. Simply configure multiple integrations with different organization IDs to get consolidated asset discovery across all your GCP environments (e.g., production, staging, development organizations).
In the top navigation, click on the project selector (next to “Google Cloud Platform”)
Click All tab to view all resources
Look for your organization name - the Organization ID is displayed next to it
Alternatively, go to IAM & Admin > Settings - your Organization ID will be shown at the top
Via gcloud CLI:
Copy
Ask AI
# List all organizations you have access togcloud organizations list# Get current organization (if configured)gcloud config get-value projectgcloud projects describe $(gcloud config get-value project) --format="value(parent.id)"
Before setting up the integration, verify you have the necessary permissions:
For Organization-Level Integration:
Copy
Ask AI
# Check if you can list organization assetsgcloud organizations list# Check if you have the required rolesgcloud organizations get-iam-policy YOUR_ORG_ID --flatten="bindings[].members" --format="table(bindings.role)" --filter="bindings.members:user:YOUR_EMAIL"
To connect ProjectDiscovery to your Azure account, you will need to create and configure an App Registration in Azure Active Directory. This process generates a Service Principal with the necessary credentials and permissions to monitor your cloud assets in a secure, read-only manner.
The required credentials are:
Azure Tenant ID
Azure Subscription ID
Azure Client ID
Azure Client Secret
Below are the steps to get the above credentials:
Create App Registration:
Go to Azure Active Directory > App registrations > + New registration.
From the app’s Overview page, collect the Application (client) ID and Directory (tenant) ID.
Generate Client Secret:
In the app, navigate to Certificates & secrets > + New client secret.
CRITICAL: Copy the secret Value immediately, as it is shown only once.
Assign Permissions:
Go to your Subscription > Access control (IAM).
Add a role assignment to grant the Reader role to the App Registration you created.
Note your Subscription ID from the subscription’s overview page.
Connect:
Enter the four collected credentials (Tenant ID, Client ID, Client Secret, and Subscription ID) into ProjectDoscovery Cloud Platform to configure the integration.
To use CLI, follow the instructions mentioned in the references below.
This guide details the secure, best-practice method for connecting to Alibaba Cloud using a dedicated RAM user with read-only permissions.
Create a RAM User for API Access:
Navigate to the RAM (Resource Access Management) console. Ref
From the left menu, go to Identities > Users and click Create User.
Enter a Logon Name (e.g., projectdiscovery-readonly).
For Access Mode, select OpenAPI Access and click OK. This is for programmatic access, not console login.
Securely Store the Access Key: An AccessKey pair is generated immediately after the user is created. This is the only time the secret is shown.
On the confirmation screen, copy the AccessKey ID and the AccessKey Secret. Store them in a secure location immediately. The secret cannot be retrieved after you close this dialog.
Grant Read-Only Permissions:
Return to the Users list.
Find the user you just created and click Add Permissions in the Actions column.
Select the System Policy type.
Search for and select the AliyunReadOnlyAccess policy and click OK. This is the official, managed policy for read-only access to all cloud resources.
Find Your Region ID and Connect:
Identify the Region ID for the resources you plan to monitor. You can find the official list in the Alibaba Cloud documentation here: Regions and zones (This link lists the specific IDs required for API configuration).
Use the credentials you have collected to fill in the fields in ProjectDiscovery:
Alibaba Region ID: The target region, for example, us-east-1.
Alibaba Access Key: The AccessKey ID from Step 2.
Alibaba Access Key Secret: The AccessKey Secret from Step 2.
Under API, click Create API token if you don’t already have one.
Copy the API Key.
Now enter API Key in ProjectDiscovery Cloud Platform.
Give a unique Integration name and click Verify.
Tip: In Fastly’s documentation and interfaces, “API Key” and “API Token” refer to the same thing. You can use the terms interchangeably throughout this guide.