Introduction

Shifting left on identity governance and administration (IGA) refers to moving the focus on identity management and access control earlier in the software development process. This means that identity considerations are taken into account from the beginning of a project rather than being added as an afterthought later.

There are a few aspects to shifting left on identity governance:

1. Including identity engineering early in application development discussions, so identity considerations are included in the project’s requirements gathering and design phases.
2. Implementing automated identity governance tooling to help enforce identity-related policies and controls throughout the development lifecycle.
3. Educating developers on identity policies and best practices via training and information sharing between security, identity, and development teams to help ensure identity engineering requirements are considered and implemented early.

By shifting left on identity governance, organizations can ensure that identity considerations are appropriately integrated into the development process and that the systems and applications they build are secure and compliant.

‍

Shift Left on IGA: Why?

As DevOps has gained momentum, developers and security teams are faced with new challenges: applications are being decomposed as a mesh of distributed (micro)services leading to an explosion of interconnectedness and making the idea of central supervision worthless. In addition, corporations are starting to understand that security concerns require the same kind of culture shift resulting in the emergence of the DevSecOps movement. Recently, we have begun to include requirements from application security and security operations into the modern continuous integration pipelines to (i) implement requirements that help security scale with product development or (ii) run custom automated security checks to find vulnerabilities. The next iteration in this “shift left security” will be identity and risk/compliance teams where capabilities like “compliance-as-code” and “policy-as-code” are implemented to proactively discover and remediate violations at the developer (aka code) level.

This approach helps mitigate any identity-related security threats and vulnerabilities that could compromise the organization, its users, and its provisioned infrastructure once the software has been deployed.

Despite these benefits, many teams continue to use a traditionally mix-and-match approach to identity, leaving them open to a variety of challenges, such as:

• Static credentials are difficult to attribute to users, resulting in too much time spent protecting them from getting into the wrong hands.
• Shared accounts are difficult to audit and make it challenging to confirm the user and their role.
• Local accounts do not tie back to a system of record, making it nearly impossible to track whether users have the correct permission access level.

Further, onboarding new users to dynamic systems and applications is complex, as well as decommissioning their access when you need visibility into where their accounts and credentials might live.

‍

IGA’s role in DevOps

Now that we’ve defined the “why,” — let’s get into the “what” of the role of IGA in DevOps. As DevOps functions increasingly add security to the mix (see DevSecOps), IAM (identity and access management) has become crucial to ensure completeness. Identity represents access and the associated privileges, which is essential in ensuring activities are appropriately authenticated, authorized, and audited. Across every phase of the software development lifecycle, it is critical to focus on identity in each lifecycle function (plan, code, build, test) and each ops function (release, deploy, operate, monitor). At each stage, IAM helps answer questions like:

(i) Which users have the access rights to develop code

(ii) What accounts and credentials are needed in the code

(iii) What privileges are required across target resources

‍

Shift Left on IGA: the benefits

Integrating identity requirements in the CI/CD pipeline will improve product time-to-market and reduce friction between security and development teams while proactively managing identity risk. To summarize:

a. Faster Time to Market

Shifting identity governance left can help teams go to market much faster by ensuring requirements are reviewed automatically in build/deploy (resulting in speedier integration/implementation of these requirements) and eliminating security bottlenecks from occurring in the final stages of development.

b. Risk Mitigation

When identity teams don’t work closely and cohesively with engineering teams, requirements can easily slip through undetected and emerge after a product goes to market. Partnering early, providing feedback on exceptions, and creating checkpoints or guardrails can prevent software from moving forward when company IAM policies are violated.

c. Create a Security Culture

Marrying identity engineers (often a sub-set of security engineering) and software development teams can provide valuable opportunities to promote security awareness and education across technical teams. In doing so, team members can better understand how specific processes impact outcomes and lead to tighter collaboration and more efficient development strategies. The goal is that, over time, developers will be able to create code that meets identity requirements (policies, best practices, etc.) from the start.

‍

Conclusion

Injecting identity as early as possible into automation pipelines is crucial to minimizing the exposure of sensitive accounts and credentials. By doing this, your DevOps team can remove static credentials from code and replace them with just-in-time credentials that help reduce the threat surface and enterprise-wide risk. Furthermore, incorporating a real-time identity governance solution enabling automatic user provisioning and deprovisioning at each production stage will remove the need for manual tasks that hinder productivity and increase risk. Finally, centralizing management of access permissions and authentication requests can provide visibility, making it easier for your security team to monitor activity around your continued, just-in-time access at a fine-grained level.

‍