If you\u2019d like to follow along with my work more closely you can subscribe to my personal blog<\/a> where I publish weekly updates<\/a> about the work I\u2019m doing. If you have questions or thoughts about what I\u2019m working on you can contact me via email: seth@python.org<\/a>.<\/p>\n Back in late August the Python Software Foundation received notice that we\u2019d successfully completed onboarding and had been authorized by CVE as a CVE Numbering Authority<\/a> or \u201cCNA\u201d. The Python Software Foundation CNA scope<\/a> covers Python and pip, two projects which are fundamental to the rest of the Python ecosystem.<\/p>\n Being a CNA means that the PSF can offer staffing to improve the sustainability and responsiveness of coordination and vulnerability disclosure work for covered projects. The PSF CNA also provides rich metadata for CVE records and advisories<\/a>, including remediation information, so upgrading or patching for vulnerabilities is as straightforward as possible for downstream users of Python.<\/p>\n The Python Software Foundation now hosts a vulnerability database on GitHub<\/a> using the Open Source Vulnerability format<\/a> (OSV). This database contains vulnerability information for CPython in addition to vulnerabilities getting published to the security-announce@python.org mailing list. The historical vulnerability information was sourced from Victor Stinner\u2019s \u201cpython-security<\/a>\u201d project in order to provide a complete history of vulnerabilities in CPython.<\/p>\n By using the OSV format the vulnerabilities can be ingested and processed by the Open Source Vulnerability database which can be searched or queried using an API<\/a> for machine-consumable vulnerability information. <\/p>\n Having vulnerability information in a machine-consumable format enables tools that scan software deployments for vulnerabilities to easily provide accurate and automatically updated reports for CPython. The Open Source Vulnerability database also is more discoverable compared to the CVE database, having a readily available public API to query for vulnerabilities, products, and versions.<\/p>\n I have been helping coordinate reports to the Python Security Response Team<\/a> (PSRT) since joining the role. This work includes reviewing all reports, gathering information from reporters, discussing timelines, and working with core developers to create and release fixes and advisories in a coordinated manner. I also worked with CVE to get CVE IDs assigned on behalf of reports before the PSF was designated as a CNA.<\/p>\n I revitalized the security-announce@python.org mailing list<\/a> to use for future advisory announcements so interested parties can be notified as soon as new vulnerabilities are published (subscribe to the linked list if you\u2019d like to receive these). I coordinated the two recent vulnerabilities affecting CPython (CVE-2023-40217<\/a> and CVE-2023-41105<\/a>) end-to-end from report to published advisory.<\/p>\n Doing this coordination work frees up volunteers on the PSRT to focus on determining whether a report is a vulnerability and working on fixes. I\u2019m also working to further reduce the manual coordination work required by PSRT by moving the reporting and triage process to GitHub using GitHub Security Advisories.<\/p>\n I co-presented a talk titled \u201cWe Make Python Safer than Ever<\/a>\u201d at OpenSSF Day Europe 2023 with PSF Board Member and OpenSSF Community Manager Cheuk Ting-Ho. The slides are available for download<\/a> and the talk recording is available to watch on YouTube<\/a>.<\/p>\n The talk introduced the Security Developer-in-Residence role, went over the challenges that are unique to securing Open Source and Python ecosystems, described completed and future projects to make the Python ecosystem more secure, and gave a list of items that viewers themselves could do right away to make their own usage of Python more secure.<\/p>\n Python releases include signatures from the Release Managers using the signing tool \u201cSigstore<\/a>\u201d. These signatures mean you can be sure that a given release artifact wasn\u2019t tampered with and was created and vetted by the Release Manager for a given Python release.<\/p>\n I did an audit of existing signatures and found some discrepancies<\/a> between the documented identities and providers and what was published for each release. I worked with Release Managers to fix the discrepancies and added extra safeguards<\/a> to release tooling to ensure signatures are verifiable as documented. I also was able to back-fill the new Sigstore signature format<\/a> from existing verification materials to make verifying signatures even easier!<\/span><\/p>\n $ python -m sigstore verify identity \\ Having consistent artifact signatures is important because any discrepancies while consuming these signatures should raise red flags for downstream users and redistributors. This also helps build confidence in the new signing method over existing methods like GPG.<\/p>\n There are three packaging tools (pip, PDM, and Conda) that are important to the Python ecosystem that are at various stages of adopting \u201cTruststore\u201d, a library that I authored prior to joining the PSF to enable Python projects to use system trust stores for verifying HTTPS certificates instead of relying on certifi for certificates.<\/p>\n PDM has started using Truststore by default starting in v2.9.0<\/a>, Conda plans to release optional support for Truststore in v23.9.0<\/a>, and pip already has optional support for Truststore<\/a> since v22.2 but has recently bundled Truststore into pip to remove the need to \u201cbootstrap\u201d into Truststore by pre-installing the library.<\/p>\n Using the system trust store is important because any removals to a trust store (like for e-Tugra root certificates<\/a>) must be propagated to all end systems in order to avoid \u201cmonster-in-the-middle\u201d attacks. Further challenging this propagation is that some tools like pip bundle certifi as a means of bootstrapping, which means that you need to upgrade both certifi and pip in order to completely propagate updates to certifi\u2019s certificate bundle.<\/p>\n This propagation is better suited to a centralized system like an OS package manager or an automatic centralized authority or IT department keeping the trust bundles up-to-date, which can only happen through using system trust stores.<\/p>\n Recently the Python implementation PyPy added support for Python 3.10, thus enabling PyPy to also use Truststore. I subsequently added support and backwards compatibility tests for PyPy to Truststore<\/a> to ensure all compliant implementations of Python can take advantage of the benefits.<\/p>\n Software Bill-of-Materials (SBOMs) are a hot topic in the world of software security due to new government requirements and improved software and vulnerability management tooling. Many tools generate or consume SBOMs as a universal format for describing software and its components and then matching those components to known vulnerabilities.<\/p>\n I’ve started working on an authoritative SBOM for the CPython project, you can follow along in this GitHub repository<\/a> if you are interested. This project is early and this will not be the final product or place where this information is published, this is only a place to experiment and get feedback on the approach and outputs before putting the final infrastructure in place.<\/p>\n I started with the most straightforward release artifact, the source tarball, and I am planning to tackle the binary installers later since they’ll require more research into the release processes. There is a work-in-progress SBOM file for Python-3.12.0.tgz available in the sboms\/ directory on the repository<\/a>.<\/p>\n Using vulnerability scanning tools I was able to see not only vulnerabilities in CPython, but crucially in the bundled subcomponents like expat and pip<\/b>. Without an SBOM the subcomponents to a project like CPython likely wouldn\u2019t get detected properly and thus would be not covered by vulnerability management tooling.<\/p>\n The challenges here will be integrating the creation and maintenance of the SBOMs into the CPython development and release processes while minimally disrupting other core developers workflows and avoiding the need to develop and maintain custom tooling for CPython\u2019s specific use-case.<\/p>\n Python is the premier \u201cglue\u201d language, meaning that Python is often used alongside many other programming languages like C, C++, Rust, Go, and more thanks to Python C API. This benefit also means that Python packages can include projects and source code from sources both within and external to the Python ecosystem.<\/p>\n Those projects and source code from outside the Python ecosystem present a problem for vulnerability scanners which typically rely on explicit metadata about projects and dependencies in order to find vulnerabilities in software manifests<\/b>. Without a clear way to encode this information into packaging metadata it\u2019s impossible to signal these dependencies even if a maintainer of a project wants to do so.<\/p>\n C and C++ projects in particular pose additional issues due to their existence outside of a programming language packaging ecosystem like Python with PyPI or JavaScript and NPM. This makes tracking usage and vulnerabilities in these projects difficult and relies on other identification schemes like CPEs or redistributions in other packaging ecosystems like RPM\/DEB. Without this information scanners today miss vulnerable components bundled in Python packages, meaning developers won\u2019t know how or when their Python deployments are vulnerable.<\/p>\n Solving this issue completely will be a multi-step process, starting with being able to encode information about bundled projects into Python distributions which will require a new packaging PEP. After the standard has been decided, next is getting bundled project metadata automatically captured to avoid needing an entire ecosystem to manually annotate every project. Concurrently to this I\u2019ll collaborate with SBOM generation tooling to add support for consuming the new standard and adding that information to SBOMs generated from Python environments.<\/p>\n CPython and pip are two of the most important projects in the Python ecosystem and each have non-trivial release processes. In an effort to increase the integrity of these projects\u2019 releases I\u2019ve researched and documented their release process<\/a> and with SLSA\u2019s list of historical supply chain attacks against software projects<\/a> have been making suggestions and implementing improvements.<\/p>\n These improvements include reproducibility of built artifacts, extra guarantees on the integrity of inputs, automating the build processes to reduce attack surface area to only services like GitHub Actions and Azure Pipelines instead of individuals\u2019 computers, and making it so that in the event of an attack that it would need to be publicly detectable and traceable.<\/p>\n By improving the integrity of these processes I am hoping to prevent disaster scenarios such as malware being injected into Python or pip at the \u201clast mile\u201d before being published to python.org. Injection of malware during build time has happened to multiple other Open Source projects with disastrous results for users<\/b>. This work means users can be even more confident in their usage of Python and upgrade early and often to take advantage of Python\u2019s latest features.<\/p>\n\n It\u2019s been three months since I was first hired as the inaugural Security Developer-in-Residence. I\u2019m quite proud of what I\u2019ve accomplished so far and think it shows the value of investing into the security of Open Source through hiring folks to work fu…<\/p>\n<\/div>","protected":false},"author":2051,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"slim_seo":{"title":"Security Developer-in-Residence 2023 Q3 Report - ITTeacherITFreelance.hk","description":"It\u2019s been three months since I was first hired as the inaugural Security Developer-in-Residence. I\u2019m quite proud of what I\u2019ve accomplished so far and think it s"},"footnotes":""},"categories":[10700],"tags":[],"_links":{"self":[{"href":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/wp-json\/wp\/v2\/posts\/329637"}],"collection":[{"href":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/wp-json\/wp\/v2\/users\/2051"}],"replies":[{"embeddable":true,"href":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/wp-json\/wp\/v2\/comments?post=329637"}],"version-history":[{"count":1,"href":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/wp-json\/wp\/v2\/posts\/329637\/revisions"}],"predecessor-version":[{"id":329638,"href":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/wp-json\/wp\/v2\/posts\/329637\/revisions\/329638"}],"wp:attachment":[{"href":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/wp-json\/wp\/v2\/media?parent=329637"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/wp-json\/wp\/v2\/categories?post=329637"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/wp-json\/wp\/v2\/tags?post=329637"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Python Software Foundation authorized as a CVE Numbering Authority (CNA)<\/h2>\n
CPython vulnerability advisories available in Open Source Vulnerability database<\/h2>\n
Python Security Response Team<\/h2>\n
OpenSSF Day Europe 2023<\/h2>\n
Sigstore signatures for Python release artifacts<\/h2>\n
–bundle Python-3.12.0.tgz.sigstore \\
–cert-identity thomas@python.org \\
–cert-oidc-issuer https:\/\/accounts.google.com \\
Python-3.12.0.tgz<\/span><\/p><\/blockquote>\nAdoption of system trust stores via Truststore<\/h2>\n
Future Projects and Challenges<\/p>\n<\/h2>\n
Software Bills-of-Materials for CPython<\/h3>\n
Tracking bundled dependencies in Python packages<\/h3>\n
CPython and pip release process improvements<\/h3>\n
![\\\"IT\u96fb\u8166\u88dc\u7fd2](\\\"http:\/\/itteacheritfreelance.hk\/test\/wordpress\/wp-content\/uploads\/2016\/05\/logo2-2.png\\\"){kind=logo}
\r\nwww.itsec.hk<\/a>
\r\nwww.itsec.vip<\/a>
\r\nwww.itseceu.uk<\/a>
<\/p>","protected":false},"excerpt":{"rendered":"