The latest buzzword to hit many of our ears attempts to give us a sense of safety and comfort. We’re no longer just doing DevOps. We’re doing DevSecOps! It’s not an unworthy goal. With DevSecOps, we’ve gone past just working through automation and continuous integration and delivery. We’re now pulling security processes into the pipeline.

That all sounds great, doesn’t it? However, these new security measures we’re talking about should have already been part of our lives. Application and infrastructure security shouldn’t be an afterthought, a checkbox on a production readiness checklist, or a bolt-on solution. Security should be considered as early in the development process as possible.

Today we’ll look at some of the hype coming from our new buzzword. And we’ll talk about how many of these practices should be second nature to our application development ecosystem. We’ll want to know security beyond the buzzwords that permeate our environment.


What’s Wrong With Another Buzzword?

A few things concern many of us when we hear yet another buzzword. Though it’s great to put a common label on some new process or tool set, many of us no longer know what these buzzwords really mean.

For example, let’s just look at DevOps. For some of us, DevOps means having a development team that’s responsible for operations. Others consider it to be the automation of infrastructure. And some consider DevOps to be the automation of the operations department’s job.

Why do all these different definitions cause concern? Well, we may all think we do DevOps, but we all might not intimately know the benefits that DevOps can provide.

Likewise, if we throw the DevSecOps term around, we may fool ourselves into thinking we’re secure because we have one or two automated tests that verify we authenticate our clients properly. Is that part of DevSecOps? Sure, but there’s more to it than that.

Additionally, when I look at all the companies that create dedicated DevOps teams that don’t work with or inside regular development teams, I wonder if DevSecOps will go the same way. It can make security concerns someone else’s job. Or it becomes just another task on a list put together by some other team.

But security isn’t something you just check off a list or delegate to another team. It’s part of the product from inception to maintenance. And it should evolve and mature just like your software application or product.


What’s the Common Sense Approach?

Now that we’ve warned you about applying buzzwords without fully understanding what they mean, let’s look at some basic steps your organization should take to implement security measures.


Develop a Comprehensive DevOps Security Policy

We shouldn’t leave security policy creation to the operations or development teams. This process requires security professionals that can put together a comprehensive policy that all teams should adhere to.

After the security team constructs these comprehensive policies, the development teams should have proper training and instruction on them. However, the training shouldn’t just cover the “how” of these policies. It should also cover the “why.” Though software developers often can’t become security experts due to time constraints, they should get a glimpse into why security policies were put together.

In addition, the developers should be able to question policies if those policies will cause detrimental effects to the development team. Of course, final say on policy should come from security professionals, but that doesn’t mean the developer’s voice shouldn’t be heard or considered when creating these policies.


Shift Security to the Left

As I mentioned previously, security shouldn’t be something that’s added on to the application after the fact. It should be considered early in the development process.

How does this help? Once we consider security up front, we can plan for security controls in our development pipeline. This way, we don’t end up in situations where people or applications that need access to a program suddenly get locked out because we added authentication and authorization to the process.

In addition, the more we move security to the left, the sooner we can find what type of security our customers will need. For example, do we need to segregate data for different tenants? Do we need to encrypt data early in the process? The sooner we know about these security requirements, the better we can plan for them in a way that’s least disruptive to the development team.


Use Robust Secret Management

Though most of us know that we shouldn’t be putting IDs and passwords into our source code, we often must find our own way of securing these secrets. A common sense approach would provide developers with known processes and tools for secret management.

That may seem like a no brainer, but situations arose in my past where secret management was an afterthought. The processes and practices were left up to developers. These developers had to not only find a way to securely store secrets without proper tools but also become experts about encrypting those secrets properly. Their hands were tied from a lack of tools and resources. They couldn’t create a clean solution that worked with the infrastructure that they had.

Therefore, your company strategy should have clear rules and processes around secret storage, rotation, and access. Ideally, secrets rotate automatically and don’t rely on people rotating them manually or creating request tickets for another team to rotate them.


Empower Security Champions

Though we can’t rely on everyone understanding all security concerns, we can still empower security champions to help teams keep security at the forefront. Find people on your teams that have a passion for security, or identify those people that can raise concerns comfortably with the team.

These people, though not security experts, can help champion security initiatives and remind everyone on the team that security isn’t an afterthought.


Implement Least-Privileged Security Policies

Implementing least-privileged security policies often doesn’t sit well with application development teams. They want access to everything so they can do their jobs quickly and efficiently. While having a least-privileged approach to providing access makes sense, also consider whether you can provide other tools for development teams so that they’re not stuck waiting for access to do something. One suggestion is to offer scrubbed test data that developers can play with easily. Another option is to offer self-service capabilities for operational tasks that don’t take excessive approvals or time.

While these policies should be created by security experts, they should keep development and operations teams in mind.


Automate Security Validation

Many companies still rely on checklists and manual testing to implement security testing. Unfortunately, that method is prone to error and often takes up too much time.

Instead, you should look for automated solutions for repetitive tasks. Plenty of tools now exist for automated security checks.

For example, security-focused code linters can spot security flaws in code more reliably than a human. Additionally, automated penetration testing can make sure that your application is safe not only today, but that it remains safe with repeatable and often-run tests. You can also implement automated dependency scans as part of your CI/CD pipeline to make sure your application pulls in the correct libraries.

All of these things focus on the DevOps component in DevSecOps, in which you look at existing security processes and find ways to automate them and make them better.


Are Buzzwords All Bad?

Now that we’ve looked at some common sense approaches to DevSecOps, we must ask the question: Are all buzzwords bad?

No, of course not. When we have an understanding of buzzwords or industry terms, it helps bring us together and provides a common language that we can use to describe problems and solutions. However, we shouldn’t just take a buzzword and start claiming adherence after reading a few blog posts about it (including this one). We should take the time to learn about the problems we’re trying to solve. And we should look at different solutions to those problems. Then, if it makes sense to get on the buzzword bandwagon, go for it.

But you don’t need to take that journey alone. With Carve Systems, you can get access to security experts that can provide the guidance you need. That guidance will make sure your application and pipeline provide automated safety security threats.

Author: Sylvia Fronczak