Skip to content

Security

The azure-functions-doctor project maintains a commitment to providing a secure tool for diagnosing Azure Functions local development environments. This document outlines the security policies, reporting processes, and the trust model for using and extending the tool.

Reporting Vulnerabilities

We take security issues seriously. If you discover a vulnerability, please report it through the following channels:

Preferred: GitHub Security Advisory

The most secure and efficient way to report a vulnerability is through the GitHub Security Advisory system at: https://github.com/yeongseon/azure-functions-doctor/security/advisories/new

Alternative: Email

You can also report security concerns via email to: yeongseon.choe@gmail.com

What to Include

When reporting a vulnerability, please include: - A clear description of the vulnerability and its potential impact. - Detailed reproduction steps, including any sample code or configuration files. - An assessment of the impact on users or environments. - A suggested fix or mitigation, if you have one.

Response Timeline

  • Initial acknowledgment: Within 48 hours.
  • Status updates and triage: Within 7 days.
  • Full resolution: We aim to provide a fix or public disclosure within a reasonable timeframe, depending on the severity and complexity of the issue.

Responsible Disclosure

We ask that you follow responsible disclosure practices. Please do not share information about the vulnerability publicly until we have had a chance to address it and notify affected users.

Supported Versions

Version Supported
Latest release Yes
Older releases No

Security fixes are only applied to the most recent stable release. Users are encouraged to stay updated with the latest version.

Security Scanning

To ensure the integrity of our codebase, we employ several automated security scanning tools:

  • Bandit (1.9.4): A static analysis security scanner that identifies common security issues in Python code.
  • Scope: Scans all files in the src/ directory while excluding the tests/ directory to focus on production code.
  • Local Execution: You can run the security scan locally using make security or hatch run security.
  • CI Integration: The security.yml workflow runs Bandit on every push and pull request to the main repository.
  • Pre-commit: Bandit is integrated as a pre-commit hook, ensuring that potential issues are caught before code is committed.

Security Scope

Within Scope

  • Diagnostic Rule Integrity: Rules must not execute arbitrary code. The core logic of the doctor is designed to evaluate state, not provide a platform for execution.
  • Custom Rules Trust Boundary: When a user specifies a custom rules.json path, that file is treated as a trusted input.
  • Network Requests: The tool makes outbound HTTP requests exclusively to check for updates to Azure Functions Core Tools using the requests library.
  • Input Validation: Path arguments and user-provided inputs are validated to prevent common vulnerabilities like path traversal.
  • Dependency Security: We monitor our five runtime dependencies (jsonschema, packaging, requests, rich, typer) for known vulnerabilities.

Out of Scope

  • Diagnosed Project Security: The security posture of the Azure Functions projects being analyzed is the responsibility of the project owner.
  • Azure Functions Runtime Security: Issues related to the Azure Functions runtime or platform are managed by Microsoft.
  • Build-time Security: Security during the build or deployment phase of the projects being checked is outside the scope of this tool.

Network Behavior

  • Update Checks: The doctor makes outbound HTTP requests to official registries to compare local Azure Functions Core Tools versions with the latest available releases.
  • Privacy: No telemetry, analytics, or user data is collected or sent to any remote servers.
  • Resilience: Network requests are designed to fail gracefully. If a connection cannot be established, the corresponding check will show a "skip" status rather than crashing the tool.

Custom Rules Trust Model

  • Assumption of Trust: Custom rules.json files provided via the --rules flag are assumed to be from a trusted source.
  • User Responsibility: Users should only load custom rules from sources they trust.
  • Execution Limits: Custom rules define metadata for checks and cannot execute arbitrary scripts or binary code.
  • Handler Types: Rule execution is limited to a pre-defined set of built-in handlers (such as file_exists, path_exists, etc.), which provides a controlled environment for diagnostic logic.

Security Best Practices for Users

  • Update Frequently: Keep your installation of azure-functions-doctor updated to benefit from the latest security patches and rule improvements.
  • Review Custom Rules: Always review the contents of a custom rules file before using it with the doctor.
  • Automation: Use the --format json output for integration into automated CI/CD pipelines for consistent security and environment checks.
  • GitHub Integration: Use the SARIF output format to integrate results directly with GitHub Code Scanning.

Dependency Security

The project relies on a minimal set of five runtime dependencies: - jsonschema: For validating rule files and configurations. - packaging: For handling version comparisons. - requests: For secure outbound HTTP communication. - rich: For formatted terminal output. - typer: For building the command-line interface.

We use Dependabot to monitor these dependencies and provide automated updates for security vulnerabilities and version upgrades. All chosen dependencies are widely-used and actively maintained packages.