Why does DevOps recommend "Shift left" principles?

Security in software development

Large and small corporations share a common fundamental interest in delivering secured software. Neglecting security exposes them to data breaches, financial losses, legal liability, and reputation damage.

Most IT departments have dedicated security teams to mitigate these risks. However, the approach to delivering secure software has evolved over the last decades through the DevOps movement.

DevOps emphasizes proactive security, collaboration, and automation. Instead of treating security as a separate phase, it integrates security from the beginning, catching vulnerabilities early and reducing the chance of issues reaching production. Moving security concerns from the end of the development lifecycle to its source defines a transformative process named "Shift left."

What are shift-left principles?

Security management in traditional IT teams

Traditional IT departments rely on reactive security measures, addressing security issues primarily after they occur. They have developed skills and tools to identify production issues and perform emergency operations in production environments.

Security is seen as a separate phase, often applied as a "band-aid" solution rather than an integrated part of the development and operations processes. Security operations are considered as firemen and not as consolidation engineers. Also, this does not include developers in securitizing their codebase, supply chain, or infrastructure.

Liabilities of the traditional security process

This structure strongly emphasizes protecting the public interfaces, while internal systems and applications may receive less attention. It results in uneven security guarantees in the components of information systems. Operations heavily monitor firewalls and gateways, but the code running on these platforms is audited only as part of larger-scale, end-to-end security audits.

These security assessments and audits are typically manual, periodic processes after the development and deployment phases. Vulnerability scans, penetration testing, and code reviews may be infrequent, leaving systems vulnerable to emerging threats.

Bringing DevOps culture into the mix

DevOps is a cultural and organizational movement that promotes collaboration and communication between software development (Dev) and IT operations (Ops) teams. It breaks down traditional silos, fostering a culture of shared responsibility and mutual understanding between these traditionally separate groups.

The main objective of DevOps practices is to streamline the process of delivering high-quality software. Automation plays a significant role in that context, and CI/CD practices are at the heart of it. It involves automating tasks like code builds, testing, deployment, and infrastructure provisioning to reduce manual errors and accelerate delivery cycles.

DevOps promotes a feedback-driven approach to development and operations, emphasizing continuous communication and learning. It fosters early feedback by automating testing, integrating feedback loops throughout the software development process, and deploying code changes frequently.

DevOps and security: Shifting left

Shift left for security practices in DevOps means that security testing occurs earlier in the development process, ideally during the coding and build stages. DevOps emphasizes collaboration and integration between development and operations teams, which also extends to security teams.

Originally, DevOps was designed to limit operational concerns for production issues like bugs or downtimes. Later, we explicitly incorporated security in the development and deployment pipeline with the rise of the DevSecOps movement.

In left-shifted security management, the DevOps process includes security teams. Thus, it ensures that security is considered from the beginning (the left) of the development lifecycle rather than being a separate process.

Principles at the core of DevOps

DevSecOps encourages security testing and continuous security monitoring as part of the development process.
DevOps strongly focuses on interacting with production environments through constant deployment pipelines.
Security testing, including static analysis, dynamic analysis, and vulnerability scanning, is automated and integrated into the CI/CD pipeline.
DevOps fosters a culture of collaboration, including security experts as part of cross-functional teams.
Developers are educated about security best practices, and security professionals gain insights into development processes.

Security as Code

DevOps encourages using infrastructure as code (IaC) for infrastructure provisioning and management. It has the first significant benefit of avoiding manual operations in production environments. When using IaC, infrastructure components are provisioned and deployed automatically through a continuous deployment (CD) pipeline, bringing consistency.

Defining infrastructure and access controls as code allows for enforcing security standards on these configuration files. It is possible to assess compliance with these standards within a continuous integration (CI) pipeline before deployment.

The above applies to configuration as code in general, whether it be a Dockerfile or a CI configuration file. Most supply chain security tools work by assessing the content of a project configuration file and defining the various dependencies of the said project.

Continuous Monitoring

There is no such thing as zero risk. While limiting risks with continuous assessment, DevOps also promotes monitoring of applications and infrastructure in production. Developers remain involved as the DevOps approach for monitoring focuses on giving developers the best tooling to assess and answer production issues quickly. Time to recovery is a standard metric for determining a team's performance in DevOps practices.

DevOps fosters small and frequent deployments. It also involves investing to be able to roll back changes easily. Thus, it becomes possible for developers to provide swift responses to security incidents, dramatically reducing the time to recovery of IT teams.

💡

Escape is designed for continuous security testing, especially in CI/CD pipelines.

Automated compliance against common security standards

DevOps practices can streamline compliance and auditing processes. Automation ensures that security controls and compliance requirements are consistently applied, reducing manual efforts.

This automation takes place through security assessment tools in CI pipelines. Thanks to this, security teams can continuously monitor for security threats. Since this evaluation happens before the code reaches production environments, ensuring ongoing compliance with security policies and standards is much more convenient.

CI pipelines can enforce the most common security standards. Supply chain (dependencies), code, infrastructure, or even a live application in a test environment can all be assessed regarding common security standards directly from a CI pipeline before it reaches a deployed environment.

💡

Escape security scans can achieve compliance against renown API security frameworks, such as the OWASP top 10, as well as PCI-DSS, among others. For more details, see our blog post.

Shifting security left: Methods and best practices

Improve collaboration between developers and security engineers

The first step for shifting left regarding security management is to act to foster a DevOps culture in how your organization delivers software. Conway's law is an empirical law that we often refer to in IT management circles.

🗞️

Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.

In the context of DevOps, this law has a single, fundamental consequence: We have to structure the IT department to foster communication between developers and operations.

The above can mean including an operation in each developer team and asking developers' teams to control their whole deployment lifecycle. It will be the most efficient way to share security and operational knowledge across developers. However, you will stop communication between DevOps of different teams. Per the law above, there is a risk of creating discrepancies in how you operate software across the organization.

You can also ask developers teams to manage their operational aspects through security/monitoring tools provided by DevOps teams that they can use as a service. For instance, a use-case we can often relate to at Escape is an operations team providing access to developers teams on our SaaS platform while setting up Escape security scans within their CI/CD pipeline. Pre-deployment enforcement of security best practices remains controlled by operations teams. Still, developers are notified much earlier in the development lifecycle if their code fails to comply with these best practices.

💡

A use-case we can often relate to at Escape, is an operations team providing access to developers teams on the platform while setting up Escape security scans within their CI/CD pipeline.

Migrate gradually to DevOps practices

A DevOps-compliant IT department features a lot of organizational as well as technological characteristics. These characteristics range from adding a large set of testing tools within a CI pipeline to purely managerial features such as security considerations in the product design phase and infrastructure management by deploying infrastructure as code.

Adopting every practice defined by DevOps guidelines at once will be, at best, challenging for managers and the teams involved. However, there is no need to shift everything at once. Becoming a DevOps organization one step at a time is possible and recommended.

The starting point will depend on your organization's operational constraints. For instance, if your deployment process involves a lot of manual operations, and is known for being flaky, you might want to focus on implementing an Infrastructure as Code strategy. On the other hand, if your product features access control caveats, you will want to focus on security guidelines and checklists for your product teams.

💡

For a short list of good practices to implement, we published an article presenting 7 DevSecOps practices

Provide developers' training for early identification and mitigation of risks

Bringing developers closer to operational and security concerns is the key to a successful DevOps transition. Organizations must provide security training and awareness programs for development and operations teams to ensure they understand and can address security issues.

No limit exists to how left security can be shifted in the development process. Product teams can be involved in security concerns by formalizing security behaviors in their user stories. For instance, at Escape, we must consider the interactions of each feature we develop with our role-based access control (RBAC) model. Should we do a new role for accessing this feature? Does it end in the scope of the RBAC? We systematically address these concerns when designing our product.

Peer code reviews are also an excellent tool for enforcing security concerns to be addressed and sharing knowledge with developers. More than that, security engineers can gain a deeper understanding of the constraints developers meet regarding security. Fostering this mutual understanding can only increase the productivity of the organization overall.

💡

At Escape, we specialize in security, especially API security, through our SaaS platform. Still, we also want to generalize security best practices. For that purpose, we just released our open-source API Security Academy

Automate security review processes

Automating being at the core of DevOps processes, this is a non-exhaustive list of possible automation for your security processes:

Use IaC to define and provision infrastructure through code, allowing for early identification of configuration and security issues.
Perform static and dynamic application security testing to identify coding issues and vulnerabilities during development. That's where Escape, the most advanced dynamic application security tool, comes in handy.
Integrate security scanning tools into the CI/CD pipeline to detect vulnerabilities early in deployment.
Use automated deployment verification techniques to ensure that deployments meet predefined criteria for quality and security.

Conclusion

In today's IT landscape, shift-left principles have emerged as a vital security strategy. They place security at the heart of software development and IT operations, detecting vulnerabilities early and reducing the risk of security breaches.

This proactive approach safeguards data and privacy and shields organizations from financial losses, legal consequences, and reputational damage.

Shift-left promotes collaboration, automation, and continuous improvement, breaking down traditional silos among development, operations, and security teams. It's not a passing trend but a strategic necessity, ensuring the delivery of secure, resilient, and reliable software.

🧢

Do you have to help your team shift API security left? Get started with Escape now.

Test my API

💡 Want to learn more?