DevOps has been a popular development strategy for a few years now, but organizations are beginning to make the transition to incorporate better security practices. Strategies like SecOps and DevSecOps are redefining how organizations think about (and implement) security, and that’s largely a good thing; security is more important than ever before, and we have access to countless tools to help get the job done.
However, implementing security in your DevOps strategy can still be challenging. You’ll need to understand the specific hurdles that most organizations face, and come up with some way to avoid, counteract, or mitigate them.
High-Level Challenges in Implementing Security
These are some of the biggest challenges most organizations face:
- Lack of direction. One of the first challenges most organizations notice is the overall lack of direction. There’s no guide on the internet that can give you a perfect, step-by-step guide on how to make the transition. There’s no checklist of internal changes to make that can suddenly integrate security into your DevOps pipeline. That’s because every business is different, and will require a slightly different approach. This is challenging, because it means you’ll have to look at your own processes and policies and come up with a strategy of your own from there.
- Corporate silos plague even the most efficient communicators. When integrating better security practices into development, into operations, and throughout your development timeline, multiple independent teams and multiple departments are going to get wrapped up in it. Some will inevitably be frustrated. Others will be confused at what’s going on. If you’re going to be successful, you need everyone operating together as a comprehensive team, and you need to communicate as clearly and as comprehensively as possible.
- Objectives and prioritization. Implementing the best possible security into the best possible product while also getting that product developed quickly is the dream—but it’s not the reality. Sooner or later, you’re going to have to make compromises. If and when you do, how are you going to prioritize your needs? Setting high-level objectives and priorities that allow teams to make on-the-fly decisions is extraordinarily difficult; there’s rarely a single right answer, but it’s still important to think about each implementation as it relates to your overall goals.
- Knowing where to start. Let’s say you’ve decided to commit to higher security standards at every stage of your pipeline. If that’s the case, where should you start? There are many viable options, with few obvious choices on where to start. Do you begin with upgrading your container orchestration tool? Or do you work on implementing better vulnerability scanning? Either way, are you going to set other priorities aside to make time for it?
- Implementing better security requires better documentation, in multiple ways. For starters, most organizations are well-served by documenting their processes from a high-level, before they start making any changes. What processes do your team members typically follow? What does your workflow look like? From there, it’s easier to identify opportunities for improvement. Once you begin implementing new policies, you’ll also need to instate new documentation to ensure your policies and practices are easy to understand and follow consistently.
- Service providers and resources. Choosing new providers and resources can also be a challenge. Depending on your goals, you may need to upgrade some of the tools you’re currently using, and/or you may need to invest in new tools, like vulnerability scanners. There are several issues that can emerge during these process, including making a decision between two very similar products, setting aside a budget for your new tools, and figuring out a way to transition from one product to another.
- Resistance to change. Finally, you’ll inevitably meet some resistance to change, most noticeably from the people within your organization. Your team leaders, developers, and even your account managers are used to a certain way of doing things. When you begin implementing different security processes into your DevOps strategy, you’ll initiate some form of disruption. Employees will be responsible for more processes. Timelines will inevitably be shifted. You’ll be using different tools and resources, and possibly even communicating differently. No matter what, it’s going to cause a bit of tension. Finding a way to navigate this is going to be crucial.
Learning and Adapting
SecOps and DevSecOps are tricky because there’s no single process or strategy that works for every organization, nor is there any kind of light switch that can make the transition instantly. Instead, each organization will need to approach this implementation uniquely, understanding their own strengths and weaknesses, and adapting as they learn more about their circumstances. Make sure you enter this new philosophy with flexibility and adaptability in mind.
Anna is a freelance writer, researcher, and business consultant. A columnist for Entrepreneur.com, TheNextWeb.com and more, Anna specializes in entrepreneurship, technology, and social media trends. Follow her on Twitter and LinkedIn.
