One of the places we have always differentiated ourselves from other teams building identity governance solutions is that we treat each project as a traditional software development project. We focus on managing the source code of the project and integrating builds into continuous integration and continuous deployment pipelines to be more agile and repeatable in the identity governance solutions we provide.
Previously, many of our team members had been part of identity governance programs where the development environment was configured completely differently from the production environment. Other team members were allowed to go into production and make configuration and code changes directly without any process or approvals.
There was no way to prove what code was running in production and, in the event of a disaster, there was definitely no way to rebuild the entire environment from code. In some cases, it would take weeks to get the identity management system back online and manually reconfigured with little trust that the solution matched what was lost at the end of the day. Merging in new code for new integrations led to hopes and prayers that it would work.
This never sat well with any of us and we kept seeing the pattern repeated over and over by other teams with customers none the wiser until something broke.
With identity governance becoming a key tenant of every organization’s security posture, we couldn’t let these practices continue in projects where we are were involved.
Today, our teams are rebuilding their local dev environments with docker in less than 10 minutes. If a new team member joins, they are up and running with the latest version of the code in minutes. Each time the team is completely re-building SailPoint IdentityIQ, ForgeRock DJ and AM containers, downloading the latest configurations and source code and merging them into the deployed war file for each customer to immediately test any changes.
We utilize a git-flow branching model to build new, repeatable releases from git in our development, test and production environments. Once tests are passed, they can be automatically be deployed and updated directly in the customer’s production environments.
Our team always know exactly what configuration is running in production and if we have to roll anything back we know exactly what source code was running previously and when. If the code is modified in production, we can detect the changes and immediately put it back to the last known good version. If the vendor puts out a new security patch or minor version upgrade, in most cases, we can have that integrated, tested, and ready for production in 24 hours.
To be able to do that, we have to do a lot of automated testing throughout the process. Many times I talk about the different approaches we take with SAST and DAST techniques and their benefits. In the identity community, this is a very new topic for most organizations. When Synopsys put out the infographic above it really helped clarify the message. Because many of these solutions utilize vendor products, we have to use a healthy mix of SAST tools to validate the source code we are developing and DAST tools to validate that the running application continues to function securely when it’s integrated and deployed into the test and production environments.
Hopefully, this graphic can help you in your testing conversations. If you’d like to learn more about how we’ve helped our customers to be more agile in their identity governance solutions and deliver higher quality, repeatable solutions, we’d love to talk.
