DevSecOps: Robservations from Black Hat 2018

One of the nice things about my new role is that I recently had the pleasure of attending my first Black Hat conference. Now to be completely transparent, I only had an exhibitor pass and I was there primarily to support networking and interactive activities at a booth, but even with those small limitations it was obvious that there is a LOT of interest these days in cybersecurity and myriad options and opinions available. Out of that, there were two big “Robervations” I took away from the few days that I spent there.

Everyone Recognizes the Need for Security as a Part of DevOps (DevSecOps)

While not everyone was using the term “DevSecOps,” some form of it was all over the discussions that I had. Whether it was with various attendees or vendors, the notion of addressing and accounting for security needs earlier in the application development life cycle is something everyone agrees is paramount to business success in today’s marketplace. Most vendors also had some form of this displayed prominently in their signage and/or present in their documentation. It’s clear the industry recognizes how important this is.

However, while many have adopted some form of DevOps methodology, the reality is the greatest barrier to achieving DevSecOps remains the culture of the organization, with most having security teams still essentially operating as a separate silo. Add to this that it is not realistic to expect developers to become security experts and anticipate cybersecurity needs as part of their day-to-day work, and we see that there is still a lot of opportunity for improvement. For these reasons, having more tooling that allows for security requirements to be incorporated as an integral part of the application conception and design process—in the same way that features and functions are handled—is critical. I expect to see more tooling that supports greater collaboration and takes advantage of both natural language and also cognitive capabilities to provide deep learning and best practices for incorporating security aspects into application requirements.

Make It Easier for Developers to Test Security

One of the more interesting discussion topics in the cybersecurity space today is around the role of the developer within it. And especially where DevOps is concerned. Ask several people what the goal of DevOps is, and you will likely hear various expressions of automation that allows for greater development speed while maintaining a high level of quality—all resulting in a shorter time to market. And while that all that is true, isn’t it also true that the real goal of DevOps is rooted in successful business outcomes—that the reason to do DevOps isn’t so much about just going faster, it’s about providing the best customer experience possible as soon as possible? And today, containerization, microservices, machine learning and AI are a big part of that experience.

Bearing all that in mind, then, the role of the developer has in that process has never been more important. And developers themselves are realizing the impact of their influence. In fact, the recent “2018 Stack Overflow Developer Survey” indicated that nearly half believe “that the creators and technologists behind the machine learning and AI algorithms are the ones who are ultimately most responsible for the societal issues surrounding artificial intelligence.”

So, how do you help developers, who are not security experts, be able to better handle security vulnerabilities and risks as they are developing? You incorporate security testing into the same delivery pipeline they are using as part of their DevOps approach. And this can be done in several ways. For starters, a great idea is to perform quick static code scans at the time of check-in to identify obvious issues while they are still in context of what the developer is doing. This is same idea as running unit and functional tests and is especially helpful if your teams are following DevOps best practices and coding against a production-like environment. Beyond that, incorporating security testing as part of continuous integration and continuous delivery processes will allow for greater overall feedback sooner, when they are easier to remediate.

Thanks for reading these “Robservations.” If you would like more information on these or other topics, I encourage you to visit the other parts of this Security Boulevard site, where you will find news, series, articles and more across every aspect of Cybersecurity. You can also visit the IBM-sponsored Security Intelligence site and connect with me on social media.

Featured eBook
The Four Current Threats Enterprises Can’t Ignore

The Four Current Threats Enterprises Can’t Ignore

The changing digital landscape of data and devices is creating a perfect storm of opportunity for cybercriminals. Enterprises today are prime targets, as more users access more data using more—and more varied—devices. In particular, enterprises today must contend with issues including ransomware, IoT security flaws, DDoS attacks and managing mobile devices on the corporate network … Read More