What is shift left security? The concept of shifting left comes from the four stages of the software development life cycle (SDLC): Develop, build, test and deploy. Developers are at the far left of the process. Anything passed to them, such as cloud security, testing or other tasks counts as a shift left.

At the heart of the shift left approach is that processes need to happen early in the software development process—they need to involve the developers. By moving processes such as testing and security to the development phase, fewer errors make it to the advanced phase of the SDLC. This approach often means less testing work and lower repair costs for the business.

The rapid evolution of DevOps poses new challenges for developers and cybersecurity teams. Information systems have been restructured into a grid of distributed microservices, with an explosion of interconnections and a reduced reliance on central monitoring.

As a result, businesses understand that cybersecurity must involve the same cultural shifts that drove the industry 20 years ago and that while collaboration is necessary, it is not enough.

DevSecOps initiatives came into existence for this reason, but moving security to the left requires organizations to provide developers with the tools to work securely without adding extra work. It means incorporating security best practices into the developer’s toolchain.

DevOps and the Cloud

The cloud is a technology that powers nearly every stage of a successful DevOps operation. Cloud computing allows organizations to:

• Rapidly scale development systems up and down as needed.
• Easily build an experimental test environment to prototype solutions quickly without the cost and hassle of physical hardware.
• Leverage hybrid infrastructure and perform cloud bursting when on-premises resources are insufficient.
• Enable concurrent development using technologies like version control, preventing teams from interfering with each other.
• Enable teams worldwide to collaborate and make changes remotely without exchanging files.
• Automate tests in a simulated environment that is indistinguishable from the real environment.

These benefits allow DevOps team members to perform tasks that require human intervention without being delayed by monotonous, error-prone tasks. DevOps is designed to make the most of an organization’s resources, and the cloud has similar benefits.

Cloud computing simplifies DevOps implementations by enhancing every stage of the development life cycle. The cloud gives teams the freedom to build and test applications in various environments.

The on-demand nature of cloud technology eliminates the need for physical machines and saves time and money. A key benefit of software-as-a-service (SaaS) platforms in the cloud is that organizations pay only for what they need when they need it.

Cloud Security Risks in DevOps

DevOps is at the heart of the cloud security life cycle. In the world of self-service, automation and cloud services, developers ultimately make cloud security and compliance decisions. Many organizations solve this problem by moving the security and compliance of their application code into the CI/CD pipeline. A common approach combines automated security testing, strict version control and automated vulnerability scanners.

These changes can help address application code vulnerabilities, but what about the security and compliance of the underlying cloud infrastructure? Cloud security and compliance face four major DevOps challenges.

1. Misconfigurations and risks discovered too late: Most organizations detect risks and misconfigurations in the cloud at runtime rather than prevent them during the build process. This process is inefficient and puts the organization in imminent danger.
2. Loss of developer productivity: Asking developers to fix production problems urgently is very inefficient. Also, runtime security issues are usually ephemeral. They are the result of a problematic IaC template and a developer must resolve the same core error repeatedly.
3. Conflicts between developers and security: Loss of productivity creates friction between developers and security, ultimately leading to a loss of trust in security. This discrepancy may prevent developers from fully participating in the security process or bypassing security altogether.
4. Dynamic environment:  When developers create or deliver new cloud services, those services join existing environments. Newly created resources might be secure and compliant on their own, but they can have security and compliance issues in a broader context. In the rapidly changing world of the cloud, this has become a particularly difficult problem to solve.

Best Practices for Shifting Security Left

The following best practices can help your organization shift cloud security left:

• Define the shift left security strategy
• It is important to have a concise strategic document at the start of a shift left journey. It makes it possible to define what shift left means for the organization and provides a clear picture of how successful teams are at achieving shift left. The main topics that this document must cover are:
  • Vision
  • Ownership and responsibilities
  • Milestones
  • Metrics
• The strategy document will change over time, so spending excessive time on the first draft is unnecessary. It is essential to iterate over time.

Understand Where and how Software is Created in Your Organization

A difficult aspect of shifting security left is understanding how and where software is created within an organization. This task can become more difficult as a company grows. This step is important because it helps the security team understand where to bring security closer to development.

Large organizations can spend months researching and interviewing development teams. Development is often outsourced to multiple vendors, requiring additional work and (in some cases) contract review. This step is relatively easy for small and medium-sized organizations but just as beneficial.

This phase aims to explore the entire organization and document its software processes. Medium and large organizations should start at the macro level and drill down into individual business units. Each business unit may have its own software development processes and tools.

The important things to check at this stage are:

• People—the individuals developing the code.
• Process—how code flows from the development system to the production environment.
• Technology—the systems used in the process (CI/CD toolchain). These usually include public cloud technologies.

Autonomous Security From day One

Automating security is very important. Repeatable processes can speed up work by reducing the number of manual steps. However, the most important reason for automating security is to match how development teams work. With security automation, you don’t need a separate security team to work with the development team. Security has become part of the developer process and a standard way of building software.

To this end, the first step in security automation is to review the tools an organization has deployed and perform security testing to find the best candidates for automation.

The next step is to ensure that the results are obtained in a standardized manner. It enables incorporating feedback from security tests into a bug tracking system to improve the process further.

Integrate While Coding

A guiding principle for organizations looking to incorporate security into their continuous delivery process is to move this process early in the development lifecycle. Integrating security into the coding process is important for creating a tight feedback loop between problem discovery and developer resolution. Asking developers for a fix they just made is much faster and cheaper than asking for a fix after six months.

Running security tests while developers write code enables immediate feedback. It allows developers to perform application security testing, but they do not understand flaws like application security experts do in most cases. Developers also have strict schedules for delivering code.

For this reason, application security should be viewed as an ongoing partnership between development and security. Security defines what is acceptable in terms of quality, and developers implement tests and deal with problems as they arise.

Conclusion

In this article, I explained the shift left principle and showed how organizations are applying it to cloud security. The cloud is having a major impact on every aspect of the IT ecosystem, and security is no exception. By taking cloud security into account, and ensuring security is baked into cloud operations from the moment development starts, you can reduce the cost and effort of cloud security, reduce surprises in production, and better defend the organization from cloud-based security threats.