There are many reasons organizations change their applications, infrastructure, and business priorities. Customers demand new features and users identify bugs. Strategies are updated to adapt to changing market conditions and competitive moves. Technologies become outdated and are replaced with the latest and greatest. Regulatory requirements are updated. Application environments have grown in complexity and it is impossible for any one individual to understand the impact of a change and how it may impact the full system. We need to take an entirely new, risk-based approach to change management for the SDLC - and it needs to span from Design to Code to Cloud.
The Greek philosopher Heraclitus said “The only constant in life is change” around 500 B.C., so people have been struggling with change seemingly forever. But what's new is both the speed of change itself and the complexity of applications and IT environments. “Application” changes no longer occur in isolation. Individual microservices may interact with multiple other microservices. Sensitive data may be exposed in numerous areas of an application and exposed by different APIs. The configuration of an API Gateway can determine whether specific code and data is protected by the appropriate authentication and authorization controls.
The purpose of Change Management is to understand, control, and adapt to change. In the security field, this requires an understanding of how each change will impact the confidentiality, integrity, and availability of the system. In order to be effective, the Change Management process needs to include all information that may impact or be impacted by the change. For today’s applications, Change Management systems that are based on self-attestation are meaningless, and Change Management systems that focus only on code or cloud environments doesn’t make sense. The “system” comprises the entire SDLC, from design to code to cloud.
Consider a change that adds PII to an existing data model in a high business impact application. To effectively understand the risk of the change, you need to understand how the data are being accessed and protected. Is it exposed by an API? Is that API Internet-facing? What are the security controls for the API and are those performed by an API Gateway or as code?
Best practice Change Management programs not only analyze the right inputs but ensure that the right people are involved in the decision-making process. The roles and expertise of individuals are an essential part of the process and ensure that the correct decisions are made at the appropriate time.
For example, when a user story is assigned, does the request match the developer’s security and compliance expertise? Is the developer new or asked to code in an unfamiliar language? If they are making a change to a security control, is there another developer or security champion that may be appropriate to help code or review the change?
Ineffective Change Management leads to misunderstanding the risk and impact of a change on the business. In some cases, high-risk changes with a tangible business impact can be missed. This can lead to financial losses, impact on brand and reputation, legal exposures, and more.
In other cases, time may be wasted on changes that seem significant but are not. This impacts the speed of feature delivery and revenue. Both situations can be avoided with an appropriate Change Management process. Extending that process from Design to Code to Cloud is critical for effective application development and business growth.