Rising perils amid a plethora of platform choices

Segregation of duties (SOD) in a DevOps environment
Achieving SOD requires implementing preventive or detective measures throughout the DevOps process to prevent an individual software engineer from unilaterally developing and implementing a production code change. Typically, this is achieved by requiring peer review on code changes combined with build and release tooling restrictions to prevent unapproved code changes from being deployed to production.

Source code management (SCM)
Without proper configurations within the SCM tool, changes could be made to the source code without review or approval. If additional controls are not in place in downstream systems, this creates a potential SOD risk in which a single engineer could make a code change and deploy it to production without review or approval.

Testing
Failure to conduct unit testing, integration testing, or end-to-end testing could lead to many issues, like failure to identify errors in the code and a disconnect between the microservices among others. In a mature DevOps environment, financially relevant testing may also be conducted to reduce the risk that a change will likely have an intentional impact on downstream financial reporting.

Build
Build tooling can point to code sourced from an unapproved location. Such activity will likely not be easily identifiable via controls placed on downstream systems because it may appear to have been created appropriately from within the build tool. This makes the risk upstream change management controls over SCM, and testing could be circumvented without detection.

Artifact storage
Artifact storage locations are used to hold code prepared by the build tooling before being deployed to the production environment. Changes to artifacts stored within the artifact storage tool create the risk that upstream change management controls over SCM, test, and build tooling could be circumvented without detection.

Deployment
Configuration changes within the deployment tooling could allow engineers to deploy software sourced from outside company-accepted tooling, creating the risk that upstream change management controls over SCM, test, build, and artifact storage tooling could be circumvented. Proper monitoring of deployments put into production could protect these activities.

Direct and indirect access to production
Users with direct access to production can modify the code running on the server and/or the data stored on the server. Additionally, configuration changes could be made directly to the production hosts themselves, allowing the host to receive potentially unapproved software. Further, multiple tools are typically used to deploy code to production in a DevOps environment. Users with privileged access to these tools can modify them to circumvent change management controls within the deployment process.

Integrations and interfaces
In platform architectures, communication between services is vital. IA needs to understand the types of integrations and how to address risks related to the completeness and accuracy of data.

Data aggregation and transformation
We often find that data flowing through platforms is aggregated, transformed, and cleansed. Tooling and/or in-house written queries are used to assist with such cumbersome tasks, especially given the data-centric world we live in today. With that said, IA needs to consider the risks associated with inappropriate transformation logic, as it can lead to inaccuracies in the data that can be difficult to reconcile or revert downstream.