We have been working throughout the pandemic to develop ISO/IEC 24772-4 Programming languages – Programming language vulnerabilities – Vulnerabilities for the programming language Python. This document is essentially ready to go to ISO for Draft International Standard balloting. Before we initiate that step, however, we want the Python community to review it and provide feedback. I will review feedback on this forum or anyone interested can send me comments at stephen.michell@maurya.on.ca.
@effigies Thanks for sharing the link to draft, in the docs folder multiple versions were available for review. As a consultant working in Software as a Medical Device (SaMD) with a focus on cybersecurity, I’ve reviewed some of the documents and had some thoughts on its Python-specific guidance.
While the document does a decent job addressing language-level vulnerabilities, many of Python’s real-world security risks arise in application domains like web development, where challenges align closely with the OWASP Top 10. Given the prevalence of these use cases, it might be beneficial to see guidance that reflects the types of vulnerabilities developers are likely to encounter when deploying Python-based software.
In my experience, teaching foundational security practices is often more achievable than teaching developers how to program Python more effectively, at least as a consultant. From this perspective, the Python-specific standard may be more useful to less experienced developers by highlighting language-specific risks and pitfalls.
I expect that the intent is for developers to follow both the Python specific standard and the general standard (ISO/IEC 24772-1) together. I personally prefer the general standard as it covers foundational security practices that are easily overlooked in real-world Python applications. You may follow all the points from the Python specific standard and still have created a very vulnerable application.
I’m curious to hear what kind of feedback you’re specifically after
There are still editing markups in the document, but it is essentially complete. The ISO balloting process could result in some changes, and comments from the Python community can impact the document.
Stephen Michell
Maurya Software
Convenor ISO/IEC/JTC1/SC22/WG 23 Programming Language Vulnerabilities
Tel: 613 299 9047
email: stephen dot michell at maurya dot on dot ca
Thank you for this research. In general, I am happy when this work is done but would be even more excited if the results of this work was contributed to a place that doesn’t require people writing Python to read this document. There’s the unknown-unknowns problem (do I need to care about security?), discoverability problem (where to look? which article?), reading and understanding, and finally the long-term “solution” requiring every developer who contributes code to go through this cycle. This is not an efficient use of time by developers, especially to cover the scope of secure coding practices.
My recommendation is to contribute these findings to an automated source code analysis tool in Python, such as Bandit, so that we evangelizing Python security have a much easier job to do: telling people “you should use Bandit!”
Secondly, the OpenSSF Best Practices working group has a project happening now that intersects quite heavily with your work, creating a list of known insecure Python code patterns and alternatives. I’ve given them the same feedback that I’ve given you about contributing to an automated tool. Hopefully these links and advice are of use
