Compliance regulations for software is ever growing and more tools are being developed to test and validate Github Repositories for routine checks on the code to make sure it performs how it should be.
United States Compliance is also something I follow very strictly and have implemented within Global-Chem in case of the software being used in a regulatory environment but mostly geared towards standards for the Federal Drug Administration in 21 CFR Part 11 Electronic Records and Electronic Signatures with the main highlighting points being:
- Plausibility: Why does this software exist and why is it needed and what is it’s future purpose?
- Validation: Does it follow a good manufacturing workflow and has a working test system to test the software?
- Audit Trail: Is there an audit trail for the code and the build systems.
- Legacy Systems: Is there history of the development of the software, has the software reached a mature state.
- Copies of Record: Is there documentation to show how the the software is used and changed over the time.
Global-Chem’s documentation addresses a lot of this in more detail but the jist of the outline for a compliance submission would look like this and the key points to be addressed.
In the US, we are required to submit Installation, Operational, and Performance qualifications for the software to prove that it produces consistent results. I wrote one for the python package here and tested it across different platforms under different versions to validate the software installs and performs on Linux, MacOS, and Windows. Outside of the scope, would be other operating systems and platforms to try on.
Test suites were also built and documented appropriately according to how the U.S standards would accept it since we should be following Good Automated Manufacturing Processes (GAMP).
This starts to bring us into the realm of what is needed for the U.S Compliance software.
Recently, our folks from across the pond implemented FAIR with something called howfairis.
FAIR is another protocol designed for how data is organized and managed. I have seen more of my European collaborators adhere to FAIR practices which fall in line with U.S compliance as well. But to validate we do adhere to FAIR I implemented their Github Action Bot. I would say the bot was a little picky on some aspects:
I must admit a lot of these badges I don’t really know. But it seemed like it was a checker for certain common tools to manage infrastructure and distribution which is what data management is all about. I think for some like NPM or Maven I wouldn’t needed. Conda would definitely be something I need to expand into but don’t have the time to learn how to build a Conda package. This makes a lot of sense of what FAIR is testing and could be pretty useful in the future. I will focus on distribution efforts more very soon to make it easier for folk.
What I have learned more, on my compliance journey, was the OpenSSF badge which I think should probably be in Global-Chem.
Going through the checklist here was very comprehensive and I realized I am missing some security vulnerability checks. They were very thorough about what algorithms I used to implement my keys and made sure they were strong as well. I think that is not a question I have had to answer.
Okay, this is a start into some of the stuff I am doing to make my codebase compliant with the world’s standards for software. Hopefully this eases process for others as well.
