|
| 1 | +Vulnerabilities |
| 2 | +=============== |
| 3 | + |
| 4 | +.. contents:: |
| 5 | + |
| 6 | +Vulnerabilities refer to potential security flaws or weaknesses in PyAnsys packages. |
| 7 | +Here are some examples of common vulnerabilities: |
| 8 | + |
| 9 | +- Insufficient input validation or insecure handling of file paths leading to unauthorized access |
| 10 | +- Insecure code and command injection into the app |
| 11 | +- Remote code execution due to deserialization of untrusted code |
| 12 | +- Disclosure of sensitive information due to weak exception handling |
| 13 | + |
| 14 | +Vulnerability sources |
| 15 | +--------------------- |
| 16 | + |
| 17 | +- **Vulnerabilities from PyAnsys library code**: Maintainers are responsible for deciding whether to |
| 18 | + address vulnerabilities. The priority of vulnerabilities can be escalated internally if they represent |
| 19 | + a roadblock for usage. The Ansys business unit in charge of the project should handle |
| 20 | + vulnerabilities on a case-by-case basis. |
| 21 | + |
| 22 | +- **Vulnerabilities from external package dependencies**: When vulnerabilities exist in external packages |
| 23 | + used by PyAnsys libraries, such as NumPy or Matplotlib, Ansys should not address these vulnerabilities |
| 24 | + directly. Instead, raise an issue on the open source repository, pointing out the |
| 25 | + vulnerability and linking the applicable `CVE`_. At most, be mindful of deprecated packages and functions |
| 26 | + because they may not receive security patches and might introduce vulnerabilities into your codebase. |
| 27 | + |
| 28 | +Vulnerability discovery and tracking |
| 29 | +------------------------------------- |
| 30 | + |
| 31 | +Leverage available security tools like dependency scanners or static |
| 32 | +analyzers (such as PyUp, Safety, or Bandit) to automatically detect and |
| 33 | +remediate security vulnerabilities in Python packages and dependencies. |
| 34 | + |
| 35 | +The PyAnsys ecosystem has implemented automated mechanisms to track and |
| 36 | +report vulnerabilities in the codebase. These tools are intended to be integrated |
| 37 | +into the CI/CD workflow of the repositories. |
| 38 | + |
| 39 | +The PyAnsys Core team has come up with a GitHub Action that can be used to |
| 40 | +automatically check for vulnerabilities in the codebase. This action is based on |
| 41 | +the following tools: |
| 42 | + |
| 43 | +- `Safety`_ : Checks installed dependencies for known security vulnerabilities. |
| 44 | +- `Bandit`_: Attempts to find common security issues in Python code. |
| 45 | + |
| 46 | +Safety addresses external dependencies, while Bandit focuses on the codebase itself. |
| 47 | +Both tools have been integrated into the ``ansys/actions/check-vulnerabilities`` action. |
| 48 | + |
| 49 | +.. note:: |
| 50 | + |
| 51 | + The tools selected for the action are not definitive. The action can be modified to include |
| 52 | + other tools or to use different versions of the tools in the future. |
| 53 | + |
| 54 | +For third-party packages, the PyAnsys Core team has listed a set of excluded advisories so |
| 55 | +that the action does not fail. This is done to avoid false positives and to ensure that the action |
| 56 | +does not block the CI/CD pipeline unnecessarily. You can find the list of excluded advisories |
| 57 | +in `the action's documentation`_. |
| 58 | + |
| 59 | +For potential vulnerabilities in the codebase, repositories can configure Bandit to ignore specific |
| 60 | +advisories. This can be due to the code not being ready yet to be fixed or that the advisory is not relevant |
| 61 | +to the codebase. However, it is important to note that ignoring advisories should be done with caution, |
| 62 | +and developers should be aware of the potential risks involved. Furthermore, repository maintainers should |
| 63 | +document the reasons for ignoring advisories and ensure that they are regularly reviewed to determine if they |
| 64 | +can be addressed. |
| 65 | + |
| 66 | +.. note:: |
| 67 | + |
| 68 | + An example on how to document the ignored advisories can be found in the `PyACP security considerations`_ |
| 69 | + documentation page. This should be taken as a reference for documenting ignored advisories in other repositories. |
| 70 | + |
| 71 | +.. warning:: |
| 72 | + |
| 73 | + Testing the action locally before enabling it in the CI/CD workflow is recommended. Information on how |
| 74 | + to do this can be found in `the action's documentation`_. |
| 75 | + |
| 76 | +Vulnerability remediation and reporting |
| 77 | +---------------------------------------- |
| 78 | + |
| 79 | +When a vulnerability is detected, the action fails and reports the vulnerabilities found in the codebase. |
| 80 | +Following that, these vulnerabilities are reported as draft security advisories in the repository's |
| 81 | +**Security** tab. Maintainers are then responsible for reviewing the advisories and deciding whether to address |
| 82 | +them or not. These advisories are monitored by the PyAnsys Core team and are escalated internally if they |
| 83 | +represent a roadblock for usage. |
| 84 | + |
| 85 | +Repositories should also have a process in place to handle vulnerabilities that are reported by users or |
| 86 | +other developers. For that purpose, a ``SECURITY.md`` file should be created in the root of the repository. |
| 87 | +This file should contain information on how to report vulnerabilities and the process for handling them. |
| 88 | + |
| 89 | +Here is an example of a ``SECURITY.md`` file: |
| 90 | + |
| 91 | +.. code-block:: markdown |
| 92 | +
|
| 93 | + ## Reporting a vulnerability |
| 94 | +
|
| 95 | + > [!CAUTION] |
| 96 | + > Do not use GitHub issues to report any security vulnerabilities. |
| 97 | +
|
| 98 | + If you detect a vulnerability, contact the [PyAnsys Core team](mailto:[email protected]), |
| 99 | + mentioning the repository and the details of your finding. The team will address it as soon as possible. |
| 100 | +
|
| 101 | + Provide the PyAnsys Core team with this information: |
| 102 | +
|
| 103 | + - Any specific configuration settings needed to reproduce the problem |
| 104 | + - Step-by-step guidance to reproduce the problem |
| 105 | + - The exact location of the problematic source code, including tag, branch, commit, or a direct URL |
| 106 | + - The potential consequences of the vulnerability, along with a description of how an attacker could take advantage of the issue |
| 107 | +
|
| 108 | +Vulnerability disclosure |
| 109 | +------------------------ |
| 110 | + |
| 111 | +When a vulnerability is detected and a decision is made to address it, the repository maintainers should |
| 112 | +create a private fork of the repository and create a pull request with the fix. Information on |
| 113 | +how to create such a temporary fork to resolve a vulnerability can be found in `Github's documentation`_. |
| 114 | +When opened, the pull request should be reviewed in depth and include tests to ensure that the |
| 115 | +vulnerability is fixed. Once the pull request is merged, the repository maintainers should create a new |
| 116 | +release with the fix and update the changelog accordingly. |
| 117 | + |
| 118 | +The release should be tagged with a new version number where the patch value has been incremented, |
| 119 | +and the changelog should include a note about the vulnerability and the fix. The note should include |
| 120 | +this information: |
| 121 | + |
| 122 | +- The CVE number of the vulnerability (if applicable) |
| 123 | +- A description of the vulnerability and its potential consequences |
| 124 | +- A description of the fix and how it addresses the vulnerability |
| 125 | +- A link to the pull request that fixed the vulnerability |
| 126 | + |
| 127 | +Additionally, the security advisory should be published on the repository's **Security** tab. |
| 128 | +This advisory should include the same information as the changelog note, in other words the |
| 129 | +CVE number, the date of the advisory, and the status of the advisory (such as published or withdrawn). |
| 130 | + |
| 131 | +A reference of a published security advisory can be found here: `PyAnsys Geometry subprocess advisory`_. |
| 132 | +This advisory was published in the PyAnsys Geometry repository and includes information about a vulnerability |
| 133 | +in which users could execute arbitrary code on the system by using one of this library's functions. |
| 134 | + |
| 135 | +Ensuring compliance across the PyAnsys ecosystem |
| 136 | +------------------------------------------------ |
| 137 | + |
| 138 | +The PyAnsys Core team is responsible for ensuring that the ``ansys/actions/check-vulnerabilities`` action is up to date and that it is |
| 139 | +being used in all PyAnsys repositories considered as libraries (that is, Python packages shipped to PyPI). |
| 140 | +Repository maintainers are responsible for ensuring that the action is implemented correctly and that the |
| 141 | +results are reviewed regularly. |
0 commit comments