Provide a continuous compliance and assurance approach to DevOps that mutually benefits banks, auditors and regulators whilst accelerating DevOps adoption in engineering and fintech IT departments.
Codethink have developed a CI system design pattern (DCS - Deterministic Construction Service) for managing safety-critical software development processes involving open source software and tools; a reference implementation of this pattern was qualified against the applicable requirements of a safety standard (ISO 26262).
A key motivation of the DCS approach was the principle of continuous compliance: that the formal criteria against which the software and its development processes need to be evaluated (in this case from the ISO 26262 safety standard) should be verified as part of the CI workflow. The goal here is to identify any deviations from the applicable criteria as part of an automated verification process, so that they can be resolved in the context of atomic changes, rather than en masse as a result of a periodic audit.
In our reference implementation we used top-down analysis of the CI system using the STPA methodology to derive constraints (specific verifiable criteria to achieve the high level regulatory goals) that we could either test as part of the pipeline, or enforce as part of the CI workflow itself. We also applied the same coordinated change control process to software, criteria, tests and supporting documentation using git repositories.
While this approach was developed with safety in mind, it is equally applicable to any kind of software development process with formal regulatory or security requirements. As suggested] by Richard in #46, I would be happy to present an overview of DCS and how a similar approach might be applied to e.g. CFI in the next SIG meeting.
Codethink have developed a CI system design pattern (DCS - Deterministic Construction Service) for managing safety-critical software development processes involving open source software and tools; a reference implementation of this pattern was qualified against the applicable requirements of a safety standard (ISO 26262).
A key motivation of the DCS approach was the principle of continuous compliance: that the formal criteria against which the software and its development processes need to be evaluated (in this case from the ISO 26262 safety standard) should be verified as part of the CI workflow. The goal here is to identify any deviations from the applicable criteria as part of an automated verification process, so that they can be resolved in the context of atomic changes, rather than en masse as a result of a periodic audit.
In our reference implementation we used top-down analysis of the CI system using the STPA methodology to derive constraints (specific verifiable criteria to achieve the high level regulatory goals) that we could either test as part of the pipeline, or enforce as part of the CI workflow itself. We also applied the same coordinated change control process to software, criteria, tests and supporting documentation using git repositories.
While this approach was developed with safety in mind, it is equally applicable to any kind of software development process with formal regulatory or security requirements. As suggested] by Richard in #46, I would be happy to present an overview of DCS and how a similar approach might be applied to e.g. CFI in the next SIG meeting.