Software is developed within a defined life cycle with defined release criteria, the development method defines coding standards, repository standards, tools and naming conventions, build and deployment tools are controlled by documented procedures, source code is reviewed to an extent based on language, tools and risk at the point the life cycle requires, and software is under configuration management with version control of code, scripts and artifacts, using orchestration and repository tools that provide assurance and traceability, with development tools assessed for fitness. Design artifacts, in documents or tools, are sufficient to develop and support the software, a software bill of materials is good practice, and software should meet requirements and be reliable, robust, maintainable, able to handle errors and sufficiently commented. Each module carries its name, traceability to design, source files, version, project, description, dependencies and build commands; changes are identified with commentary referencing the change request or sprint and a history of request, version, date, person and summary; software is maintainable by a competent person other than the author; open-source modules are monitored for updates and retirement; dead code is removed while switchable test and diagnostic code is documented, unused options of configurable code are demonstrated deselected and commented-out code is cleaned up before major releases; and defensive coding recovers safely from bad data or equipment behavior with informative error messages. Source code review checks that standards are applied, code matches design and defects are removed, is performed by at least one independent knowledgeable person with the author, may use automated comparison tools and static analysis of control, data, fault and interface behavior and formal verification for high-risk code, has a documented risk-based extent, records problems with corrective actions resolved before testing, and may be recorded in tools. For purchased software, evidence of control comes through supplier assessment with remedial actions or further testing where inadequate; for free and open-source software a risk assessment of business and GxP risks identifies controls, considering community sustainability, documentation quality, version verification with checksums from a reputable source, the governance model for updates, patch currency, participation, and the fact that one-off modifications become custom code the company must manage.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.