DevSecOps: 3 ways to bring developers, security together

Source – enterprisersproject.com

Applications are the heart of the digital business, with code central to the infrastructure that powers it. In order to stay ahead of the digital curve, organizations must move fast and deploy code quickly, which unfortunately is often at odds with stability and security.

With this in mind, where and how can security fit into the DevOps toolchain? And, in doing so, how can we create a path for successfully deterring threats?

As DevOps continues along its path of dominance, organizations need to bring developer and security teams closer together to support secure applications. They can do this in three ways.

1. Develop trust

What contributes to the divide that exists between developers and security teams? Different cultures and priorities, shifts in methodologies, and varying tools and technologies are all factors. The goal is to change perceptions between DevOps and security and foster an environment of understanding.

Trust is key to uniting the two groups: A good starting point for security professionals is to find out what motivates developers. More than likely the answer will be that developers enjoy being on the cutting edge of technology and learning new skills. In this regard, unfortunately, most developers do not regard security as “cool.” This is a good starting point where you can change perceptions.

How? One business addressed this by rewarding developers and identifying them as “security champions” when they consistently followed security best practices.

They first found a smaller set of motivated senior architects with whom the larger development fraternity identified, then engaged with this set of senior architects to co-develop security best practices, and finally, used these seasoned and respected architects to promote security best practices. This move by the security team away from the perceived “policing” of the development chain towards engagement did much to gain the development team’s trust and respect.

2. Create accountability

In many instances, developers do not feel that it is their job to be responsible for security. But in the age of DevOps, just as developers feel responsible for the quality of the software they create, it’s important that they also feel a sense of responsibility for the security of their software practices.

One way to build accountability could be for the teams to set up sessions to review very simple exploits, how they could potentially deface some internal applications, or gain access to an app without authorization. By creating a dialog about what both teams need to be aware of through simple, practical demonstrations, you can open both teams’ eyes as to what could happen if the product does not prioritize security.

3. Promote cooperation

By creating a partnership and undertaking the journey together rather than separately, teams begin to perform as one unit.

Usually, application security teams are small, with resources assigned to various development projects. What usually ends up happening is that the application security team, with all good intent, begins holding people accountable to certain standards without necessarily recognizing assumptions and constraints that the development team is under while building out products.

It’s a perfect recipe for building resentment and misunderstanding, instead of creating a unified team focused on seamless DevSecOps.

An alternative approach is to take the available security resources and actually embed them into some of the most critical projects within the business. The rationale is that if the security component is tightened within a handful of projects to create a successful DevSecOps process, this blueprint can later be applied to other projects. It’s important to ensure the method be scalable to suit projects of various sizes.

By embedding security resources into product development teams in this way, application security professionals are able to:

• Be part of the daily development standards process.
• Have a voice at the table during each step of the development process: They are part of the journey.
• Develop an understanding of constraints – be it time, technology, or both – within the development chain.

By being involved each step of the way, the security team is involved in the day-to-day build out and are able to voice security concerns more easily and with more credibility.

Following each of these three steps requires constant recognition and affirmation of all the teams involved. Positive reinforcement is important when it comes to team goodwill.

While it will take time to implement and build security into the software development lifecycle, achieving a DevSecOps blueprint that truly integrates all the internal stakeholders will help to pave the way for building and deploying innovative applications that are stable and secure.