Platform Integrations

​

Notification Integrations

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.

​

Slack

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

• Refer to Slack’s documentation on creating webhooks for configuration details.

​

MS Teams

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.

• Refer to Microsoft’s documentation on creating webhooks for configuration details.

​

Email

ProjectDiscovery supports notifications via Email. To enable email notifications for completed scans simply add your recipient email addresses.

​

Webhook

ProjectDiscovery supports custom webhook notifications, allowing you to post events to any HTTP endpoint that matches your infrastructure requirements.

To implement webhook notifications, provide:

• Configuration name

• Webhook URL

• Authentication parameters (if required)

Example endpoint format:

https://your-domain.com/api/security/alerts

​

Ticketing Integrations

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.

​

Jira

ProjectDiscovery provides integration support for Jira to create new tickets when vulnerabilities are found.

Provide a name for the configuration, the Jira instance URL , the Account ID, the Email, and the associated API token.

Details on creating an API token are available in the Jira documentation here.

​

GitHub

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.

Details on setting up access in GitHub are available here.

​

GitLab

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.

Refer to GitLab’s documentation for details on configuring a Project Access token.

​

Linear

ProjectDiscovery integrates with Linear for automated issue tracking. The integration requires the following API parameters:

1. Linear API Key

2. Linear Team ID

3. Linear Open State ID

To retrieve these parameters:

1. API Key Generation:

   • Path: Linear > Settings > API > Personal API keys

   • Direct URL: linear.app/[workspace]/settings/api

2. Team ID Retrieval:

query {
  teams {
    nodes {
      id
      name
    }
  }
}

1. Open State ID Retrieval:

query {
  workflowStates {
    nodes {
      id
      name
    }
  }
}

For detailed API documentation, refer to the Linear API Documentation.

​

Cloud Asset Discovery

ProjectDiscovery leverages our open-source Cloudlist technology to provide comprehensive cloud asset discovery and management through a simple web interface.

​

AWS (Amazon Web Services)

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.

Supported AWS Services:

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 Connection Methods

ProjectDiscovery supports three methods to connect to AWS, each suited for different use cases and security preferences:

1. 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.

2. 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.

3. 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

​

1. Single AWS Account (Access Key & Secret)

To connect a single AWS account directly:

1. 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).

2. 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).

3. 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.

​

2. Multiple AWS Accounts (Assume Role)

For monitoring multiple AWS accounts from a central account:

1. Choose a Primary Account: Create an IAM user in one AWS account (the “primary”) with programmatic access.

2. Create an IAM Role in Each Target Account: In each AWS account you want to monitor, create a role that:

   • Uses the same role name across all accounts (e.g., “ProjectDiscoveryReadOnlyRole”)
   • Has a trust relationship allowing your primary account to assume it
   • Has the required read-only permissions

3. Configure in ProjectDiscovery:

   • Select Multiple AWS Accounts (Assume Role)
   • Enter the primary account’s AWS Access Key ID and Secret Access Key
   • Specify the Role Name to Assume (the common role name)
   • List all AWS Account IDs to monitor (one per line)
   • Give the integration a unique name
   • Select the AWS services you want to monitor

​

3. Cross-Account Role (Role ARN)

The most secure method using ProjectDiscovery’s service account:

1. Create an IAM Role in Your AWS Account:

   • In your AWS console, go to IAM → Roles → Create Role
   • Select “Another AWS account” as the trusted entity
   • Enter ProjectDiscovery’s ARN: arn:aws:iam::034362060511:user/projectdiscovery
   • Enable “Require External ID” and enter the External ID shown in the ProjectDiscovery UI
   • Attach the necessary read-only permissions

2. Configure in ProjectDiscovery:

   • Select Cross-Account Role (Role ARN)
   • Enter the Role ARN of the role you created
   • Give the integration a unique name
   • Select the AWS services you want to monitor

Required Permissions

ProjectDiscovery needs read-only access to your AWS assets. The following AWS-managed policies are recommended:

• EC2 - AmazonEC2ReadOnlyAccess
• Route53 - AmazonRoute53ReadOnlyAccess
• S3 - AmazonS3ReadOnlyAccess
• Lambda - AWSLambda_ReadOnlyAccess
• ELB - ElasticLoadBalancingReadOnly
• Cloudfront - CloudFrontReadOnlyAccess

Alternatively, you can use this custom policy for minimal permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequiredReadPermissions",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
        "route53:ListHostedZones",
        "route53:ListResourceRecordSets",
        "s3:ListAllMyBuckets",
        "lambda:ListFunctions",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:DescribeTargetHealth",
        "cloudfront:ListDistributions",
        "ecs:ListClusters",
        "ecs:ListServices",
        "ecs:ListTasks",
        "ecs:DescribeTasks",
        "ecs:DescribeContainerInstances",
        "eks:ListClusters",
        "eks:DescribeCluster",
        "apigateway:GET",
        "lightsail:GetInstances",
        "lightsail:GetRegions"
      ],
      "Resource": "*"
    }
  ]
}

Verifying the Integration

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.

References:

1. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam_read-only-console.html

2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html

3. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html

4. https://docs.aws.amazon.com/sdkref/latest/guide/feature-assume-role-credentials.html

5. https://docs.logrhythm.com/OCbeats/docs/aws-cross-account-access-using-sts-assume-role

​

Google Cloud Platform (GCP)

Supported GCP Services:

• Cloud DNS

• Kubernetes Engine

• Compute Engine

• Bucket

• Cloud Functions

• Cloud Run

Google Cloud Platform can be integrated by using the following configuration block.

- provider: gcp # provider is the name of the provider
  # profile is the name of the provider profile
  id: logs
  # gcp_service_account_key is the minified json of a google cloud service account with list permissions
  gcp_service_account_key: '{xxxxxxxxxxxxx}'

gcp_service_account_key can be retrieved by creating a new service account. To do so, create service account with Read Only access to cloudresourcemanager and dns scopes in IAM. Next, generate a new account key for the Service Account by following steps in Reference 2. This should give you a json which can be pasted in a single line in the gcp_service_account_key.

Scopes Required: Cloud DNS, GKE

References:

1. https://cloud.google.com/iam/docs/service-account-overview

​

Azure

Supported Azure Services:

• Virtual Machines

Example Config:

Microsoft Azure can be integrated by using the following configuration block.

- provider: azure # provider is the name of the provider
  # id is the name defined by user for filtering (optional)
  id: staging
  # client_id is the client ID of registered application of the azure account (not requuired if using cli auth)
  client_id: $AZURE_CLIENT_ID
  # client_secret is the secret ID of registered application of the zure account (not requuired if using cli uth)
  client_secret: $AZURE_CLIENT_SECRET
  # tenant_id is the tenant ID of registered application of the azure account (not requuired if using cli auth)
  tenant_id: $AZURE_TENANT_ID
  #subscription_id is the azure subscription id
  subscription_id: $AZURE_SUBSCRIPTION_ID
  #use_cli_auth if set to true cloudlist will use azure cli auth
  use_cli_auth: true

tenant_id, client_id, client_secret can be obtained/generated from All services > Azure Active Directory > App registrations subscription_id can be retrieved from All services > Subscriptions

To use cli auth set use_cli_auth value to true and run az login in the terminal

References:

1. https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli

2. https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest#az_ad_sp_create_for_rbac

3. https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli

​

Alibaba Cloud

Suppoted Alibaba Cloud Services:

• ECS Instances

Example Config:

Alibaba Cloud can be integrated by using the following configuration block.

- provider: alibaba # provider is the name of the provider
  # id is the name defined by user for filtering (optional)
  id: staging
  # alibaba_region_id is the region id of the resources
  alibaba_region_id: $ALIBABA_REGION_ID
  # alibaba_access_key is the access key ID for alibaba cloud account
  alibaba_access_key: $ALIBABA_ACCESS_KEY
  # alibaba_access_key_secret is the secret access key for alibaba cloud account
  alibaba_access_key_secret: $ALIBABA_ACCESS_KEY_SECRET

Alibaba Cloud Access Key ID and Secret can be created by visiting https://ram.console.aliyun.com/manage/ak

References:

1. https://www.alibabacloud.com/help/faq-detail/142101.htm

2. https://www.alibabacloud.com/help/doc-detail/53045.htm

​

Infrastructure & Platform Services

​

Kubernetes

Support for:

• Services

• Ingresses

• Cross-cloud cluster discovery

Navigate to Assets → Connect Cloud Services → Kubernetes to configure your cluster access.

​

Hashicorp Stack

Support for:

• Terraform state file parsing

• Nomad services

• Consul services

​

CDN & DNS Providers

Configure these providers through Assets → Connect Cloud Services:

• Cloudflare: DNS and CDN assets

• Fastly: CDN endpoints

• Namecheap: Domain management

​

VPS & PaaS Providers

Access these providers through Assets → Connect Cloud Services:

• DigitalOcean: Droplets and managed services

• Scaleway: Instances and managed services

• Heroku: Applications and add-ons

• Linode: Compute instances

• Hetzner Cloud: Cloud servers