What is DevSecOps?
DevSecOps is a joint effort by development, security and operations personnel to ensure that products are released efficiently and securely from the start. The model was developed to address security vulnerabilities that arise when security is introduced too late in the development process. This requires rewriting the unsecure code, delays release to production, and risks deployment of software with severe security issues.
DevSecOps mandates shifting left security in the development lifecycle. Instead of happening at the end of the cycle, security starts from day one. Tools and processes are provided to operations and development teams to help them make security decisions, from the planning stage, through development, testing and deployment. At the same time, the security team adjusts these tools and processes according to development and operational requirements to maintain an agile work environment.
The process of transitioning to a DevSecOps team is not easy, but using the right tools can simplify adoption of the process and collaboration among dev, ops, and security teams.
How Can DevSecOps Improve Both Security and Velocity in Software Development Pipelines?
The goal of DevSecOps is to bridge the gap between IT and security by adding security practices to the already fast and agile software delivery process. Organizations using the DevSecOps model understand that security cannot be considered at the end of the delivery pipeline, so they make it an integral part of the entire software development lifecycle (SDLC).
DevSecOps collaboration is much more difficult than DevOps because it requires the organization to achieve two contradicting goals:
- Trying to speed up the delivery process
- Ensuring code is safe from vulnerabilities or security gaps
Traditionally there were two schools of thought: some thought security was not so crucial and could be pushed aside in favor of releasing software faster. Others believed that it is better to bring products to market slowly, but ensure maximal security. DevSecOps tries to combine these two approaches and deliver high velocity with a high level of security.
To implement DevSecOps without compromising product quality, organizations are building a culture of “security as code”, encouraging developers to consider security issues and encouraging security teams to automate tasks. In addition, the organization is committed to flexible and continuous collaboration between IT engineers, software developers, and security teams, by facilitating communication and collaboration.
DevOps vs DevSecOps: What Is the Difference?
The primary difference between DevOps and DevSecOps is that the former is a convergence of development, operations, and application delivery, while the latter converges all of these with security.
DevOps vs. DevSecOps
DevOps focuses on technologies and techniques that can help developers and operations teams work together to achieve common goals, while DevSecOps is focused on practices that can add security considerations to an existing DevOps pipeline.
DevOps Elements
Microservices
In a DevOps team, developers often use a microservices architecture, building software as a set of independent services, each providing a separate function. Each microservice can run autonomously in a container or virtual machine (VM), and it is easier to identify and resolve production issues in a single microservice or container, rather than in a large, complex system.
Infrastructure as Code (IaC)
Infrastructure as Code is a method of using code to manage and automate computing resources such as hosts, virtual machines and containers. Developers use IaC to perform IT operations automatically, eliminating the need for IT assistance and supervision with infrastructure-related tasks. Operations staff can also use IaC to spin up environments on demand and provide self-service functionality for developers.
Policy as Code (PaC)
Policy as Code is a way to use code to manage policies, such as an organizational decision to use specific types of technologies, security standards or IT practices. Policies are provided in code format, making it possible to automatically enforce policies across the organization in all stages of development.
DevSecOps Elements
Shifting security left
“Shifting left” is moving a task to an earlier stage in the development cycle. Moving security “to the left” ensures that security standards are met from the time the codebase is first developed. Development tasks are considered “done” not only when functional requirements are met, but also when the codebase is tested to be free of security flaws and vulnerabilities.
Continuous feedback loop
The continuous feedback loop regularly encourages all team members to improve their development and maintenance practices. Continuous feedback is backed by an automated process that can continuously monitor for security vulnerabilities and provide real-time alerts to developers and security experts, as soon as a security issue is introduced into the development pipeline, allowing all teams to collaborate and fix it immediately.
Security automation
Automation is a key factor in ensuring that DevSecOps standards and practices are met at all stages of the development lifecycle. Automation allows DevSecOps teams to quickly take on more security responsibilities, including automated code analysis, compliance monitoring, and threat investigation.
DevSecOps Implementation: Challenges and Solutions
Like any organizational or cultural change, implementing DevSecOps introduces significant challenges. Here are some of the common challenges and how your organization can deal with them.
Resistance to Change
It is natural for people to resist a change from a familiar state or process. For people who did not “grow up” in DevOps teams, collaboration between departments can be more difficult to adjust to. Teams who have been working independently in “silos” now need to work together with others and adjust their work process. This requires planning and patience. In other cases, teams may embrace the change, but administration functions or executives can oppose it.
To make the transition as smooth as possible, get support from stakeholders. Clearly outline the “business case” of the transition in terms of improved productivity, financial benefits and improvement of consumer confidence.
When planning your migration to DevSecOps, you should include management and members of development, security, and operations teams. This allows you to keep everyone’s needs and priorities in mind when planning your strategy. It also provides an opportunity to let everyone practice communication and negotiation, which is essential for the future.
Mismatched Tools and Processes
There are more and more tools developed to meet the needs of DevSecOps, but these tools may not be suitable for all teams. Some of the tools and processes already in use may remain useful after the transition. Others need to be retrofitted or replaced.
Integration of automated security testing tools is often the first step—for example, static application security testing (SAST) and dynamic application security testing (DAST) tools can be used throughout the development process.
When deciding which tools and processes to use, teams must make joint decisions. If a tool is difficult to use or directly hinders productivity, it will get in the way of the organizational change. Ideally, the tools and processes you choose should be transparently integrated and streamlined for all parties involved. These tools and processes should focus and automate your workflow as much as possible, to make collaboration easier and improve productivity.
Developers are Not Security Specialists
DevSecOps requires operations and development teams to share security responsibilities. In addition, the team must incorporate security processes into their workflow. A related issue is the complexity of the security process and security requirements.
The fact is that at the outset, only security personnel will have knowledge and skills related to security. This is especially a problem for developers. They will need to learn more about secure coding methods and incorporate security testing into their daily workflow. This integration significantly reduces productivity, especially in the early stages.
To minimize these drawbacks, it is mandatory to provide security training for everyone involved in a DevSecOps project. Training should educate non-security members about security best practices and their importance, and also educate security teams about tools and practices in use by the DevOps organization.
Careful use of tooling will also help in this regard—for example, integrating security information and alerts into the Integrated Development Environment (IDE) can help developers learn safe coding skills and make safe choices while coding.
Communication Requirements
In any work environment communication is key, and this is doubly important for DevSecOps teams. When individuals from different backgrounds collaborate on shared projects and schedules, there will be communication failures and disagreements.
Various experts have their own terminology, way of thinking, and expectations. These should be aligned and clarified. Team members should be willing to admit they do not understand a requirement or a system and there should be an openness to share information.
Training can also be important to improve communications. Training courses provided to teams should include an explanation of the current working process, responsibilities and key concepts. By building a unified knowledge base, conflicts can be avoided. Additionally, team members can educate each other to lay the groundwork for the DevSecOps collaboration.
How Imperva Helps DevSecOps Teams
Imperva offers a broad portfolio of security tools and capabilities, several of which are of interest to DevSecOps teams. Imperva can increase application security and reduce risk across new and legacy applications without getting in the way of developer productivity.
Imperva RASP (Runtime Application Self-Protection)
Protects applications from being exploited at runtime, while integrating with tools in the CI/CD pipeline. Imperva RASP delivers increased security without adding overhead to the development process. It reports vulnerabilities in the codebase, and performs ongoing runtime application traffic monitoring to show how attacks are resolved.
Imperva Web Application Firewall (WAF)
Offers defense-in-depth capabilities to the network edge. At the perimeter, the Web Application Firewall solution profiles incoming application layer traffic and blocks any known exploits from malicious clients or botnets. The WAF service is usually installed by operations teams on a ‘set it and forget it’, security-by-default basis.
Other Defense-In-Depth Capabilities
Other capabilities relevant for DevSecOps teams in Imperva’s full-stack portfolio include:
- API security – automatically generates a positive security model for published APIs
- DDoS protection – offering 3-second mitigation SLA against any kind of attack of any size or duration
- Bot protection – protects against all OWASP automated threats and advanced account takeover threats.
