Security Vulnerability

PyPackIT takes the security and privacy of all its users and members very seriously, and is committed to ensuring the safety of its products and services. In case a security vulnerability is detected that may affect users, we take immediate action to:

1. fix the issue as soon as possible,

2. release a new security patch in case a published application was affected,

3. release a security advisory, detailing the vulnerability, as well as guidelines for end-users to protect themselves. Security advisories are accessible on our website and repository, as well as via a feed.

PyPackIT Security Measures 🛡

Learn more about our security measures and procedures to handle vulnerability issues on our maintenance guide(…/collaborate/maintenance/index).

Vulnerability Disclosure Policy

This policy is intended to give users, contributors, and security researchers clear guidelines for reporting potential security vulnerabilities and conducting vulnerability discovery activities. It describes what systems and types of research are covered under this policy, how to send us vulnerability reports, what information to include, and how long we ask security researchers to wait before publicly disclosing vulnerabilities.

🛡️**Supported Versions**

Questions regarding this policy may be sent to security@agency.gov. We also invite you to contact us with suggestions for improving this policy.

Reporting a Potential Vulnerability

If you have found a potential vulnerability in our application, website, or repository, please report it as soon as possible, following the guidelines described here. Please DO NOT

Where to Report

We use GitHub’s security advisories feature of our repository to securely discuss, fix and publish information about security vulnerabilities in PyPackIT. To privately report a security vulnerability, follow the documentation on Github or click here to directly open a private report form.

Other ways to open a security advisory:

On the Issues tab

On the Security tab

PyPackIT Security Measures 🛡

ergergg

Email Body

—Thank you for reporting a security vulnerability. Please provide as much information as you can under the sections listed below. Texts like this that are surrounded by three hyphens are instructions and should be deleted before sending the email.—

1. Summary —Provide a short summary of the problem. Make the impact and severity as clear as possible. For example: An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the server.—

2. Details —Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.—

3. PoC —Complete instructions, including specific configuration details, to reproduce the vulnerability.—

4. Impact —What kind of vulnerability is it? Who is impacted?—

5. Affected Products —For each affected product, name the ecosystem (e.g. pip, GitHub Actions), package- or filename, and affected versions.—

6. Severity —Asses the severity of the issue, e.g. using a CVSS vector string (learn more at https://www.first.org/cvss/v3.1/user-guide).—

7. Weaknesses —Provide Common Weakness Enumerator (CWE; learn more at https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/about-repository-security-advisories#cve-identification-numbers).—

8. Mitigation —Provide necessary steps to mitigate the problem.—

🥷🏾 Prefer Anonymity?

Our vulnerability management team also welcomes anonymous emails sent to {email_security}.

Information to Include

In order to help us assess and triage submissions, please provide as much information as you can, under following sections:

1. Title: A concise title describing the vulnerability.

2. Summary: A short summary of the problem. Make the impact and severity as clear as possible. For example: An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the server.

3. Details: Details on the vulnerability, including the location the vulnerability was discovered. Pointing to the incriminated source code is very helpful for the maintainer.

4. PoC: Complete instructions, including specific configuration details, to reproduce the vulnerability. Proof of concept scripts or screenshots can be helpful to include.

5. Impact: The type of vulnerability in terms of potential impact of exploitation and affected users.

6. Affected Products: Name of the ecosystem (e.g. pip, GitHub Actions), package- or filename, and affected versions, for each affected product.

7. Severity: Assessment of the severity of the issue, using the Common Vulnerability Scoring System (CVSS).

8. Weaknesses: A Common Weakness Enumerator (CWE), if available.

9. Mitigation: If known, necessary steps to mitigate the problem.

For more information, also refer to GitHub documentations on creating a repository security advisory and best practices for writing repository security advisories.

Response Policy

When you choose to share your contact information with us, we commit to coordinating with you as openly and as quickly as possible:

• Within a week, our vulnerability management team will acknowledge receiving your report.

• To the best of our ability, we will confirm the existence of the vulnerability to you and be as transparent as possible about what steps we are taking during the remediation process, including on issues or challenges that may delay resolution.

• We will maintain an open dialogue to discuss issues.

Disclosure Policy

This project follows a 120-day disclosure timeline; if you are a security researcher and would like to disclose the vulnerability you detected, we request that you allow us at least 120 days prior to any public exposure. This helps the project contributors to resolve the vulnerability and issue a new release, and provides our users a chance to update their applications and protect themselves.

Testing for Vulnerabilities

PyPackIT is a free and open-source project. We encourage security researchers to help us improve our security measures by conducting vulnerability discovery activities on our application, website, and repository. Before starting, please read the guidelines below, describing what systems and types of research are covered under this policy.

Authorization

If you make a good faith effort to comply with this policy during your security research, we will consider your research to be authorized, will work with you to understand and resolve the issue quickly, and will not recommend or pursue legal action related to your research. Should legal action be initiated by a third party against you for activities that were conducted in accordance with this policy, we will make this authorization known.

Guidelines

Under this policy, “research” and “vulnerability discovery” means activities in which you:

• notify us as soon as possible after you discover a real or potential security issue,

• make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data,

• only use exploits to the extent necessary to confirm a vulnerability’s presence,

• do not use an exploit to compromise or exfiltrate data, establish persistent command line access, or use the exploit to pivot to other systems,

• provide us a reasonable amount of time to resolve the issue before you disclose it publicly,

• do not submit a high volume of low-quality reports.

Once you’ve established that a vulnerability exists or encounter any sensitive data (including personally identifiable information, financial information, or proprietary information or secrets of any kind), you must:

• stop your test,

• notify us immediately,

• and not disclose this data to anyone else.

Test Methods

The following test methods are not authorized:

• Network denial of service (DoS or DDoS) tests or other tests that impair access to or damage a system or data.

• Social engineering (e.g. phishing) or any other non-technical vulnerability testing.

Scope

This policy applies to any source code, data, or configuration directly stored in our GitHub repository at RepoDynamics/PyPackIT, and any software, package, website, or other digital products and services that are directly published/deployed from this repository.

Any service not expressly listed above, such as any connected services, are excluded from scope and are not authorized for testing. Additionally, vulnerabilities found in systems from our vendors fall outside of this policy’s scope and should be reported directly to the vendor according to their disclosure policy (if any). If you aren’t sure whether a system is in scope or not, or there is a particular system not in scope that you think merits testing, please contact us at armiariam@gmail.com to discuss it first, before starting your research.