Putting the "Sec" in DevSecOps – Part 1

DevSecOps Panel – What Is DevSecOps & DevOps Security Challenges

Chris Stewart
© Shutterstock / vs148

Since DevSecOps is such a prominent topic as we move into 2020 that we decided to ask five experts their opinions on the subject of security roles being integrated into DevOps. In this first part of our panel series we ask two questions: What is DevSecOps? Where is it easy and where is it difficult to keep an eye on security? Here’s what our experts had to say.

In this, the first of a two-part DevSecOps interview panel series, we look at what DevSecOps is and what the challenges are when dealing with security in a DevOps setup. Check out part two where we talk about best practices, tools and application vulnerabilities. Now, let’s get stuck in!

JAXenter: DevOps has been a term for years when it comes to modern processes in software development, but the security aspect is becoming more and more important. This is often emphasized under the buzzword “DevSecOps”. Dev stands for Developer and Ops for the Operations side. What exactly does Sec mean in your eyes?

Bart Copeland, ActiveState CEO: The purpose of DevSecOps is to create the mindset within the enterprise that everyone is responsible for security. So the“Sec” means adopting security as a key component that’s fully integrated throughout the software development process. That means making security a part of an application’s DNA, starting from initial conception all the way through to release.

The DevSecOps philosophy is that security should be embraced and made better by everyone within the organization. It should also be supported by those with the skills to contribute security value to the system. Security practices have to move at the speed of the rest of development. For example, developers must resolve common open source issues earlier in the software development life cycle, decreasing costs and speeding time to market. This means security considerations are moved up front, shifted-left as much as possible to the developer. In other words, security is baked into the development process.

But does this mean that security is shifted entirely onto the already heavily loaded shoulders of the developer? Of course not. Security is all about protection in depth, from the edge of the network down through the application to the data layers, operating systems, and the people involved. However, it does mean that developers need the tools that can help automate and bake in as much security as possible. Ideally, baking in security at the time the code is written and when architectural decisions are being made.

Robert Ross, Curtail CTO: Both development and operations organizations focus on functionality and availability – sometimes to the detriment of security. Developers may handle passwords in an insecure way to ship the product sooner, or operations may deploy a product with default passwords or without appropriate network firewalls in place. Security may be considered something separate from development and operations activities to be performed by another group. Adding “Sec” to DevSecOps means making an emphasis on security ubiquitous throughout the DevOps process and culture. Providing consistent and trustworthy security guarantees requires attention at every step of the process.

Kaushik Mysur, Instaclustr Director of Product Management: The security aspect of software development has long been a key focus, although its emphasis has been significantly fueled by cloud growth. In the new paradigm of containerized applications built on a microservices architecture, development teams and businesses are taking note of cautionary data breach tales as they continue to make headlines. So, security continues to be an ever-growing focus in software development.

DevOps, whose benefits are grasped fairly easily and quickly, has also seen an accelerated growth in adoption. With DevOps, you empower the dev team to build and deploy applications rapidly with a lot of focus on automation and productivity, in turn making businesses agile and responsive to changing market trends and consumer behavior. However, traditional security measures negate these benefits and are considered a laggard in adopting a DevOps strategy.

From our perspective as a SOC 2-certified managed service provider that helps enterprises develop applications by leveraging container and cloud technologies – enterprises whose own customers entrust them to keep sensitive data confidential – it’s certainly clear that DevOps must incorporate a more omnipresent focus on security, including continuous review and testing, operational monitoring, and the capabilities to respond effectively to any issues. This means building effective security measures iteratively into each stage of the DevOps pipeline with a focus on automation rather than a monolithic security testing just before the software is released.

Gary Duan, NeuVector CTO: Placing “Sec” right in the middle of DevSecOps indicates that security teams are working hand-in-hand with DevOps – implementing security strategies that are well-planned and built-in from the beginning of the development lifecycle rather than bolted on later. At the same time, the rise of DevSecOps is also a response to the need to secure container environments in production, which requires specifically-designed security solutions and even closer cooperation between security and DevOps experts. DevSecOps acknowledges that security must “shift left” to the start of development and “shift right” to safeguard production environments in order to really secure applications throughout their entire build-ship-run lifecycle.

Wei Lien Dang, StackRox co-founder and VP of product: It means that security is now everyone’s responsibility and that the principles and practices that underlie DevOps – automation, faster iteration, and continuous delivery – must also be applied to security. Security cannot be an afterthought, and it must be integrated earlier into the application lifecycle and align with DevOps workflows and toolchains. The adoption of containers and Kubernetes enables this shift because patterns such as declarative configuration of applications, modularity of microservices architectures, and programmatic security controls that are built into infrastructure platforms all make it easier for organizations to increasingly adopt a “security as code” mindset.

SEE ALSO: Speed of deployment: Security, compliance crucial to DevOps success

JAXenter: A development process consists of many parts, steps, and tools. Security should be considered holistically and should play a role in each of these aspects. Where is it particularly easy and where is it particularly difficult to keep an eye on security?

Bart Copeland, ActiveState CEO: The easiest part should be making security a standard consideration during development, something that is thought carefully about before the actual development begins. It has to start at the beginning.

Once development actually begins, it gets trickier. One of the advantages of modern-day software development is access to a vast array of modules, packages, and libraries. These can all extend the features and functionality provided by the core language or framework used to build applications. While this provides great benefits and flexibility, it also brings about challenges when it comes to security. Many of these packages are open source, created by multiple contributors and may not go through a strict security review process. This results in undetected vulnerabilities. Moreover, even if packages have gone through a security assessment in the past, they may contain new vulnerabilities not yet known. And these new vulnerabilities will not be detected by existing tools and processes.

Containers further these security challenges. Although there are many benefits to using containers, they impede open source runtime management. Containers accelerate the good and the bad of open source, in particular vulnerabilities and lack of visible code, into production.

Robert Ross, Curtail CTO: Many aspects of security are fairly easy to address but often get neglected in the rush to get systems working. Avoiding SQL injection attacks is generally quite simple, but developer laziness has created countless vulnerabilities of this category. From an operations perspective, cloud providers offer many tools that make secure deployment easy. Neglected AWS S3 bucket permissions seem to make the news for this somewhat regularly.

In terms of difficulty, we’re seeing containerization as a particularly troublesome area. Containers offer many benefits when it comes to software applications and software testing, but they also bring some drawbacks. They make software delivery simpler and more predictable, because they provide a consistent deployment environment that can be used at all stages of the delivery pipeline. However, containers aren’t immune to the types of security concerns that plague software development. What makes containers particularly difficult to manage security with is that if someone creates an exploit that works against one container, now there will be identical software running everywhere – and it’s going to work against all those containers. The fact that security incidents, flaws and outages can still occur in containerized environments is proof that testing tools don’t catch 100% of issues. In fact, a recent report by Snyk found that the top 10 most popular Docker images each contain at least 30 vulnerabilities. On top of that, if you install any container with an older version of an application, there’s a high likelihood that it will contain vulnerabilities.

SEE ALSO: Fugue open sources Regula, security and compliance tool for Terraform

Kaushik Mysur, Instaclustr Director of Product Management: I’d argue there is no such thing as “easy” when talking about security. Security is hard to implement, hard to track and monitor, and hard to enforce. No matter how secure applications are, there are always gaps for people to exploit. The most secure thing built a few years ago is probably no longer secure today. As long as innovation thrives and new technologies, frameworks, and platforms continue to be born, the threat vector continues to expand – making it harder and harder to keep pace. For instance, today’s containerized applications built with several loosely coupled microservices have way more threat vectors and vulnerabilities than a traditional application. So, technology teams have started investing more time and effort into building security in such applications as it is new and more difficult to achieve. In due time, we will probably hear fewer security concerns around this; but then a new way of doing things will pop-up and the cycle repeats.

One constant area where keeping an eye on security is particularly hard is changes to application, as each change invites vulnerabilities and security risks. Therefore, a policy of careful application code review and testing is essential to identifying those potential risks. Automated test suites help here and if integrated into the CI/CD pipeline, it minimizes the risk of untested changes making their way into production.

Another challenging area for DevSecOps is network security. Enforcing security in a multi-tenant deployment is harder than when deployed on dedicated resources. Enforcing security for applications with public IP is tougher than when deployed in a private network cloud. Again, as new ways of deploying applications come up, they will each need serious investments in time and money to ensure network security is enforced in that new environment.

Gary Duan, NeuVector CTO: It’s fairly straightforward to scan images for vulnerabilities, even in a rapid deployment environment. But in production enterprise environments often include hundreds or thousands of containers and services, with containers dynamically born one second and gone the next. This is, of course, much quicker than any manual security process could hope to address. It’s also the case that attacks on container environments seldom leverage a single exploit, but instead will escalate their impact through a “kill chain” series of actions within internal container traffic.

Whereas protecting containerized environments from external network attacks is arguably an easier challenge, because securing external traffic is well within the capabilities of traditional firewalls, internal ‘east-west’ container traffic security is much more complex. Securing the “micro-perimeters” around all containers and services within a container environment requires automated tools capable of providing the visibility it takes to recognize and thwart insider and zero-day attacks escalating in real-time.

Wei Lien Dang, StackRox co-founder and VP of product: In my view, it is relatively easier when it is a technology problem that can be addressed with new solutions or tools. The aspects of security that rely on organizational alignment, collaboration between people, and repeatable processes are more difficult to effect. This is why DevOps and DevSecOps is as much about culture as it is about how development and operations are implemented. The emergence of cloud-native architectures and technologies, which often require organizations to reevaluate their existing development and operations practices, can be a driving force to hone in on how areas of security can benefit from an approach more aligned with DevOps.

Thanks very much!

Chris Stewart
Chris Stewart is an Online Editor for He studied French at Somerville College, Oxford before moving to Germany in 2011. He speaks too many languages, writes a blog, and dabbles in card tricks.

Inline Feedbacks
View all comments