Basic API functions usage

Basic API functions usage#

Using the Python Code Audit APIs is simple and straightforward!

If you have any questions, feel free to get in touch!

To use the Python Code Audit functions, simply import the desired function into your notebook or Python script.

To use the Python Code Audit functions import the function you want to use in a notebook or in a Python file.

Platform information#

The platform_info() function provides detailed information about the runtime environment.

This information is essential for both security purposes and handling edge cases that may affect the behavior of the APIs.

from codeaudit.api_interfaces import platform_info

platform_info()

{'python_version': '3.14.6', 'python_implementation': 'CPython'}

Python Code Audit version information#

Good security validation starts with knowing which tools — and which versions — you have used.

When you build your own APIs using this framework, all critical scanning API calls automatically include a version identifier.

However, if you need to retrieve the version information using a script (for example, when creating CI/CD scripts), you can easily do so using the following command:

from codeaudit.api_interfaces import version

version()

{'name': 'Python_Code_Audit', 'version': '1.8.1'}

Security Assessment of Module Vulnerabilities#

This API retrieves security vulnerability data for external modules via the OSV (Open Source Vulnerability) Database.

How it Works

Input: Provide the name of the module you wish to query.
External Call: This function triggers an external request. Please note that the OSV Database is not designed for high-frequency, continuous polling. Use this API judiciously to avoid rate-limiting or performance issues.
Output: The API returns a Python dictionary containing comprehensive vulnerability details. This structured data allows you to build custom reporting and monitoring tools tailored to your needs.

Best Practices Validating external modules for known vulnerabilities should be a standard security requirement, not an optional step. Because security risk depends on how a module is implemented, you must evaluate the returned data to determine if a module meets the security standards for your specific use case.

Attention

Checking against known vulnerabilities is not as strong as doing a SAST scan on code.

So always use Python Code Audit and check on (new)weaknesses!!

Too many tools only check Python programs and their dependencies (or used modules) against known vulnerabilities.

Many security tools focus exclusively on auditing Python programs and their direct dependencies against lists of known vulnerabilities. These vulnerabilities are typically tracked and published in global repositories:

NVD & CVE: Security flaws are officially identified and catalogued using the Common Vulnerabilities and Exposures (CVE) system. These are central to the U.S. National Vulnerability Database (NVD).
OSV Database: In addition to the NVD, many Open Source Software (OSS) vulnerabilities are aggregated in the Google-managed OSV (Open Source Vulnerability) database, which provides a more distributed and developer-friendly format for many ecosystems.

How to use this API call#

from codeaudit.api_interfaces import get_module_vulnerability_info

vulnerability_info = get_module_vulnerability_info("pandas")  #now the vulnerabilty information , if available, is retrieved 

vulnerability_info  #shows retrieved vulnerability information for external modules.

{'name': 'Python_Code_Audit',
 'version': '1.8.1',
 'generated_on': '2026-07-31 13:23',
 'pandas_vulnerability_info': [{'id': 'PYSEC-2020-73',
   'summary': '',
   'details': "** DISPUTED ** pandas through 1.0.3 can unserialize and execute commands from an untrusted file that is passed to the read_pickle() function, if __reduce__ makes an os.system call. NOTE: third parties dispute this issue because the read_pickle() function is documented as unsafe and it is the user's responsibility to use the function in a secure manner.",
   'aliases': ['CVE-2020-13091'],
   'severity': []}]}

Known vulnerabilities of the Python module: `requests`#

An example for the output of known vulnerabilities of a well known Python module: requests

If you see this output ask the question if you really should use this module!

vulnerability_info = get_module_vulnerability_info("requests")  #now the vulnerabilty information , if available, is retrieved 

vulnerability_info

{'name': 'Python_Code_Audit',
 'version': '1.8.1',
 'generated_on': '2026-07-31 13:23',
 'requests_vulnerability_info': [{'id': 'GHSA-652x-xj99-gmcc',
   'summary': 'Exposure of Sensitive Information to an Unauthorized Actor in Requests',
   'details': 'Requests (aka python-requests) before 2.3.0 allows remote servers to obtain sensitive information by reading the Proxy-Authorization header in a redirected request.',
   'aliases': ['CVE-2014-1830', 'PYSEC-2014-14'],
   'severity': [{'type': 'CVSS_V4',
     'score': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N'}]},
  {'id': 'GHSA-9hjg-9r4m-mvj7',
   'summary': 'Requests vulnerable to .netrc credentials leak via malicious URLs',
   'details': '### Impact\n\nDue to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs.\n\n### Workarounds\nFor older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on your Requests Session ([docs](https://requests.readthedocs.io/en/latest/api/#requests.Session.trust_env)).\n\n### References\nhttps://github.com/psf/requests/pull/6965\nhttps://seclists.org/fulldisclosure/2025/Jun/2',
   'aliases': ['CVE-2024-47081', 'PYSEC-2026-1872'],
   'severity': [{'type': 'CVSS_V3',
     'score': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N'}]},
  {'id': 'GHSA-9wx4-h78v-vm56',
   'summary': 'Requests `Session` object does not verify requests after making first request with verify=False',
   'details': "When using a `requests.Session`, if the first request to a given origin is made with `verify=False`, TLS certificate verification may remain disabled for all subsequent requests to that origin, even if `verify=True` is explicitly specified later.\n\nThis occurs because the underlying connection is reused from the session's connection pool, causing the initial TLS verification setting to persist for the lifetime of the pooled connection. As a result, applications may unintentionally send requests without certificate verification, leading to potential man-in-the-middle attacks and compromised confidentiality or integrity.\n\nThis behavior affects versions of `requests` prior to 2.32.0.",
   'aliases': ['CVE-2024-35195', 'PYSEC-2026-1873'],
   'severity': [{'type': 'CVSS_V3',
     'score': 'CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N'}]},
  {'id': 'GHSA-cfj3-7x9c-4p3h',
   'summary': 'Exposure of Sensitive Information to an Unauthorized Actor in Requests',
   'details': 'Requests (aka python-requests) before 2.3.0 allows remote servers to obtain a netrc password by reading the Authorization header in a redirected request.',
   'aliases': ['CVE-2014-1829', 'PYSEC-2014-13'],
   'severity': [{'type': 'CVSS_V3',
     'score': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N'},
    {'type': 'CVSS_V4',
     'score': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N'}]},
  {'id': 'GHSA-gc5v-m9x4-r6x2',
   'summary': 'Requests has Insecure Temp File Reuse in its extract_zipped_paths() utility function',
   'details': '### Impact\nThe `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one.\n\n### Affected usages\n**Standard usage of the Requests library is not affected by this vulnerability.** Only applications that call `extract_zipped_paths()` directly are impacted.\n\n### Remediation\nUpgrade to at least Requests 2.33.0, where the library now extracts files to a non-deterministic location.\n\nIf developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.',
   'aliases': ['CVE-2026-25645', 'PYSEC-2026-2275'],
   'severity': [{'type': 'CVSS_V3',
     'score': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N'}]},
  {'id': 'GHSA-j8r2-6x86-q33q',
   'summary': 'Unintended leak of Proxy-Authorization header in requests',
   'details': "### Impact\n\nSince Requests v2.3.0, Requests has been vulnerable to potentially leaking `Proxy-Authorization` headers to destination servers, specifically during redirects to an HTTPS origin. This is a product of how `rebuild_proxies` is used to recompute and [reattach the `Proxy-Authorization` header](https://github.com/psf/requests/blob/f2629e9e3c7ce3c3c8c025bcd8db551101cbc773/requests/sessions.py#L319-L328) to requests when redirected. Note this behavior has _only_ been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. `https://username:password@proxy:8080`).\n\n**Current vulnerable behavior(s):**\n\n1. HTTP → HTTPS: **leak**\n2. HTTPS → HTTP: **no leak**\n3. HTTPS → HTTPS: **leak**\n4. HTTP → HTTP: **no leak**\n\nFor HTTP connections sent through the proxy, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the `Proxy-Authorization` header must be sent in the CONNECT request as the proxy has no visibility into further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials.\n\nThe reason this currently works for HTTPS connections in Requests is the `Proxy-Authorization` header is also handled by urllib3 with our usage of the ProxyManager in adapters.py with [`proxy_manager_for`](https://github.com/psf/requests/blob/f2629e9e3c7ce3c3c8c025bcd8db551101cbc773/requests/adapters.py#L199-L235). This will compute the required proxy headers in `proxy_headers` and pass them to the Proxy Manager, avoiding attaching them directly to the Request object. This will be our preferred option going forward for default usage.\n\n### Patches\nStarting in Requests v2.31.0, Requests will no longer attach this header to redirects with an HTTPS destination. This should have no negative impacts on the default behavior of the library as the proxy credentials are already properly being handled by urllib3's ProxyManager.\n\nFor users with custom adapters, this _may_ be potentially breaking if you were already working around this behavior. The previous functionality of `rebuild_proxies` doesn't make sense in any case, so we would encourage any users impacted to migrate any handling of Proxy-Authorization directly into their custom adapter.\n\n### Workarounds\nFor users who are not able to update Requests immediately, there is one potential workaround.\n\nYou may disable redirects by setting `allow_redirects` to `False` on all calls through Requests top-level APIs. Note that if you're currently relying on redirect behaviors, you will need to capture the 3xx response codes and ensure a new request is made to the redirect destination.\n```\nimport requests\nr = requests.get('http://github.com/', allow_redirects=False)\n```\n\n### Credits\n\nThis vulnerability was discovered and disclosed by the following individuals.\n\nDennis Brinkrolf, Haxolot (https://haxolot.com/)\nTobias Funke, (tobiasfunke93@gmail.com)",
   'aliases': ['CVE-2023-32681', 'PYSEC-2023-74'],
   'severity': [{'type': 'CVSS_V3',
     'score': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N'}]},
  {'id': 'GHSA-pg2w-x9wp-vw92',
   'summary': 'Python Requests Session Fixation',
   'details': 'The `resolve_redirects` function in sessions.py in requests 2.1.0 through 2.5.3 allows remote attackers to conduct session fixation attacks via a cookie without a host value in a redirect.',
   'aliases': ['CVE-2015-2296', 'PYSEC-2015-17'],
   'severity': []},
  {'id': 'GHSA-x84v-xcm2-53pg',
   'summary': 'Insufficiently Protected Credentials in Requests',
   'details': 'The Requests package through 2.19.1 before 2018-09-14 for Python sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.',
   'aliases': ['CVE-2018-18074', 'PYSEC-2018-28'],
   'severity': [{'type': 'CVSS_V3',
     'score': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N'}]},
  {'id': 'PYSEC-2014-13',
   'summary': '',
   'details': 'Requests (aka python-requests) before 2.3.0 allows remote servers to obtain a netrc password by reading the Authorization header in a redirected request.',
   'aliases': ['CVE-2014-1829', 'GHSA-cfj3-7x9c-4p3h'],
   'severity': []},
  {'id': 'PYSEC-2014-14',
   'summary': '',
   'details': 'Requests (aka python-requests) before 2.3.0 allows remote servers to obtain sensitive information by reading the Proxy-Authorization header in a redirected request.',
   'aliases': ['CVE-2014-1830', 'GHSA-652x-xj99-gmcc'],
   'severity': []},
  {'id': 'PYSEC-2015-17',
   'summary': '',
   'details': 'The resolve_redirects function in sessions.py in requests 2.1.0 through 2.5.3 allows remote attackers to conduct session fixation attacks via a cookie without a host value in a redirect.',
   'aliases': ['CVE-2015-2296', 'GHSA-pg2w-x9wp-vw92'],
   'severity': []},
  {'id': 'PYSEC-2018-28',
   'summary': '',
   'details': 'The Requests package before 2.20.0 for Python sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.',
   'aliases': ['CVE-2018-18074', 'GHSA-x84v-xcm2-53pg'],
   'severity': []},
  {'id': 'PYSEC-2023-74',
   'summary': '',
   'details': 'Requests is a HTTP library. Since Requests 2.3.0, Requests has been leaking Proxy-Authorization headers to destination servers when redirected to an HTTPS endpoint. This is a product of how we use `rebuild_proxies` to reattach the `Proxy-Authorization` header to requests. For HTTP connections sent through the tunnel, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the `Proxy-Authorization` header must be sent in the CONNECT request as the proxy has no visibility into the tunneled request. This results in Requests forwarding proxy credentials to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate sensitive information. This issue has been patched in version 2.31.0.\n\n',
   'aliases': ['CVE-2023-32681', 'GHSA-j8r2-6x86-q33q'],
   'severity': []},
  {'id': 'PYSEC-2026-1872',
   'summary': 'Requests vulnerable to .netrc credentials leak via malicious URLs',
   'details': '### Impact\n\nDue to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs.\n\n### Workarounds\nFor older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on your Requests Session ([docs](https://requests.readthedocs.io/en/latest/api/#requests.Session.trust_env)).\n\n### References\nhttps://github.com/psf/requests/pull/6965\nhttps://seclists.org/fulldisclosure/2025/Jun/2',
   'aliases': ['CVE-2024-47081', 'GHSA-9hjg-9r4m-mvj7'],
   'severity': [{'type': 'CVSS_V3',
     'score': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N'}]},
  {'id': 'PYSEC-2026-1873',
   'summary': 'Requests `Session` object does not verify requests after making first request with verify=False',
   'details': "When using a `requests.Session`, if the first request to a given origin is made with `verify=False`, TLS certificate verification may remain disabled for all subsequent requests to that origin, even if `verify=True` is explicitly specified later.\n\nThis occurs because the underlying connection is reused from the session's connection pool, causing the initial TLS verification setting to persist for the lifetime of the pooled connection. As a result, applications may unintentionally send requests without certificate verification, leading to potential man-in-the-middle attacks and compromised confidentiality or integrity.\n\nThis behavior affects versions of `requests` prior to 2.32.0.",
   'aliases': ['CVE-2024-35195', 'GHSA-9wx4-h78v-vm56'],
   'severity': [{'type': 'CVSS_V3',
     'score': 'CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N'}]},
  {'id': 'PYSEC-2026-2275',
   'summary': '',
   'details': 'Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.',
   'aliases': ['CVE-2026-25645', 'GHSA-gc5v-m9x4-r6x2'],
   'severity': [{'type': 'CVSS_V3',
     'score': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N'}]}]}