arrow-down coffee engineering consultancy development remote-management support linkedin twitter youtube email phone gitlab github

An introduction to SecOps

Submitted by Marcello Evangelista on February 16, 2018

One of DevOps' focus is software development and delivery, ensuring clear communication from one stage to the next. In particular, there is a great focus on collaboration between the development and operations teams within the company.

A primary goal is to reduce the time needed to launch new versions of software through faster development cycles and increased application stability.

This so-called "continuous delivery" DevOps philosophy is already implemented by great players around the world. Amazon, Netflix, Google and Uber have all benefited from more DevOps-like workflows. They have moved away from traditional, long development cycles that rarely involved any operations personnel.  It is worth noting here that DevOps isn't just about the  application codebase.  It is about the whole environment responsible for hosting the software, application and business performance, and ensuring little to no negative impact to the final customer.  Some development cycles could be dedicated to other areas beyond the application codebase.

At first glance for Information Security traditionalists, DevOps is something that makes code audits and standard security pre-checks harder.  These are traditionally performed in the time between development and production - but that time frame is constantly shrinking.  DevOps is here to stay, so how does security fit in? How can we automate while ensuring that a security standard is delivered both at the application and business level? Where's my coffee?! These are all questions that may be lurking in your mind.

DevSecOps, it's a thing!

Enter SecOps

The DevOps cycle is a great opportunity to integrate security into the core of an application. Instead of passing through a "final  checkpoint" before a big release, compliance and best practices are verified continuously throughout the application lifecycle.  This
practice is often referred to as "SecDevOps" or more commonly "SecOps".

The first step to bringing security into the DevOps cycle is to include security as one of the main stakeholders of a project. There's no need for anything special yet; use the same methodologies from well-established standards.

Next, implement security as early as possible to ensure a faster audit process and a lesser impact on the development cycle. Combining security and operations is a solution for faster, safer deliveries with a narrow scope of vulnerabilities.  It's a beautiful thing, like leaving for the weekend with the certainty that your last release wasn't packed with failed security tests and breaches.

OK, How Is This SecOps Thing Actually Done?

Design Your Security Blueprint

Research the technology stack - both development and infrastructure and note known vulnerabilities.  Work out how to remediate them. For infrastructure, research best practices for the application environment, including servers, services, configurations and providers.  For development, map out the critical code.  Check how authentication and sensitive information is being passed around inside the application. Check that your back-end is treating information properly. Take a look at the language's guide for best practices of code and security frameworks, something that almost every language has nowadays.

Bring your devs closer to security

This goes beyond just using a Security team to point at the code's weak points and performing cold analysis. Bringing developers closer to security is about sharing knowledge of the importance of security to the entire business. It's about enabling developers with the power of security wisdom.  There is a wealth of content on this topic.  OWASP is a great place to start since it enumerates the main vulnerabilities in web applications.  Schedule sessions with both the security and development teams for case studies and the next security goals.

Use the right tool for the job

Using frameworks and other relevant tools immediately following code check-in helps to avoid some of the most common security issues. Auditing at such an early stage ensures a shorter time to a true production-ready state; vulnerabilities weak code points are eliminated before deployment.  This exposes the application and the company to less risk. Some examples are OWASP python Security, HTML Purifier, Apache Shiro etc.

Constant checks == Constant security

Vulnerabilies will always exist.  One of the first mantras that we all learn in security is: "If you make it, someone will break it". Integrating deeper security tests such as penetration testing, breach simulation or even a code review will ensure that teams are on top of what could happen and encourages preventative behaviour. Using a partner company, like us (shameless plug) to put your application and internal failure processes under stress is a great idea. You'll get a peer-review of internal policies and test how solid your teams are under the pressure of a breach.


Leveraging security in your teams and using it as a way to constantly deliver a better product will significantly reduce all weak points not just in terms of security.  Increasing communication between Security, Development and Operations teams is crucial to create better and safer ways of product delivery and achieving real business value.

Security isn't a step, security is a road.