Introduction
Providers form the backbone of Prowler, enabling security assessments across various cloud environments. A provider is any platform or service that offers resources, data, or functionality that can be audited for security and compliance. This includes:- Cloud Infrastructure Providers (like Amazon Web Services, Microsoft Azure, and Google Cloud)
- Software as a Service (SaaS) Platforms (like Microsoft 365)
- Development Platforms (like GitHub)
- Container Orchestration Platforms (like Kubernetes)
- Database-as-a-Service Platforms (like MongoDB Atlas)
There are some custom providers added by the community, like NHN Cloud, that are not maintained by the Prowler team, but can be used in the Prowler CLI. The main purpose of this documentation is to guide you through creating a new provider and integrating it not only in the CLI, but also in the API and UI. Non official providers can be checked directly at the Prowler GitHub repository.
Provider Types in Prowler
Prowler supports several types of providers, each with its own implementation pattern and use case. Understanding these differences is key to designing your provider correctly.Classifying your Provider
Before implementing a new provider, you need to determine which type it belongs to. This classification will guide your implementation approach and help you choose the right patterns and libraries.Decision Criteria
Once you have decided the provider you want or need to add to Prowler, the next step is to study how to retrieve data from it. Based on that, the provider will fall into one of the following types: SDK, API or Tool/Wrapper (maybe in the future there will be new types but for now this are the only ones). Choose SDK Provider if:- The target platform/service has an official Python SDK available
- The target platform/service has a non-official Python SDK available but it’s been updated and maintained
- You need to support multiple authentication methods (profiles, service principals, IAM roles, etc.)
- The SDK provides built-in session management, retry logic, and error handling
- You want to leverage SDK-specific features like credential chaining, role assumption, etc
- The platform is a major cloud provider (AWS, Azure, GCP, etc.) or has mature SDK support
- The target platform has a REST API but no official Python SDK
- The target platform has a non-official Python SDK available but it’s not updated and maintained
- You need to implement custom authentication flows (OAuth, token-based, etc.)
- The platform is a custom or community service without official SDK support
- You want to use standard HTTP libraries like
requestsfor API calls - The platform exposes well-documented REST endpoints but lacks SDK tooling
- You’re integrating a third-party security tool or library
- The tool provides scanning capabilities that need to be adapted to Prowler’s interface
- You don’t need authentication or session management (the tool handles this)
- You need to map tool arguments and convert outputs to Prowler’s format
- Some providers may combine multiple approaches (e.g., SDK + Tool wrapper, SDK + API, etc.)
- Example: M365 uses msgraph SDK for authentication and some checks, and PowerShell wrapper for other checks that the SDK doesn’t support
- These require custom implementation patterns that blend different provider types
Classification Examples
| Provider | Type | Reasoning |
|---|---|---|
| AWS | SDK | Official boto3 SDK, multiple auth methods, mature ecosystem |
| Azure | SDK | Official azure-identity SDK, service principals, managed identity |
| GCP | SDK | Official google-auth SDK, service accounts, ADC support |
| Kubernetes | SDK | Official kubernetes SDK, service accounts, ADC support |
| NHN Cloud | API | Custom REST API, no official SDK, community provider |
| MongoDB Atlas | API | Custom REST API, no official SDK |
| IAC | Tool | Third-party security tool that uses trivy, no auth needed, output conversion |
| M365 | Hybrid | Combines msgraph SDK for auth + PowerShell wrapper for operations |
| GitHub | Hybrid | Non-Official PyGithub SDK but it’s been updated and maintained + Official graphql API requests |
Questions to Ask Yourself
1. Does the platform have an official Python SDK?- Yes → Consider SDK Provider
- No → Continue to question 2
- Yes → Then if the SDK is updated and maintained, consider SDK Provider, otherwise continue to question 3.
- No → Continue to question 3
- Yes → Consider Tool/Wrapper Provider
- No → Continue to question 4
- Yes → Consider API Provider
- No → You may need a custom approach

Implementation Complexity
- SDK Providers: Low complexity. You have mature examples like AWS, Azure, GCP, Kubernetes, etc. that you can leverage to implement your provider.
- API Providers: Medium complexity. You need to implement the authentication and session management, and the API calls to the provider. You now have NHN and MongoDB Atlas as example to follow.
- Tool/Wrapper Providers: High complexity. You need to implement the argument/output mapping to the provider and handle problems that the tool/wrapper may have. You now have IAC and the PowerShell wrapper as example to follow.
- Hybrid Providers: High complexity. You need to “customize” your provider, mixing the other types of providers in order to achieve the desired result. You have M365 (msgraph SDK + PowerShell wrapper) and Github (PyGithub SDK + graphql API requests) as examples.
Determining Regional vs Non-Regional Architecture
After classifying your provider type, the next critical decision is determining whether your provider operates with regional concepts or is global/non-regional. This decision fundamentally affects how your provider and services are structured and executed.Regional Providers
Regional providers operate across multiple geographic locations and require region-specific resource discovery and iteration. Examples:- AWS: Has regions like
us-east-1,eu-west-1,ap-southeast-2 - Azure: Has regions like
East US,West Europe,Australia East - GCP: Has regions like
us-central1,europe-west1,asia-southeast1
- Must implement region discovery and iteration
- Services must be instantiated per region or handle multi-region data
- Checks must execute across all available/specified regions
- Resource ARNs/IDs must include region information
- Region-specific client initialization
Non-Regional (Global) Providers
Non-regional providers operate globally without geographic partitioning. Examples:- GitHub: Repositories, organizations are global concepts
- M365: Tenants operate globally across Microsoft datacenters
- Kubernetes: Clusters are independent units without regional concepts
- Single global client/session
- No region iteration required
- Global resource discovery
- Simpler resource identification (no region in ARNs/IDs)
- Single audit execution
Decision Matrix
| Aspect | Regional Provider | Non-Regional Provider |
|---|---|---|
| Client Init | Per-region clients | Single global client |
| Resource Discovery | Iterate through regions | Single discovery call |
| Resource ARN/ID | Include region | Global identifier/None |
| Audit Execution | Multi-region loops | Single execution |
| Service Architecture | Region-aware services | Global services |
| Performance | Parallelizable by region | Linear execution |
Region Discovery
Region discovery is the process of getting the list of regions that are available for the account. This is done by the provider and is stored in theprowler/providers/<provider_name>/lib/regions/<provider_name>_regions.py file.
Regional Service Implementation
For detailed guidance on implementing services for regional services, including code examples, service architecture, and check execution patterns, see the Regional Service Implementation section in the Services documentation. Key concepts covered:- Threading and parallel processing across regions
- Service implementation patterns for regional providers
- Cross-region resource attribution and ARN handling
- Best practices for performance and error isolation
Step 1: Create the Provider Backend (CLI Integration)
Once the type of provider and its regional architecture are determined, the next step is to start creating the code of the provider.SDK Providers
General aspects to consider when implementing a new SDK provider: Definition:- Use the official SDK of the provider to interact with its resources and APIs.
- Examples: AWS (boto3), Azure (azure-identity), GCP (google-auth), Kubernetes (kubernetes), M365 (msal/msgraph), GitHub (PyGithub).
- Cloud platforms and services with mature Python SDKs.
- Need to support multiple authentication methods (profiles, service principals, etc).
- Providers that offer comprehensive Python libraries for resource management.
- Authentication and session management handled by the SDK.
- Arguments: Depends on the provider, but for example we can have
profile,region,tenant_id,client_id,client_secret, etc. - Outputs: Standardized via SDK models and responses.
- Session objects that can be reused across multiple API calls.
- Built-in retry logic and error handling.
- SDK providers typically use credential objects or session objects provided by the official SDK.
- They often support multiple authentication methods (several types of credentials, configuration files, IAM roles, etc.).
- Session management includes token refresh, connection pooling, and retry mechanisms.
- Resource discovery and enumeration is usually straightforward through SDK methods.
Implementation Guide for SDK Providers
Now it’s time to start creating the code needed to implement the provider.Step 1: Create the Provider Structure
Explanation: SDK providers require a specific folder structure to organize authentication, configuration, and service management. This structure follows Prowler’s conventions and ensures proper integration with the CLI and API. Required Structure:<provider_name>_provider.py: Main provider class with authentication and session managementmodels.py: Data structures for identity, session, and provider-specific informationexceptions/: Custom exception classes for error handlingservices/: Folder that contains all the provider services, how to make a new service is explained in another section.lib/arguments/: CLI argument validation and parsinglib/mutelist/: Resource exclusion and muting functionalitylib/regions/: Region management and validation. If the provider is NOT regional, this folder will not be created.lib/service/: Base service class for provider-specific services
Step 2: Implement the Provider Class
Explanation: The provider class is the core component that handles authentication, session management, and identity information. It inherits from Prowler’s base Provider class and implements SDK-specific authentication flows. All providers must share, as far as possible, common patterns for session setup, identity management, and credential validation. Nevertheless, you may encounter changes and must adapt the implementation logic accordingly. A basic example of a common provider implementation is the following: File:prowler/providers/<provider_name>/<provider_name>_provider.py
Step 3: Create Models
Explanation: Models define the data structures used by your provider. They include identity information, session details, and provider-specific configurations. These models ensure type safety and consistent data handling across the provider. File:prowler/providers/<provider_name>/models.py
Step 4: Implement Arguments
Explanation: Argument validation ensures that the provider receives valid configuration parameters. This step is crucial for preventing runtime errors and providing clear error messages to users. The validation should check for required parameters and validate their format. File:prowler/providers/<provider_name>/lib/arguments/arguments.py
Step 5: Implement Mutelist
Explanation: The mutelist functionality allows users to exclude specific resources or checks from the audit. This is useful for handling false positives or excluding resources that are intentionally configured differently. File:prowler/providers/<provider_name>/lib/mutelist/mutelist.py
Step 6: Implement Regions
Explanation: Region management is essential for cloud providers that operate across multiple geographic locations. This component handles region validation and provides region-specific functionality.Regions are optional, only if the provider has regions, for example Github does not have regions, but AWS does.
prowler/providers/<provider_name>/lib/regions/<provider_name>_regions.py
Step 7: Create Custom Exceptions
Explanation: Custom exceptions are needed to be able to handle the errors in a more specific way. Prowler uses a structured exception system with error codes, messages, and remediation steps. File:prowler/providers/<provider_name>/exceptions.py
Step 8: Implement Service Base Class
Explanation: The service base class defines a common interface for all services in your provider, since they will inherit from it. It defines the client to make requests to, the audit configuration and the fixer configuration. File:prowler/providers/<provider_name>/lib/service/service.py
Step 9: Register in CLI
Explanation: Add your provider to the available providers in the CLI. File:prowler/lib/cli/parser.py
Step 10: Register in Main
Explanation: Main registration makes your provider discoverable by Prowler’s core system. It’s needed to add your provider to the output options and to the compliance evaluation. File:prowler/__main__.py
Step 11: Register in the list of providers
Explanation: This is needed to be able to use the provider in the generic checks. The provider must be registered in theinit_global_provider method to handle CLI arguments and initialization.
File: prowler/providers/common/provider.py
Step 12: Add to Config
Explanation: Configuration registration ensures your provider is recognized by Prowler’s configuration system. This enables proper handling of provider-specific settings and defaults. File:prowler/config/config.py
prowler/providers/aws/config.py.
Step 13: Create Compliance Files
Explanation: Compliance files define the security checks and standards that your provider supports. These JSON files map security controls to specific checks and provide remediation guidance. It’s needed to create the folder with an init file to ensure the provider will work, however, adding different compliance files is optional. Folder:prowler/compliance/<provider_name>/
Step 14: Add Output Support
Explanation: Output support ensures that your provider’s results are properly formatted in Prowler’s various output formats (CSV, JSON, HTML, etc.). This step integrates your provider with Prowler’s reporting system. File:prowler/lib/outputs/summary_table.py
prowler/lib/outputs/finding.py
prowler/lib/outputs/outputs.py
Step 15: Generate the HTML Report
Explanation: The HTML file is needed to be able to generate the HTML report. This step involves adding support for your provider in the HTML output generation system to ensure proper display of assessment summaries and findings. File:prowler/lib/outputs/html/html.py
Step 16: Add the Check Report Model
Explanation: Add the provider to the generic models, this is needed to be able to use the provider in the generic checks. File:prowler/providers/check/models.py
Step 17: Add Dependencies
Explanation: Dependencies ensure that your provider’s required libraries are available when Prowler is installed. This step adds the necessary SDK or API client to Prowler’s dependency management. File:pyproject.toml
Step 18: Create Tests
Explanation: Testing ensures that your provider works correctly and maintains compatibility as Prowler evolves. Comprehensive tests cover authentication, session management, and provider-specific functionality. Folder:tests/providers/<provider_name>/
Step 19: Update Documentation
Explanation: Documentation updates ensure that users can find information about your provider in Prowler’s documentation. This includes examples, configuration guides, and troubleshooting information. Update the provider documentation to include your new provider in the examples and implementation guidance.API Providers
Definition:- Interact directly with the provider’s REST API using HTTP requests (e.g., via
requests). - Examples: NHN Cloud.
- Providers without an official Python SDK.
- Providers with a non-official Python SDK that is not updated and maintained.
- Providers that expose REST APIs and meet above requirements.
- Manual management of authentication (tokens, username/password, etc).
- Arguments: Depends on the provider, for example,
username,password,tenant_id, etc. - Outputs: Dicts or custom models based on API responses.
- Custom HTTP session management with headers and authentication.
- Manual handling of pagination, rate limiting, and error responses.
- API providers require manual HTTP request management using libraries like
requests. - Authentication typically involves obtaining tokens via login endpoints or OAuth flows.
- Session management includes setting appropriate headers (Authorization, Content-Type, etc.).
- Resource discovery often requires multiple API calls to different endpoints.
- Error handling and retry logic must be implemented manually.
Implementation Guide for API Providers
Step 1: Create the Provider Structure
Explanation: API providers require the same structure as the SDK providers, the main difference would be that due to the lack of an official Python SDK, some methods could be implemented differently or not implemented at all. Required Structure:<provider_name>_provider.py: Main provider class with HTTP session managementmodels.py: Data structures for identity and API responsesexceptions/: Custom exception classes for API errorsservices/: Folder that contains all the provider serviceslib/arguments/: CLI argument validation and parsinglib/mutelist/: Resource exclusion and muting functionalitylib/regions/: Region management and validation. If the provider is NOT regional, this folder will not be created.lib/service/: Base service class for provider-specific services
Step 2: Implement the Provider Class
Explanation: The provider class is the core component that handles HTTP session management, authentication, and identity information. It inherits from Prowler’s base Provider class and implements API-specific authentication flows using direct HTTP requests. File:prowler/providers/<provider_name>/<provider_name>_provider.py
Step 3: Create Models
Explanation: Models define the data structures used by your API provider. They include identity information and API response structures. These models ensure type safety and consistent data handling across the provider. File:prowler/providers/<provider_name>/models.py
This step is common with SDK providers so you can follow the same pattern as there.
Step 4: Implement Arguments
Explanation: Argument validation ensures that the API provider receives valid configuration parameters. This step is crucial for preventing runtime errors and providing clear error messages to users. File:prowler/providers/<provider_name>/lib/arguments/arguments.py
Arguments depends on the provider and not the type, so the pattern for this step is the same as the SDK providers.
Step 5: Implement Mutelist
Explanation: The mutelist functionality allows users to exclude specific resources or checks from the audit. This is useful for handling false positives or excluding resources that are intentionally configured differently. File:prowler/providers/<provider_name>/lib/mutelist/mutelist.py
The implementation of the mutelist is the same as the SDK providers.
Step 6: Implement Regions
Explanation: Region management is essential for cloud providers that operate across multiple geographic locations. This component handles region validation and provides region-specific functionality.Regions are optional, only if the provider has regions, for example Github does not have regions, but AWS does.
prowler/providers/<provider_name>/lib/regions/<provider_name>_regions.py
The implementation of the regions is the same as the SDK providers.
Step 7: Create Custom Exceptions
Explanation: Custom exceptions provide specific error handling for API-related issues, making debugging and error reporting more effective. Prowler uses a structured exception system with error codes, messages, and remediation steps. File:prowler/providers/<provider_name>/exceptions/exceptions.py
Step 8: Implement Service Base Class
Explanation: The service base class defines a common interface for all services in your provider, since they will inherit from it. It defines the client to make requests to, the audit configuration and the fixer configuration. File:prowler/providers/<provider_name>/lib/service/service.py
Step 9: Register in CLI
Explanation: Add your provider to the available providers in the CLI. File:prowler/lib/cli/parser.py
This step is the same as the SDK providers.
Step 10: Register in Main
Explanation: Main registration makes your provider discoverable by Prowler’s core system. It’s needed to add your provider to the output options and to the compliance evaluation. File:prowler/__main__.py
This step is the same as the SDK providers.
Step 11: Register in the list of providers
Explanation: This is needed to be able to use the provider in the generic checks. The provider must be registered in theinit_global_provider method to handle CLI arguments and initialization.
File: prowler/providers/common/provider.py
This step is the same as the SDK providers.
Step 12: Add to Config
Explanation: Configuration registration ensures your API provider is recognized by Prowler’s configuration system. This enables proper handling of provider-specific settings and defaults. File:prowler/config/config.py
This step is the same as the SDK providers.
Step 13: Create Compliance Files
Explanation: Compliance files define the security checks and standards that your provider supports. These JSON files map security controls to specific checks and provide remediation guidance. It’s needed to create the folder with an init file to ensure the provider will work, however, adding different compliance files is optional. Folder:prowler/compliance/<provider_name>/
This step is the same as the SDK providers.
Step 14: Add Output Support
Explanation: Output support ensures that your provider’s results are properly formatted in Prowler’s various output formats (CSV, JSON, HTML, etc.). This step integrates your provider with Prowler’s reporting system. File:prowler/lib/outputs/summary_table.py
This step is the same as the SDK providers.
Step 15: Generate the HTML Report
Explanation: The HTML file is needed to be able to generate the HTML report. This step involves adding support for your provider in the HTML output generation system to ensure proper display of assessment summaries and findings. File:prowler/lib/outputs/html/html.py
This step is the same as the SDK providers.
Step 16: Add the Check Report Model
Explanation: Add the provider to the generic models, this is needed to be able to use the provider in the generic checks. File:prowler/providers/check/models.py
This step is the same as the SDK providers.
Step 17: Create Tests
Explanation: Testing ensures that your API provider works correctly and maintains compatibility as Prowler evolves. Comprehensive tests cover authentication, session management, and API-specific functionality. Folder:tests/providers/<provider_name>/
Step 18: Update Documentation
Explanation: Documentation updates ensure that users can find information about your API provider in Prowler’s documentation. This includes examples, configuration guides, and troubleshooting information. Update the provider documentation to include your new API provider in the examples and implementation guidance.Tool/Wrapper Providers
Definition:- Integrate third-party tools as libraries or subprocesses (e.g., Trivy for IaC).
- Examples: IaC (Trivy).
- Providers that require integration with external security tools.
- Tools that need to be executed as subprocesses or imported as libraries.
- Providers that require specific tool configurations and argument mapping.
- Legacy systems or tools that don’t have direct API access.
- No session/identity management required (tool handles this internally).
- Arguments: specific to the tool, but for example:
scan_path,frameworks,exclude_path,scan_repository_url, etc. - Outputs: Tool-specific output formats that need to be parsed and converted.
- Tool execution and output parsing.
- Configuration file mapping and argument translation.
- Tool providers typically execute external tools as subprocesses (e.g.,
pwshortrivycommand). - They require mapping between Prowler’s interface and the tool’s arguments.
- Output parsing and conversion to Prowler’s standard format is crucial.
- Tool-specific configuration files and validation.
- Repository cloning and temporary file management for remote scans (if needed).
Implementation Guide for Tool/Wrapper Providers
Step 1: Create the Provider Structure
Explanation: Tool/Wrapper providers require a specific folder structure to organize tool integration, configuration, and service management. This structure follows Prowler’s conventions and ensures proper integration with the CLI and API. Required Structure:<provider_name>_provider.py: Main provider class with tool integrationmodels.py: Data structures for tool output and configurationlib/arguments/: CLI argument validation and parsing
Step 2: Implement the Provider Class
Explanation: The provider class is the core component that handles tool integration, execution, and output parsing. It inherits from Prowler’s base Provider class and implements tool-specific execution flows using subprocesses or library calls. File:prowler/providers/<provider_name>/<provider_name>_provider.py
Step 3: Create Models
Explanation: Models define the data structures used by your tool provider. They include output options and tool-specific configurations. These models ensure type safety and consistent data handling across the provider. File:prowler/providers/<provider_name>/models.py
Step 4: Implement Arguments
Explanation: Argument validation ensures that the tool provider receives valid configuration parameters. This step is crucial for preventing runtime errors and providing clear error messages to users. File:prowler/providers/<provider_name>/lib/arguments/arguments.py
Step 5: Register in CLI
Explanation: Add your provider to the available providers in the CLI. File:prowler/lib/cli/parser.py
This step is the same as the SDK providers.
Step 6: Register in Main
Explanation: Main registration makes your provider discoverable by Prowler’s core system. It’s needed to add your provider to the output options and to the compliance evaluation. File:prowler/__main__.py
This step is the same as the SDK providers.
Step 7: Register in the list of providers
Explanation: This is needed to be able to use the provider in the generic checks. The provider must be registered in theinit_global_provider method to handle CLI arguments and initialization.
File: prowler/providers/common/provider.py
This step is the same as the SDK providers.
Step 8: Add to Config
Explanation: Configuration registration ensures your tool provider is recognized by Prowler’s configuration system. This enables proper handling of provider-specific settings and defaults. File:prowler/config/config.py
This step is the same as the SDK providers.
In some cases, you may need to create a new configuration file for your provider, for example, the AWS one that is inside prowler/providers/aws/config.py.
Step 9: Create Compliance Files
Explanation: Compliance files define the security checks and standards that your provider supports. These JSON files map security controls to specific checks and provide remediation guidance. It’s needed to create the folder with an init file to ensure the provider will work, however, adding different compliance files is optional. Folder:prowler/compliance/<provider_name>/
This step is the same as the SDK providers.
Step 10: Add Output Support
Explanation: Output support ensures that your provider’s results are properly formatted in Prowler’s various output formats (CSV, JSON, HTML, etc.). This step integrates your provider with Prowler’s reporting system. File:prowler/lib/outputs/summary_table.py
This step is the same as the SDK providers.
Step 11: Generate the HTML Report
Explanation: The HTML file is needed to be able to generate the HTML report. This step involves adding support for your provider in the HTML output generation system to ensure proper display of assessment summaries and findings. File:prowler/lib/outputs/html/html.py
This step is the same as the SDK providers.
Step 12: Add the Check Report Model
Explanation: Add the provider to the generic models, this is needed to be able to use the provider in the generic checks. File:prowler/providers/check/models.py
This step is the same as the SDK providers.
Step 13: Create Tests
Explanation: Testing ensures that your tool provider works correctly and maintains compatibility as Prowler evolves. Comprehensive tests cover tool execution, output parsing, and provider-specific functionality. Folder:tests/providers/<provider_name>/
Step 14: Update Documentation
Explanation: Documentation updates ensure that users can find information about your tool provider in Prowler’s documentation. This includes examples, configuration guides, and troubleshooting information. Update the provider documentation to include your new tool provider in the examples and implementation guidance.Step 2: Integrate the Provider in the API
This step is required only if you want your provider to be available in the API and UI. The API integration involves several components:2.1. Backend API Models
Location:api/src/backend/api/models.py
Add your provider to the ProviderChoices enum and implement UID validation:
Provider model already exists and supports all provider types. Ensure your provider type is included in the choices.
2.2. Add the provider to the Provider Choices
Update thereturn_prowler_provider function to include your provider. This function is crucial for the API to instantiate the correct provider class.
File: api/src/backend/api/utils.py
initialize_prowler_provider function:
match statement requires Python 3.10+. If you’re using an older version, you can use traditional if-elif statements instead.
2.3. API Serializers
Create or update serializers for your provider. You’ll need to add your provider to the validation logic: File:api/src/backend/api/v1/serializers.py
api/src/backend/api/v1/serializer_utils/providers.py
2.4. Database Migration
Create a new migration to add your provider to the database. This is crucial for the API to recognize your provider type. File:api/src/backend/api/migrations/XXXX_your_provider.py
- Migration Number: Use the next sequential number (e.g., if latest is 0044, use 0045)
- Dependencies: Update the
dependencieslist to point to the most recent migration - Choices Array: Add your provider to the
choicesarray with proper display name - SQL Operation: The
RunSQLoperation adds your provider to the PostgreSQL enum type - Reverse SQL: Use
migrations.RunSQL.noopsince adding enum values cannot be easily reversed
- Format:
XXXX_your_provider.py(e.g.,0045_your_provider.py) - Use descriptive names that indicate what the migration does
- Follow the existing pattern in the migrations folder
2.5. Update the V1 Yaml
Update the OpenAPI specification (v1.yaml) to include your provider in all relevant endpoints and schemas. This is crucial for API documentation and client generation.
File: api/src/backend/api/specs/v1.yaml
2.5.1. Provider Enum Values
Add your provider to the provider enum in the Provider schema:2.5.2. Provider Credential Schemas
Add your provider’s credential schema to the integration configuration. This defines how your provider’s credentials are structured:2.5.3. Example Provider Schemas
Here are examples of how existing providers are documented: AWS Provider:2.5.4. Important Notes
- Position: Add your schema in the
oneOfarray alongside existing providers - Structure: Follow the exact pattern of other providers (title, properties, required fields)
- Descriptions: Provide clear, helpful descriptions for each field
- Required Fields: Specify which fields are mandatory in the
requiredarray - Field Types: Use appropriate JSON schema types (
string,integer,boolean,email, etc.) - Validation: Add any field-specific validation patterns or constraints
- Documentation: Ensure your provider appears in the generated API documentation
2.6. Testing API Integration
Create tests for your provider: Location:api/src/backend/api/tests/
2.6.1. Add your mocked provider to the tests
If needed, add your mocked provider to the tests config file so you can use it on the tests. File:api/src/backend/conftest.py
2.7. Compliance and Output Support
Add your provider to the compliance export functionality: File:api/src/backend/tasks/jobs/export.py
prowler/lib/outputs/finding.py
2.8. API Endpoints
Your provider will be available through these endpoints:GET /api/v1/providers/- List all providersPOST /api/v1/providers/- Create a new providerGET /api/v1/providers/{id}/- Get provider detailsPUT /api/v1/providers/{id}/- Update providerDELETE /api/v1/providers/{id}/- Delete providerPOST /api/v1/providers/secrets/- Add provider credentials
2.9. Update the provider if needed
Depending on your provider’s authentication requirements, you may need to add new authentication methods that are compatible with the API. This involves updating the provider class to support additional credential types beyond the basic ones.2.9.1. Adding New Authentication Methods
If your provider requires specific authentication methods, you’ll need to:- Update the provider constructor to accept new authentication parameters
- Extend the credential handling to support the new authentication method
- Update the API serializers to include the new credential fields
- Modify the OpenAPI specification to document the new authentication schema
2.9.2. Example: GitHub Provider Authentication Methods
The GitHub provider demonstrates how to implement multiple authentication methods:Step 3: Integrate the Provider in the UI
TBDProvider Implementation Guidance
Use existing providers as templates, this will help you to understand better the structure and the implementation will be easier:- AWS (SDK)
- Azure (SDK)
- GCP (SDK)
- Kubernetes (SDK)
- M365 (SDK/Wrapper)
- GitHub (SDK)
- NHN (API)
- IAC (Tool)
- MongoDB Atlas
Best Practices
-
Code Quality & Documentation
- Comprehensive Docstrings: Every class, method, and function should have detailed docstrings following Prowler’s format
- Type Hints: Use type hints for all function parameters and return values
- Logging: Implement proper logging using Prowler’s logger
-
Error Handling & Validation
- Custom Exceptions: Create provider-specific exceptions for better error handling
- Input Validation: Validate all inputs and provide clear error messages
- Graceful Degradation: Handle errors gracefully without crashing the entire scan
- Raise on Exception: Use
raise_on_exceptionparameter for test methods
-
Testing & Quality Assurance
- Comprehensive Test Coverage: Aim for >80% test coverage
- Test Naming: Use descriptive test names:
test_method_name_scenario - Test Organization: Group related tests in test classes
- Mock External Dependencies: Mock external API calls and services
- Test Edge Cases: Include tests for error conditions and edge cases
- End-to-End Testing: Test the provider on real infrastructure
-
Performance & Security
- Session Management: Reuse sessions when possible, don’t create new ones unnecessarily
- Rate Limiting: Implement rate limiting for API calls to avoid hitting limits
- Resource Cleanup: Ensure proper cleanup of temporary resources
- Authentication Security: Never log sensitive credentials or tokens
-
Code Organization
- Single Responsibility: Each method should have one clear purpose
- Consistent Naming: Follow Prowler’s naming conventions
- Modular Design: Break complex functionality into smaller, testable methods
- Configuration Management: Use configuration files for provider-specific settings
-
Documentation & Maintenance
- README Updates: Update provider-specific documentation
- Changelog: Document changes and new features
- Examples: Provide usage examples and common scenarios
- Troubleshooting: Include common issues and solutions
- Documentation: Update the provider documentation to include your new tool provider in the examples and implementation guidance.
-
Integration Standards
- CLI Consistency: Follow Prowler’s CLI argument patterns
- Output Format: Ensure outputs are compatible with Prowler’s reporting system
- Compliance Mapping: Map provider checks to relevant compliance frameworks
- Backward Compatibility: Maintain compatibility when possible
-
AI-Assisted Development
- Use Rules: Use rules to ensure the code generated by AI is following the way of working in Prowler.
Checklist for New Providers
CLI Integration Only
Phase 1: Research & Planning- Soft research completed
- Spike date scheduled
- Deeper research completed
- Action plan created
- Folder and files created in
prowler/providers/<name> - Provider class implemented and inherits from
Provider - Authentication/session logic implemented
- Arguments/flags mapped and documented
- Outputs and metadata standardized
- Registered in the CLI
- Minimal usage example provided
- PoC delivered
- MVP delivered
- Version 1 completed
- QA and documentation completed
- GA release ready
API Integration
- All CLI integration items completed
- Provider added to
ProviderChoicesenum in API models - API serializers created/updated for the provider
- API views support the new provider type
- Provider credentials model supports the new provider
- API endpoints tested and working
- Provider-specific validation implemented
- API tests created and passing
UI Integration
- TBD

