How to transition into DevSecOps

Many of us have been living the DevOps life for a while now. We no longer just write the applications and leave the rest of the lifecycle to others. We’re integrated into the entire process of getting applications to production and beyond. And this has provided great benefits to our customers. We’ve found a way to get features out faster and to fix defects quickly when something slips by.

But what if the defect that slips by is security related? Are we prepared? Do we have the tools we need to make sure we’re doing all we can from a security standpoint?

For many of us, the answer is “no.” And it’s nothing to be ashamed of. It took us a while to get our DevOps groove on, and now we’ve realized we need to go further. We need to shift our security left in the application development lifecycle. We need security integrated into the whole process.

But where do we start? What’s the best way to get value out of DevSecOps without being overwhelmed with all that we have to learn?

In this post, we’ll talk a bit about the state of DevSecOps as it is today. And we’ll look at ways you can start incorporating security into your DevOps pipelines and processes. But first, let’s look a bit at ourselves.

State of our DevOps engineers

We are overwhelmed. For most of us DevOps engineers, we review and maintain infrastructure, manage the CI/CD pipeline, expose metrics, create automated tests, and incorporate design and usability into our decisions. And now we need to bring security into our domain. We need tools and knowledge to make the right decision. And we need things to be easy—or at least doable—with our current workload.

So why are we also taking on security?

Not only do we need to incorporate security to protect our customers, but we also need to protect ourselves and our organization’s reputation. And it’s not bad for the bottom line, either. You see, as with application defects, the earlier in the application lifecycle we find security vulnerabilities, the cheaper they are to fix. And for vulnerabilities that do slip by, because some always will, the faster we can detect and remediate them, the better off we are.

State of DevSecOps

Next, let’s look at where DevSecOps stands today.

We’re still working to spread the word. We encourage companies to shift left and incorporate concepts like zero trust into our vocabulary. And the number of companies either providing tools or training in this space grows every year.

And why is that? To start with, security traditionally has been hard. It’s been an afterthought. It’s what we look at two weeks before our big production deployment, hoping that the security folks down the hall don’t find anything too horrible.

Also, management and the C-suite have realized that security needs more focus. It can’t all just be about shipping features out the door. Today’s consumer wants security as a base feature. And we need to find a way to make that happen.

First steps toward DevSecOps

Now that we know where we currently stand, let’s take a look at how to integrate security into our DevOps world. Let’s learn to embrace DevSecOps.

Create an environment based on trust

Security concerns and vulnerabilities can be a scary thing. Teams may be hesitant to bring up problems or incidents out of fear of the repercussions.

We need to create an environment of trust where we’re all working together. Without this trust, glaring security holes might not be discovered, mentioned, or scrutinized.

Acknowledge that we’re all working toward making our application ecosystem a safer and more reliable place. And by sharing the shortfalls we’ve discovered, the whole organization can grow in its security knowledge.

Trust also requires transparency.

So if you’re hiding what you’re doing as a DevSecOps professional, know that you may erode the trust that others have in you. So track your results in the DevSecOps journey and share the results, good and bad. Provide engineers visibility into what’s working, what’s not working, and what we’re making better.

Enhance the CI/CD pipeline and automate security

DevOps discussions almost always start with automated integration and deployment. And we’re going to jump in there with DevSecOps fairly quickly as well.

As part of your first steps toward DevSecOps, find ways to incorporate security without creating a lot more work for yourself or other engineers. So when you add tools like SAST, ASM, and SCA to your pipeline, do it in a way that lets all your development teams reap the benefits without having to put in all the toil.

You see, many companies add requirements around adding tools like SAST and SCA, but don’t provide the tooling or infrastructure to make it easy.

So then you end up with team after team re-learning the same thing, making the same mistake, and struggling with adding things into the pipeline that should come out of the box.

Instead of falling into the same trap, use tools that can seamlessly integrate with your current CI/CD pipeline, and that can help you automate security protection, at all stages of your CI/CD pipeline, from development to production. Create templates or scripts that make security scans more difficult to take out of the process than it is to add them. Enhance your pipeline for security by making the secure action the default action.

Consider your infrastructure

Next, let’s look at infrastructure. When engineers are on the hook for updating their own application infrastructure, things will fall through the cracks.

However, if our infrastructure automatically updates, patches, and upgrades dependencies, we’ve just freed up time on our DevOps plate to get features out the door. Additionally, if our infrastructure can be deployed in much of the same way as our applications, then we can react to security incidents faster by replacing compromised VMs quickly and consistently.

So don’t just stop after automating applications with DevOps tools. Look at infrastructure as well. And then incorporate the Sec in DevSecOps to make sure you’re ready when problems arise.

Build your DevSecOps knowledge

With knowledge comes responsibility. And without knowledge, we still have accountability, but not the judgment to make good decisions.

But keep in mind that everyone can’t be an expert on everything. Focus your training so that everyone gets a good base of security knowledge. And then focus on becoming an SME in particular sectors that provide the most benefit to your team. Also, encourage others to up their security training, creating teams, SMEs, or security champions that can assist others in gaining security knowledge over time.

Additionally, make sure everyone knows security processes. When a vulnerability surfaces, you want quick action and escalation. You don’t need teams playing phone tag and chasing tickets, hoping to find someone that can help fix or even diagnose the issue.

And finally, the security landscape changes frequently. DevSecOps isn’t something you learn once and are done with. Keep building upon your knowledge base on the best ways to prevent and remediate issues.

Automate manual security processes

So now that we’ve got a culture of trust, automated scans, infrastructure as code, and the knowledge to keep ourselves safe, what’s our next step as DevSecOps professionals?

Next, we should look at the manual security processes that we’ve been relying on for years and automate them. And with automation, we’re not just making the process simpler. We’re making it more reliable and repeatable because we’re not expecting our people to produce perfection.

What does this include? Look at how your team can automate access and security audits. Find ways of automating threat modeling. Work with your security teams to find new tools that can be incorporated in your DevOps systems to provide automation for previously manual processes.

Test and monitor the tools

Now that we’ve got all this automation, what else can further our journey? Metrics!

Metrics not only provide great value for determining if an application is up and running, but they also provide peace of mind that all your security and infrastructure stays in place and functions correctly.

With security incidents, time to detection is critical. Invest in tools that detect security flaws and alert you automatically. And test that those tools find vulnerabilities in an automated fashion. Green tests don’t mean much if they’re false positives.

And don’t add monitoring only to applications and infrastructure. Also add it to your security controls. Test that they’re working and providing you with data that you can act on.

Your journey begins here

It’s an exciting time. Security concerns that had previously been put on the back burner or pushed far to the end of the development lifecycle are coming toward the front, and now we have the opportunity to decentralize security across developers, security, and operations teams.

We’ve got a lot of opportunities to make our applications more secure than ever. New tools and techniques identify and solve problems that we’ve had for years. And we need all this, because the bad guys are developing their own tools and knowledge as well.

So shift left, automate security scans and processes, and evolve your knowledge base over time. And don’t put all the pressure on yourself. Find the tools and partners that will help you succeed with DevSecOps.


This post was written by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.

Notify of
Inline Feedbacks
View all comments