mirror of
https://github.com/docling-project/docling.git
synced 2026-05-17 13:10:38 +00:00
geoHeilandGitHub
5b1df788ef
* ci: tighten pre-commit guardrails Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> * ci: validate pre-commit guardrail changes Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> * ci: switch hook validation to prek Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> * ci: exempt active slim plan from max-lines Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> * ci: move max-lines config under github Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> * ci: fail on uncovered tach modules Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> * ci: ignore generated docs in max-lines check Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> * ci: clarify local validation tasks Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> * docs: refine agent instructions Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> * ci: replace mypy with ty (cherry picked from commit 382afbde8f00abfaeba95ea9c8e9cc603f27a2d9) Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> * ci: replace justfile with makefile Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com> --------- Signed-off-by: Georg Heiler <georg.kf.heiler@gmail.com>
60 lines
3.6 KiB
Markdown
60 lines
3.6 KiB
Markdown
# Security and Disclosure Information Policy for the Docling Project
|
|
|
|
The Docling team and community take security bugs seriously. We appreciate your efforts to responsibly disclose your findings, and will make every effort to acknowledge your contributions.
|
|
|
|
## Supported Versions
|
|
|
|
The latest versions of Docling are supported.
|
|
|
|
### Security
|
|
|
|
- Participation in the [OpenSSF Best Practices Badge Program](https://bestpractices.coreinfrastructure.org/en/projects/10101) for Free/Libre and FLOSS projects to ensure that we follow current best practices for quality and security
|
|
- Use of [HTTPS](https://en.wikipedia.org/wiki/HTTPS) for network communication
|
|
- Use of secure protocols for network communication (through the use of HTTPS)
|
|
- Up-to-date support for TLS/SSL (through the use of [OpenSSL](https://www.openssl.org/))
|
|
- Performance of TLS certificate verification by default before sending HTTP headers with private information (through the use of OpenSSL and HTTPS)
|
|
- Distribution of the software via cryptographically signed releases (on the [PyPI](https://pypi.org/), [Quay.io](https://quay.io/organization/docling-project/) and [GHCR.io](https://github.com/orgs/docling-project/packages) package repositories)
|
|
- Use of [GitHub](https://github.com/) Issues for vulnerability reporting and tracking
|
|
|
|
### Analysis
|
|
|
|
- Use of [Ruff](https://docs.astral.sh/ruff/), [ty](https://docs.astral.sh/ty/) and [Pytest](https://docs.pytest.org/en/7.2.x/) for Python code linting (static and dynamic analysers) on pull requests and builds
|
|
- Use of GitHub Issues for bug reporting and tracking
|
|
|
|
## Reporting a Vulnerability
|
|
|
|
If you think you've identified a security issue in a Docling project repository, please DO NOT report the issue publicly via the GitHub issue tracker, discussions, or any other public forum.
|
|
|
|
### Preferred Method: GitHub Private Vulnerability Reporting
|
|
|
|
**We strongly encourage you to use GitHub's Private Vulnerability Reporting feature**, which provides a secure and streamlined process for disclosing security issues:
|
|
|
|
1. Navigate to the [Security tab](https://github.com/docling-project/docling/security) of the Docling repository
|
|
2. Click on "Report a vulnerability"
|
|
3. Fill out the vulnerability report form with as many details as possible
|
|
4. Submit the report
|
|
|
|
This method allows for:
|
|
- **Secure communication** directly with the maintainers team
|
|
- **Coordinated disclosure** through GitHub's built-in workflow
|
|
- **Automatic tracking** of the vulnerability lifecycle
|
|
- **Credit attribution** when the vulnerability is published
|
|
|
|
### Alternative Method: Email Disclosure
|
|
|
|
Alternatively, you can send an email with as many details as possible to [deepsearch-core@zurich.ibm.com](mailto:deepsearch-core@zurich.ibm.com). This is a private mailing list for the maintainers team.
|
|
|
|
**Important:** Please do not create a public issue or discuss the vulnerability in any public channel until it has been addressed.
|
|
|
|
### Security Vulnerability Response
|
|
|
|
Each report is acknowledged and analyzed by the core maintainers within 3 working days.
|
|
|
|
Any vulnerability information shared with core maintainers stays within the Docling project and will not be disseminated to other projects unless it is necessary to get the issue fixed.
|
|
|
|
After the initial reply to your report, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance.
|
|
|
|
## Security Alerts
|
|
|
|
We will send announcements of security vulnerabilities and steps to remediate on the [Docling announcements](https://github.com/docling-project/docling/discussions/categories/announcements).
|