DevSecOps and the idea behind
DevSecOps is popular among companies who value security and compliance. Some understand the idea earlier than others, some don’t until there is an incident. A lot has been said on the topic but it still confuses people, especially people who think DevOps is the same and there is no need to put the Sec in the middle.
We disagree because we believe we need to talk a lot more about security and other related topics to be able to protect our business and get ahead of the competition. This blog post is a starting point for our continuous effort into making security and compliance easier and safer for everyone. We first want to explain what it is, how it is related to DevOps, and name the practices that make DevSecOps possible.
What is DevSecOps?
DevSecOps extends the DevOps name, a decade long movement that brings devs closer to ops and ops closer dev. The idea behind DevSecOps is not different from DevOps but its main focus is. DevOps is about creating a culture of shared responsibility with the help of proven practices and supporting tools. Due to its name and origin story, it focuses on breaking down the invisible wall between ops and devs. DevSecOps on the other hand puts the security aspect at its core and wants it to be a first-class citizen for everyone.
Is it just Security? ie. What about compliance and risk management?
Security is a broad name. Compliance and risk management are not separate entities. They are all strictly related. Companies that invest in DevSecOps get benefits for compliance and risk management. For example, policy as code represents automation practices (which we will cover in detail in another blog post soon) that would benefit both compliance and security.
Can we think of DevOps as a prerequisite for DevSecOps?
Yes, you can. DevOps is about culture, practices, and tools. All three aspects are critical to each other. The DevSecOps promise is to make Security everyone’s job. This is only possible with the right culture, practices, and tools. DevSecOps extends DevOps. Without the building blocks from DevOps, security won’t be part of our delivery pipeline and continuous learning practices.
Shift left is another common terminology many people use when they explain DevSecOps. It means that security talks should move to an earlier stage in the development cycle. This is only possible if security raises on top of a giant like DevOps.
Important practices for DevSecOps
Automated policy and compliance checks
Automation is a broad term. Infrastructure as code (IaC) is the first to come to mind. DevOps reduces dependencies and failure points using IaC with disposable and repeatable infrastructure. The ideas behind infrastructure as code can be extended to compliance and security. Terms like “policy as code” or “compliance as code” are getting popular day by day because automation makes many manual checks much easier and more importantly less risky. We will talk about these ideas and how we, at Resmo, help our clients with security and compliance automation.
Security tests in delivery pipelines
Continuous integration and delivery pipeline (CI/CD) is the bridge between dev and ops. When Security is on that bridge, it is able to reach out to both sides. Some security tests and checks should be run on each commit. Application security is very suitable for these checks as they frequently change and faster to run. Of course, security is not just about the application itself. It is also about your cloud infrastructure, repositories, single sign-on system, user behavior, and more. The idea is to tie whatever makes sense to CI/CD pipelines to secure and check for compliance on every change.
Compliance and security monitoring for apps and resources
Monitoring or another popular term Observability are not just here to optimize performance and minimize downtime. Application performance monitoring, collecting logs and traces help with identifying changes to code and its behavior. Nowadays with the increased number of tools in our DevOps chain, we need to monitor resource configuration changes. Cloud itself is a huge asset that needs detailed monitoring. Combine that with Git repositories, CI/CD pipelines, single sign-on, DNS registry, CDN, chat tools, and many others. Your system has many points of change. Many ways to fail. You can not just trust that everyone in your company would use all these complex tools and services the right way. This is important for DevSecOps and DevOps because empowering developers means giving them more freedom. Without automated compliance security monitoring, it is almost impossible to find out what may be dangerous before it becomes an incident and find out where the vulnerabilities are.
Continuous learning embedded in daily routines
Security and compliance training usually sucks. Almost everyone wants to just get over with it. Some find tricks to skip forward, some have to listen for a few hours to answer some basic questions. If we need to create security awareness, we need to make these training embedded into our daily routines as small bits and get rid of unnecessary, automatable bits. This is an often overlooked aspect of DevSecOps but it is important because there will always be a human aspect of security.
In our first blog post on DevSecOps, we talked about what it is, why it is important, how it is related to DevOps, and mentioned some of the fundamental practices for DevSecOps. We tried to keep things concise as we explained what and why. In future blog posts, we will write more on the policy as code, compliance as code, and definitely resource configuration monitoring.
Sign up for the Resmo early access program and follow us on Twitter to learn more about how we help with DevSecOps teams and get regular updates!
