Cloud Native
Analyzing DevSecOps vs. DevOps
Learn the difference between DevSecOps and DevOps and get tips to smoothly embed security throughout the entire build lifecycle.
Save to Folio
If you didn’t have the chance to join us at CloudSec, you can watch the full session, DevSecOps Analysed, here. Keep reading the explore the principles discuss.
What is the difference between DevSecOps and DevOps?
DevSecOps and DevOps are terms you’re most likely familiar with and they’re often used so interchangeably you may wonder if there’s an actual difference. DevOps walked so DevSecOps can run. Or, in plain English, DevOps was the starting point for integrating teams to encourage agility, but development teams quickly realised this didn’t address security teams, so they added security to the mix and coined this DevSecOps.
Now you know the difference regarding definition. Not to be all philosophical—but should there be a difference? DevOps should include security everywhere at any time. Saying you have a DevOps approach is almost like saying you open your mouth to eat but call it a fancy term like “food-breathing.” So, let’s put the term DevSecOps to rest, and embrace that DevOps means security in integrated into the development process.
Are you doing DevOps right?
Adding security into the development process is a good start, but is it enough? Most development teams add security into the final phases of the flow but testing for bugs after production is not ideal—it increases the likelihood of a breach, and it costs more to remediate. Also, it keeps security teams siloed from the entire build process yet they’re still fully responsible for anything security related. Sounds counterproductive, right?
It’s like eating Pad Thai and then asking the chef if it has any peanuts because you’re allergic. It’s too late now—you’re swelling up like a balloon and the chef is panicked trying to stab you with an EpiPen and call the ambulance. If you had asked beforehand, he could’ve double-checked his recipe and cooked you a tasty, peanut-free dish.
Ideally, you want to integrate security into the entire flow. It should be practised from ideation to planning to coding to testing to deployment. Below is the classic DevOps diagram with security embedded throughout—aet voila, you have “DevSecOps” aka proper DevOps.
DevOps is especially important as more enterprises move to the cloud. With development and deployment speeds rapidly increasing, integrating security “checkpoints” throughout the build lifecycle ensures you can quickly ship secure projects.
DevOps shared security responsibility model
It’s usually recommended to “shift left,” meaning implementing security as early in the build process as possible. This is much better than tossing security in at the end of the flow, but remember security needs to continue throughout the development stages. Also, let’s clarify that when we talk about embedding security, we don’t just mean tools.
By integrating security throughout, you’re removing the siloes between development and security teams. Everyone needs to play their part throughout the build lifecycle. Below is a diagram of how each role is responsibility for security:
You may be wondering, if we’re all sharing the responsibility, do we even need a designated security team? The answer is YES. Security teams are still responsible for very important tasks like pen testing and using their expertise to establish best practises and guidelines for developers to abide by. Security professionals are the experts, it is their job to guide and support development teams across the build lifecycle, so developers can focus on their expertise—building great modern apps.
Tips to inject security into your DevOps practises
To get the most out of your DevOps practises, it’s important to inject security into the pillars of DevOps. There’s some debate about how many pillars of DevOps there are, but essentially it all boils down to people, processes, and products. Let’s review each pillar and how security can be applied.
PEOPLE
Many organisations think DevOps is all about tools, but in actuality, strong leadership and culture are vital to its success. Gartner research found that through 2023, 90% of DevOps initiatives will fail due to the limitations of management approaches used by leadership.
Shifting to the “assume breach” mindset
Seems impossible, right? In his CloudSec 2021 session, Microsoft DevOps Architect Davide Benvegnu, discussed how his engineering team (focusing on Microsoft Azure DevOps) changed their mindset. They started with two teams: the red team focused on hacking/penetrating the environment while the blue team tries to identify and remediate risks before red team is successful.
Eventually, Benvegnu’s team soon realised this wasn’t the most effective approach. Instead of playing “catch-up” with the red team, they eliminated the blue team and spread its components across each feature team, completely shifting security left.
Now, each feature team is responsible for the security of the product. To ensure their tasks were completed security, they leveraged security tools with automation to help prevent common risks like credential theft, secrets leakage, and open source software (OSS) vulnerabilities. Also, developers learnt to write secure and reliable code and write the tests to check for security vulnerabilities.
PROCESS
Establish security practises throughout the entire process
If the teams don’t buy into the mindset and new approach, they will be less likely to actually follow procedures. After everyone is on board, you can effectively implement security practises throughout the build lifecycle.
For example, when you open a request, you run and security scan and block any pull requests if vulnerabilities are present. Next, run the same vulnerability scanning in the CI/CD pipeline for anything pushed or merged. Set up fixed interval scans to check the code base, even if nothing was pushed or committed, just in case you decide to use it later. Finally, deploy only after all security tests are passed. Ideally, deploy across multiple stages with release gates to test for security, not just functionality. Progressive exposure helps identify and fix vulnerabilities as quick as possible.
Treat “security work” like it’s normal work
This will help developers become more familiar with security and remediation tasks and incorporate it into their everyday workflow. Of course, there will be exceptions for critical incidents like Apache Log4j (Log4Shell).
PRODUCTS
Similar to how process is only effective when backed by people, security products only work well if they fit the specific needs of your process. For example, you need to perform regular code reviews, but manual cheques slow down build time, and agility cannot be compromised. Solution: tools with automated scans and configuration cheques remove the burden of manual review so developers to build quickly and securely.
Get specific with what tools are needed for your technologies and services. If you’re developing with containers, select purpose-built security products for container image and application scanning. This ensures no vulnerabilities are in your hidden dependencies and all security policies are respected.
Next steps
To summarise:
- DevOps should inherently include security, rendering the term DevSecOps obsolete
- Security should be embedded throughout the entire development lifecycle—not just the final hurdle before deployment
- Inject secure practises into the three pillars of DevOps (people, process, and products) for best results
