DevSecOps: what is it and what should we do?

Why should I think about this? 

Devops is a mindset – a cultural thing – just as much as it’s a way of doing business. It merges your development with your operations, creating a way of implementing change and growing rapidly. But is it enough? Are you already doing DevOps but adding security into the mix might seem challenging? You are not alone. 

DevOps is meant to build a bridge between dynamic, stormy and agile development and calm and still waters of operations, build operational capabilities to cope with the ever-changing landscape and requirements of development. DevOps shares the responsibility of running code in production environment. 

DevSecOps (Development, Security and Operations) stems from the ideology that security cannot be added afterwards or bolted-on into a product or system. Security must be considered from day one and should be intertwined and an essential part of the development culture and operational procedures. See where I'm getting at, security is not something you stamp on a product or sprinkle on top of. Security should be one of the key pillars and quality gate from day one. So, we call it DevSecOps. 

The hard part: people & culture 

The hardest part of the DevSecOps evolution is the people. Throughout the history of software development, quality and security has often been seen as an external function – responsibilities that belong to that infamous “someone else”.  

Embracing and managing the change from development-oriented organization to ownership-oriented can be a difficult task but helps your organization to span across different silos and mental barriers. 

Implementing DevSecOps means that your developers need to embrace security and see it as an integral part of their work. You need to have your development team understand the baseline of security and have them develop and implement it. You need to consider “alert fatigue” and having your CI/CD pipeline working with limited disruptions. One good idea is to have “security champions” in your development team – people who become the “go to” for all security related questions.  

How?  

Security as a function needs time and money, simple as that, and what I mean by that is security need sponsorship and commitment from the top. The understanding and mandate to build secure products must flow down from executives. 

Spending time and money on security will pay back in the long run. Which is nice. 

Introducing security from day one starts from: 

• Coding standards and reviews 

• Automated linting and documentation 

• Managing 3rd party dependencies 

• Standardized incident management and retro culture 

DevOps often demonstrates itself as a set of automated development and deployment processes called CI/CD. Simplest way of getting into DevSecOps as a technical ability is to start adding security considerations into your pipelines: 

• Automated code analysis and security testing 

• Measure and gate 

• Keep it simple, stupid 

Understanding shift left and right 

"Shift left" is a term that in DevOps refers to a practice where team focuses on quality and work towards preventing issues instead of detecting them post-mortem. 

With DevSecOps "shift right" is somewhat equally important since most attacks and security incidents happen in real time, as we speak, in live production environments. So: 

• Monitor, seek for anomalies 

• Automated penetration testing 

Real world example 

The main reason why we care about security are the risks it poses to our operation and business. To mitigate appropriate threats, it's advised to perform a security risk analysis to identify assets and their relative value, sensitivity and importance to the organization. 

Based on the analysis, focus your automation effort where you achieve highest risk/cost impact. Many features of modern DevOps; high abstraction cloud services, infrastructure as a code paradigm, security policies and microservice architectures offer higher security just by adopting the technology. 

Baking the security built-in into the product and processes is not an easy task, but can be achieved with gradual, iterative steps, like the agile development process in general. Showcase your security functions in the same repositories and infrastructure as a code templates as rest of the operation, measure and monitor. 

So, what does all this mean in practice? Here is a real-world example from one of our customers, running a container based in-house coded application with multiple deployment cycles per day. Our primary goal is to validate and emphasize the importance of code quality in the end product. The creative coding process on the “left” is recognized as the phase with most human involvement and latter phases of deployment are automated with conventional means of DevOps. 

Here's a simplified diagram of their CI/CD process (the “shift left” side of things) emphasizing the integrated security features, including: 

• AWS CodeGuru integration to GitHub and pull request process 

• OWASP dependency analysis 

• SonarQube bug and vulnerability analysis 

• AWS ECR Container Image Scanner 

To summarize, get empowerment from the top, keep things simple, start small but enforce and keep talking about security.