DevSecOps has been a hot topic within tech conversations for a few years now. The idea isn’t new.
But what has changed is the role that DevSecOps plays in software delivery. When DevSecOps emerged as a concept, it was seen as a way to make security better, but not necessarily as an essential component of a healthy CI/CD chain.
That is no longer the case. Today, DevSecOps is not optional. It’s a must-have if you want to keep modern application delivery secure at all. Let’s take a look at why.
Defining DevSecOps
As you may already know, DevSecOps is the idea that everyone, no matter their job role, is responsible for security. The driving concept behind DevSecOps is that you can and should be able to empower a developer, a DevOps engineer or a network engineer (for example) to make security-based decisions without sacrificing the security of the application or project they’re working on, and allow these decisions to be made quickly so as not to stifle productivity.
So, Why Isn’t DevSecOps Optional?
In many businesses, DevOps as a concept, is being embraced heavily—and application developers, alongside operations engineers, are being forced to be agile in their approach to development, deployment and interoperability. With this comes a requirement for a crossover in skills for engineers that allows them to not only understand what other teams are working on, but also in some cases to contribute to the work.
Full-stack engineers tend to be a good example of this sort of mindset. (The age-old phrase jack of all trades, master of none comes to mind.) One of the trades a modern-day DevOps/full-stack engineer needs to be familiar with is security.
Achieving DevSecOps
So how can a typical software engineer gain the security skills he or she needs to do DevSecOps effectively? Let’s take a look.
Be Collaborative
In the past, it was often the case that people would pigeonhole themselves into a specialty or job role and others were scared to get involved (because it was something they were unfamiliar with), or it was simply the case that the culture of the company they were working for wasn’t geared up to support them.
Identifying security risks and vulnerabilities requires collaboration between all the different elements and people that ultimately bring a new product or service to the fore. Again, this doesn’t mean that the person in question should be a master of all these skills, but it’s useful to have an understanding of them.
An example of this would be an operations engineer working with a developer to identify a security vulnerability in their application—and likewise, a developer working closely with an operations engineer. Indeed, with open source software at the forefront of many businesses, it’s useful to not only have an understanding of deploying it, but also patching it if you identify issues along the way.
Share Information
Like collaboration, sharing information is of key importance when it comes to security.
If, for example, you happen to have learned of a new vulnerability, then by all means share it with others. Be open and show an interest. This communication will allow all parties to move forward in fixing a problem, and will contribute to the learning process of all involved.
Monitor Proactively
Another way in which you can transform yourself from a DevOps engineer to a DevSecOps engineer is by proactively thinking about security when designing any monitoring system you’re putting into production. A start could be as simple as building checks in your monitoring service to monitor systems for important security updates and alerting staff that they need to conduct patching. This could also be using SIEM to monitor application logs and build alerting dashboards on failed login attempts, patterns matching DoS/DDoS-based attacks, and so on.
Security-as-Code
That brings us to another point: The concept of Security-as-Code. If you’re reading this, then odds are you’re familiar with the likes of Ansible, Puppet and Chef. These allow you to define infrastructure in files and form what we know as Infrastructure-as-Code.
If you’re doing the above, then you’ll know that in many cases (such as when using AWS) you will most likely have to define in your code what security groups you would like to create, combined with the services you wish to expose. This requires some knowledge of networking, along with an understanding of the implications of opening up a “hole” from the outside world into your application or network.
You could also write automated checks using security tools such as NMAP which will scan newly deployed servers to see what ports are open and will fail if ports that shouldn’t be open have been found to be exposed.
Use Relevant Toolsets
Use relevant tools when thinking about security. For example, Twistlock has continuous integration tools that plug right into your existing CI/CD pipeline system (Jenkins, for example). This can allow you, with relative ease, to set thresholds for security and compliance, including HIPAA, PCI, CIS Benchmarks, and do this within the build itself. You could go on to set policies that alert or block unsafe builds with custom alerting and guidance on what to do next.
Similar to the above, utilizing security services with APIs that always provide up-to-date information are far more effective than sticking to arbitrary guidelines written in a Wiki somewhere (that may become outdated very quickly).
Conclusion
The importance of DevSecOps can’t be overstated. As nefarious individuals become more clever at finding vulnerabilities in software and hardware, so too must IT professionals adapt to the changing landscape. We need to be agile in our approach to security and act collectively in addressing the issues going forward. Doing so will reduce the attack footprint on services we ultimately deploy and give us all a better understanding of security.
DevSecOps is not only a mindset change but one in which those responsible should be provided with the correct tooling and guidance to put security at the forefront of their business decisions. DevSecOps engineers offer enormous value in that they can continuously evaluate security in their day-to-day work and take action when they identify a problem. It also takes away the reliance on a separate security team or singular security engineer in a wider DevOps team who may not have a complete view on a piece of infrastructure or recently developed application.
Finally, for this mindset change to take place, it’s key to involve decision makers at a high level in the business to get their buy-in and understanding of the importance of DevSecOps.
