DevSecOps Definition
DevSecOps is short for development, security and operations. It is a software development model in which these three teams work in close collaboration and in a synchronized fashion. One may say that a DevSecOps team is an agile, cross-functional DevOps team that embeds security practices into their own processes to deliver secure software products and digital services. In other words, DevSecOps is DevOps done securely.
The intent of DevSecOps is to make everyone accountable for security while still operating at the same speed and scale as DevOps development CI/CD pipelines. Adding application security to DevOps is a major challenge because security practices are becoming a "bottleneck" for software development assembly line. However, as cyber threats continue to grow, secure software development processes have never been more important.
The solution is to reimagine and rebuild security practices integration into DevOps.
Security is meant to be an integral part of DevOps because of security practices such as secure design, code reviews, automated testing, penetration testing. In real life, these detached DevOps security practices cannot provide security, although they could help. DevOps teams should adopt a security mindset and apply security principles to their day-to-day agile activities.
Today software is released in short sprints and it becomes essential to perform application security testing during development cycles without slowing down the engineering processes. Ideally, security activities should be started as early as possible during the software lifecycle – we call it a security “shift-left”.
DevSecOps model brings together DevOps and continuous security testing.
DevSecOps ensures that developers think about security when they create a design of a system, and when they write code, that software is tested for security problems before it is deployed. Also, that development teams have a plan in place for addressing security issues quickly in the event that they appear after deployment.
DevSecOps Structure
DevSecOps can be defined as a combination of technology, processes and people. It’s indeed people who form Dev, Ops and Sec teams. These teams follow agile principles in their day-to-day work. Professionals from all three teams use technology tools and work in accordance with defined processes.
Technology
DevSecOps technology overall would include application, data, and infrastructure security. In this article we are focused specifically on application security.
Application Security (AppSec) focuses on making software more secure by applying secure design principles to created applications by testing, finding and fixing vulnerabilities in code, and by protecting the applications during the deployment phase.
AppSec helps development and security teams become more efficient and scale DevSecOps through automation, integration, and collaboration so they can continue creating innovative applications. DevSecOps means taking a programmatic approach that focuses on continuous AppSec integrated seamlessly into DevOps.
Nowadays, the application security toolchain is mainly focused on testing. That’s why the term Application Security Testing (AST) is in use to cover most parts of the technology areas (types of security testing) from the list outlined below. Each application security technology area is called an application security practice. All practices are divided into three groups– AST, Orchestration and Correlation, and Application Protection.
ASOC stands apart from all other items in the table above because its goal is to orchestrate all types of security testing and to correlate and group collected findings together.
RASP and WAF provide additional levels of protection when the application is in a production environment. The intent here is to defend applications from attacks in real time whereas AST focuses on identifying and removing vulnerabilities in the application.
Process
An integrated process needs to be implemented where the security engineering team can easily execute application security tests, identify security defects, pass defects to the Dev team, validate that the fix is correct, and close the fixed ones.
A Secure Software Development Lifecycle (SSDL) process assumes necessary changes and limitations of the existing software engineering process. Procedures, regulations, requirements, and standards of secure software development should be documented, published for all key stakeholders, and reflected in the company’s policies.
Organizational and technical measures for a secure software development process should be used. Implementation of best practices for secure software development transitions into continuous process improvement. Quantitative security metrics and KPIs need to be defined, documented, and measured.
People
Creating a Software Security Group (SSG) is one of the key components of organizational readiness for DevSecOps. SSG accumulates and disseminates knowledge across the organization and defines new roles and responsibilities for management and the required technical experts.
The software engineering industry struggles to find enough quality security resources to support the growing scale of software engineering. Therefore, finding members of your company who are open to focusing their careers towards security is critical to the success of the DevSecOps transformation. Glenn Wilson (see detailssee details) calls these people Security Champions. They will help other team members improving the security of software products/services they build.
Members of software development teams, security teams, and other stakeholders involved in the SSDL should be trained on procedures, regulations, processes, requirements, and standards of secure software engineering.
Secure Software Engineering Culture
There are tools and processes that can help you evolve to a DevSecOps organization. But ultimately, DevSecOps is a culture that matches the four principles of building security into agile development as declared in the Agile Security Manifesto (see detailssee details):
1. Rely on developers and testers more than security specialists. Security shall be owned first and foremost by the software team that works on software development.
2. Secure while we work more than after we’re done. Security shall be built into the existing process of daily development and testing performed by the software team.
3. Implement features securely more than adding on security features. It is preferable to involve experienced professionals to implement specific security aspects inside the software, and do not expose security features to the control of the end user.
4. Mitigate risks more than fix bugs. Just fixing security bugs is not the right approach to security. We shall be focused on risk management and minimizing the business and users’ risks.
Engineering-led software businesses are shifting their working culture towards applying their security expertise as code for everyone’s benefit.