Mission Possible: Securing Developer Access, CI/CD and Code (With Love)

Okay, so you’re a security leader at your enterprise – congratulations! It’s a big, challenging role, as you know too well. You or a colleague are likely responsible for securing the cloud and legacy apps that drive critical revenue and customer engagement for your organization. But it’s not just the apps you need to secure. There’s also increased executive scrutiny and interest in ensuring that the build, testing and deployment processes are secure and won’t cause unplanned outages. These are unquestionably big tasks. And you know which teams write and run those cloud apps: the cloud team, platform engineers, DevOps admins and developers.

Understanding Developer and Cloud Team

That’s right, developers, cloud engineers and DevOps admins, how well do you know these teams? How important is security to them? Maybe the question we are asking ourselves is, what do the broader development teams want? It’s fair to say that security will be, at best, one of multiple priorities for many of these teams and roles.

First, developers, cloud engineers and operations all need to access cloud resources and various dev tools to do their jobs, but how much access do they need, and which tools do they need to use vs. administer? Second, developers need to write code and build apps to get the features and capabilities required to market rapidly. And yes, they know their apps need to be secure, but there can be many cases where the development team can be pretty sure the code is secure. But is it really secure? Too often, it isn’t secure because of a lack of secure processes and tools, human error or a process skip.

As security leaders, how well do we understand what it takes to secure developers’ build environments, pipelines and access requirements? What about production environments? How confident are we that we can restrict access to tools, enforce security processes, for instance, and not impact productivity and operations?

Providing Transparent Security Without Burdening Cloud Teams

So, what should we do to ensure the security of dev and cloud environments? In most cases, a mandate from the security team isn’t viable, and even if it is, how well will mandated tools and processes be adopted? You know the answer. But how can we ensure security without burdening developers with new processes and tools? Ideally, we could let them access and use cloud resources and secure secrets using the tools they already use and transparently ensure the tools, access and development processes are secure. By achieving this, security requirements will not burden development teams, and security can ensure that apps and development processes are secure. Providing security while staying out of the way, or at least being minimally visible, helps accelerate acceptance from the development and cloud teams.

Educating Developers: Security As a Pain Reliever (Lessons from A Snowboarder’s Lost Powder Day)

However, developers can also experience much pain and additional work from a security failure. For example, when credentials were stolen from a popular code repository, CircleCI issued an advisory that all credentials should be rotated. With automated rotation, that’s relatively easy, but if the credentials are manually rotated, that’s days of work for developers.

I recently saw this firsthand – one of my snowboarding buddies and developer friend was alerted on the chairlift that his organization’s cloud credentials had been hardcoded and posted to a code repository. Fortunately, it appeared the credentials had not been stolen. His team removed and secured the hardcoded credential…. but didn’t rotate it. Duh, but he’s a developer, not a security person. The attacker got what they wanted with the original credential and stole their cloud resources – even when you delete versions in a code repository, the old versions are still there.

Sadly, my friend lost a powder day on the slopes (we don’t get many of those in New England), development slipped, and dev resources were wasted. It was a huge pain and embarrassment for him and his company – all because a credential was not rotated. The reality is, of course, that security incidents are always painful and never happen at convenient times.

Being Loved by Preventing Pain and Accelerating Development

If we can prevent dev teams from experiencing pain and have devs realize that security has their back, then security teams can be loved! The message to dev teams can be: Keep doing what you’re already doing, and we, security, will help keep you out of trouble! Or, even better, with automation tools, such as automated secrets onboarding from popular dev tools like Terraform, we (security) can help accelerate your development processes.

Now, that’s a win, and it puts security on track to be loved!

Taking a Holistic Approach to Security Avoids Impacting Agility

Let’s dive deeper into how we can deliver transparent security processes. Of course, we’ll need to take a broader perspective. While technology is a key enabler, it’s not just about technology; it’s also about people and processes. Developers want and expect to automate everything they do, so automated security processes are a key requirement.

And, when we talk to development leads, it’s clear they care a lot about security, and their collective voice echoes a common sentiment: “Security is non-negotiable, but it must not come at the cost of our agility and creativity.”

Achieving Transparent Security by Addressing People, Processes and Technology

Here are three essential requirements and challenges to consider (as you seek to be loved):

1. Technology. Let dev teams do what they are already doing without needing to change their workflows, processes or tools, or at least to keep any changes to a minimum. Make security transparent to the developer. For example, allow developers and cloud teams access to cloud resources through the cloud providers’ consoles that they are already using while giving the security teams precise, granular controls with zero standing privileges (ZSP)

If developers are already using Kubernetes Secrets or the cloud providers’ built-in (native) secrets vaults such as Azure Key Vault, AWS Secrets Manager or Google Secret Manager for securing their secrets – let developers keep using them while meeting corporate security mandates by transparently giving security teams a centralized view of all the secrets stores across the organization, providing and managing rotation and taking care of audit needs. This eliminates the need for dev teams to be concerned about secrets rotation or logging audit data. Instead, developers can access secrets from the native vaults just like they’ve done before.

While developers continue to access secrets from native vaults as they have always done, it is crucial to explore how centralized security measures can further enhance the protection of these secrets without disrupting existing workflows, as demonstrated in the ESG Showcase for AWS Applications.

2. People. A frequent, key challenge for security teams is working and aligning with the cloud teams. This critical step ensures that while security teams can offer transparent solutions for developers, they will often need to reconfigure access and other permissions to the cloud to deploy these technologies.

In our recently published technical community blog, “Secrets Hub Success: Engaging with Your Cloud Teams,” CyberArk’s professional services team outlines approaches for reaching out and making requests to the organization’s cloud team.

3. Process. Establishing secure automated build environments and processes is a balancing act – what can be done to ensure CI/CD build and development processes are secure without burdening developers? While automation and technology play significant roles, there are also process steps to improve security. For example, security can be strengthened, and any damage limited by approaches such as segmenting access to code bases, automating pipeline creation and forcing destruction after the build so that no credentials can be reused, forcing manual inspection of a pull or merge request by requiring MFA at critical build steps and of course severely restricting access to production environments.

Recognizing these challenges, the webinar titled “Software Development Environments in the Real World: Striking the Right Balance between Security and Innovation” offers insights into practical solutions. CyberArk development and R&D leaders draw upon research from the new book by O’Reilly Media and CyberArk, “Identity Security for Software Development: Building With Identity, Secrets and Credentials,” to address these concerns.

Collaborating with Dev and Cloud Teams – Don’t Force Technology

A holistic approach addressing technology, people and processes is essential to secure development environments and teams. No matter how good it may be, trying to force the latest security technology on dev and cloud teams risks frustration and lagging adoption. Instead, by taking a holistic approach, it is possible to be loved while securing developers’ access, CI/CD pipelines and code – and more “love” will help you drive higher levels of adoption of secure practices.

Partnering and Engaging – Key Approaches

Key elements that security teams have used to partner with development and cloud teams to establish secure build and development processes include:

• Engaging with developer leads and cloud teams to understand their needs and challenges and to build trust.
• Identifying and enabling security champions in the cloud and dev teams.
• Offering flexible security solutions that minimize changes to developer workflows.
• Providing automation solutions to help development teams maximize their efficiency.
• Working with DevOps admins and the platform engineering teams to build process steps that boost security without burdening teams and impacting productivity.
• Fostering a culture of shared responsibility for security. Highlighting potential burdens, such as rotation and audit, for which security is responsible.
• Continuously educating and updating teams on best security practices.

By taking these steps, we can ensure that security becomes a fundamental part of the development process. This will lead to more secure and efficient development processes for your organization, which benefits everyone involved. And maybe it even generates a little love for you and the security team.

Chris Smith is a director of product marketing at CyberArk.