“Shift left” is a well-known concept for security teams working with software developers. In the simplest sense, it means introducing security at the earliest possible point in the software development lifecycle (SDLC). To understand why this is crucial, especially right now, it’s important to consider a few key points about the software development lifecycle.
It All Starts With the Development Process
Let’s take a quick look at the software development life cycle (SDLC). For a typical development environment, the SDLC reflects how code is developed and eventually put into production. The App lifecycle starts with planning, followed by coding, creating a build, testing and then releasing, deploying and running the new application in production.
Responsibilities across the lifecycle are shared between different teams. Developers primarily write and test the code, while DevOps and Ops are typically responsible for building the systems through which the code flows into production. Security is in the mix too, but too often not brought in until the code is already in production.
Given there are separate development (dev) and production (prod) environments, it might seem like security can just focus on securing the production environments. However, with the increase in the use of automation technology, that is no longer a viable strategy. Many of the development processes are automated by tools such as Jenkins, which runs the CI/CD (Continuous Integration/Continuous Delivery) pipeline, or Ansible, which automates putting code into production.
Now, because of automation, not involving security until deployment is simply too late. Critical security decisions have already been made without security’s guidance and altering these decisions can be time-consuming to re-do. Security needs to “shift left” involving themselves earlier in the development process to ensure that each step of the SLDC can be secured from the start.
Shift Left to Include Security At All Stages of the Development Process
How does security make the shift left to embed security early in the process? There are a lot of different ways to incorporate security, but one of the most critical steps to take to eliminate vulnerabilities is to remove hardcoded credentials, secrets and access keys from application code. These are the powerful credentials used by applications to access databases, cloud platforms and other sensitive resources.
We’ve all heard the horror stories of a developer embedding credentials in code and using a code repository for version control without realizing that the repository they thought was private was actually public. Instead of hard coding these privileged credentials in the application, they should instead be secured, managed and monitored by a secrets management platform and only accessed by applications when needed. Code repositories are very widely used, but with secrets management, even when code is inadvertently made public, there are no credentials to be exposed.
One challenge when removing hardcoded credentials is that developers have to code their applications to fetch the passwords and credentials needed to securely access the resource. While it is relatively easy to replace the hardcoded credential with a simple API call early in the development process, it will require considerable rework if you wait until after credentials are hardcoded into the application. A huge potential hassle for developers – but something which be easily solved by having security teams engaged with developers early in the development lifecycle.
Partner and Engage with Developers to Address Security
Developers too often view security as a roadblock, especially if they jump into the process late. Developers also may not fully understand the specific security needs and approaches and may think they can handle it themselves. If you want to get security and DevOps teams to work together smoothly, here are a few practical steps to consider:
- Transform your security team into a DevOps partner, by first developing some of the basic skills to understand the development process, so that you can communicate to the development team in their language.
- Work with your DevOps counterparts to establish enterprise requirements for securing secrets and credentials.
- Help developers understand the security vulnerabilities and the challenges that come with addressing them. Communicate the vulnerabilities in terms that developers can more easily relate to, such as the recent Kubernetes or Docker vulnerabilities. Once they fully understand what it means to be responsible for security — handling compliance and audit requests, securing the human credentials for the DevOps tools, maintaining the secrets management platform and so on – they’ll be eager to hand off those responsibilities.
- Make it easy for developers and their code to consume secrets with APIs or out of the box integrations with popular tools, so they can incorporate security into their code without impacting velocity.
- Avoid security becoming a bottleneck. Consider offering self-service solutions, such as an automated approval process that enables developers to request security policy updates that allow their apps to access secure resources.
With these steps, many security teams work very successfully together with development teams and build security into their processes. It’s important to recognize that incorporating security early is a journey and even small steps are important.
Want to learn more about how to incorporate security earlier in the development process? Check out our webinar, Securing DevOps 101: “Shift Left” with Security into the Development Workflows, or review The CISO VIEW: Protecting Privileged Access in DevOps and Cloud Environments, which is packed with guidance from CISOs from the Global 2000 organizations.
