The Edgewise Approach to DevSecOps

DZone 's Guide to

The Edgewise Approach to DevSecOps

By treating security as code, you avoid the risk of shipping vulnerable code and the highly inefficient “security hardening sprint.”

· DevOps Zone ·
Free Resource

Real security

There aren't a lot of good stock photos about security.

Tom Hickman, vice president of engineering at Edgewise Network, recently shared his thoughts on the current state of DevSecOps:

What do you consider to be the most important elements of a successful DevSecOps implementation?

Successful products built within DevSecOps will turn engineering into a 24x7 function, and while traditional “Ops” staff have always dealt with this expectation, developers and security practitioners have not. It’s a big change for them. The team must buy-in on a pretty significant paradigm shift away from traditional stove-piped silos of responsibility. And leadership must acknowledge the change in role, and look after the team to prevent burn-out.  

What are the attributes of a positive DevSecOps culture?

Empowerment and transparency, in the service of velocity, without sacrificing security. 

Empowerment: With the right tooling, an engineer in a DevSecOps team has the resources he or she needs, from kernel to cloud, to design, test, deploy and support secure software solutions. Done well, DevSecOps creates a culture where people are empowered to solve problems, without requiring permission.

Transparency: That only works, of course, if everyone can see the whole system, and if there are no secrets. This is virtuous at face value, but very critical for a team where empowered engineers are moving fast, and sometimes breaking stuff.

Velocity: To me, this is what it’s all for. DevSecOps is about enabling teams to solve customer problems faster, and to get secure, valuable, and scalable solutions into customers’ hands faster than ever before.

What problems are solved by DevSecOps – where is the greatest value realized?

Successful DevSecOps shops typically don’t have silos of knowledge, and thus don’t have the kinds of “turf-wars” that were once common in teams organized by specialty or tech stack. The value that produces is pretty straight forward -- the team can own the solution to any problem, full-stack; they are empowered -- able to move fast and break stuff. And they can do this without sacrificing security.

What are a couple of real-world problems being solved with DevSecOps by your company or clients?

By treating security as code, and by building security practices into the software development life cycle, DevSecOps shops avoid both the risk of shipping vulnerable code and the highly inefficient “security hardening sprint” that kills so many project schedules.

What are the most common DevSecOps fails? How are they rectified?

The biggest failure is tacking the “Sec” on at the end, which really just replicates the broken practices of previous development and delivery models, only faster and with more complexity. Security has to be built into the environment, the tooling, and even the wetware -- the brains and mindsets of everyone involved in building and delivering software solutions.

You may also like: DevSecOps #Fails

Do you have any concerns regarding the current state of DevSecOps?

The technology supporting the DevSecOps movement is great. The big concern I have is the deployment topology, at any significant scale, is unknowable by humans. That’s been the big driver behind our extreme automation approach to micro-segmentation, using machine learning (ML) to simplify vast and hyper-complex rule sets and turn it all into actionable, understandable policy recommendations. 

What’s the future of DevSecOps from your perspective, where do the greatest opportunities lie?

The future of DevSecOps is security as code, and what micro-segmentation will allow practitioners to do is to register new applications, application collections, hosts and host segments from the same toolchain they use to build, test, and deploy their applications and infrastructure.

What do developers need to keep in mind with regards to DevSecOps?

Security has to be front of mind in every feature, function, commit, and transaction.

What have I failed to ask you that we need to consider with regards to implementing DevSecOps?

One of the cool emerging areas where technological advances are converging with changes in how people do “our” jobs is the capability of machine learning and algorithmic analysis to take “big data” approaches to automate what was previously manual and to simplify what was previously daunting. This opens up a lot of opportunities for DevSecOps practitioners and puts a lot of pressure on our company to solve the problem of micro-segmentation -- security at scale and at high-velocity. I think it would be interesting to explore how we and others are enabling solutions that were previously thought impossible, through automation and ML-informed algorithms.

Further reading

DevOps Security at Scale (Part 1): Security Policy as Code

The Secret to Workplace Morale May Very Well Be DevOps

devops ,devsecops ,security ,transparency ,empowerment ,velocity ,security as code

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}