You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Slack takes the security of its software and services seriously, including all open-source repositories managed through the [slackapi](https://github.com/slackapi) GitHub organization.
4
+
5
+
## Reporting a Vulnerability
6
+
7
+
**Do NOT report security vulnerabilities through public GitHub issues, pull requests, or discussions.**
8
+
9
+
If you believe you have found a security vulnerability in `slack-bolt`, please report it through the Slack bug bounty program on HackerOne:
10
+
11
+
**<https://hackerone.com/slack>**
12
+
13
+
Even if `slack-bolt` is not explicitly listed as an in-scope asset on the HackerOne program page, reports for vulnerabilities in this package should still be submitted there. The Slack security team triages reports for all `slackapi` open-source repositories through this program.
14
+
15
+
If HackerOne is inaccessible, you may alternatively report the issue to [security@salesforce.com](mailto:security@salesforce.com).
16
+
17
+
Please do not discuss potential vulnerabilities in public without first coordinating with the security team.
18
+
19
+
## What to Include
20
+
21
+
To help us triage and respond quickly, please include:
22
+
23
+
- Type of vulnerability (e.g., signature bypass, token leakage, denial of service)
24
+
- Affected version(s) of `slack-bolt`
25
+
- Step-by-step reproduction instructions
26
+
- Proof-of-concept code or payloads, if available
27
+
- Impact assessment: what an attacker could achieve
28
+
- Any specific configuration required to trigger the vulnerability
29
+
- Affected source file paths, if known
30
+
31
+
## Threat Model
32
+
33
+
Bolt for Python is a framework that sits between the Slack platform and developer application code. Its security boundary covers the integrity and confidentiality of that interface.
34
+
35
+
### In Scope
36
+
37
+
The following are considered framework vulnerabilities:
38
+
39
+
- Bypass of request signature verification (HMAC-SHA256 validation)
40
+
- OAuth token leakage or cross-tenant token exposure during authorization flows
41
+
- Denial of service caused by malformed or specially crafted payloads processed by framework internals
42
+
- Authentication or authorization bypass in any built-in adapter
43
+
- Information disclosure through framework error responses or timing side channels
44
+
- Bypass of the `ssl_check` endpoint protections
45
+
46
+
### Out of Scope
47
+
48
+
The following are NOT framework vulnerabilities:
49
+
50
+
- Vulnerabilities in the Python runtime, operating system, or hosting infrastructure
51
+
- Security issues in developer application logic built on top of Bolt (e.g., SQL injection caused by passing unsanitized payload data to a database)
52
+
- Vulnerabilities in third-party PyPI packages chosen and installed by the developer outside of Bolt's direct dependencies
53
+
- Vulnerabilities in Slack's server-side platform infrastructure (report those directly under Slack's main HackerOne scope)
54
+
- Attacks that require possession of a valid signing secret or bot token
55
+
- Arbitrary attribute injection or unsafe deserialization caused by developer code handling untrusted input
56
+
- Issues that only affect end-of-life versions with no reproduction on supported versions
57
+
58
+
## Disclosure Policy
59
+
60
+
This project follows coordinated disclosure:
61
+
62
+
- Allow a reasonable timeframe for the team to investigate, develop, and release a fix before any public disclosure.
63
+
- Researchers who follow responsible disclosure practices are eligible for recognition and bounty consideration through the Slack HackerOne program.
-`adapter_dev.txt` -- all framework adapter deps (Flask, Django, FastAPI, etc.)
210
+
-`test_async.txt` -- test runner deps (`pytest`, `pytest-asyncio`, includes `async_dev.txt`)
211
+
-`test.txt` -- test deps without async (`pytest`, `pytest-cov`)
212
+
-`test_adapter.txt` -- adapter-specific test deps (`moto`, `boddle`, `sanic-testing`)
213
+
-`dev_tools.txt` -- dev tools (`mypy`, `flake8`, `black`)
214
214
215
215
When adding a new dependency: add it to the appropriate `requirements/*.txt` file with version constraints, never to `pyproject.toml``dependencies` (unless it's a core runtime dep, which is very rare).
0 commit comments