Even in the most enlightened and supportive organization, you will face challenges in introducing and sustaining the SSDLC in the face of ever-shifting priorities and pressures.

Here are some challenges you’re likely to face:

Business Objections

You may work in an organization that already understands that security investment is important. Maybe key customers are already making inquiries. If not, you are going to need to convince the business that an investment in security is in their best interest, because it will have a cost.

You may be tempted to scare people into security investment by talking about worst-case scenarios; be careful not to overdo it or you may end up losing credibility and/or creating a more disruptive event than you intended.

Consider using examples of issues in your own industry and demonstrating the cost of not doing anything. Anecdotes from customers can be powerful as well. And by framing the conversation in the context of a measurable SSDLC, you will be able to demonstrate your current state and progress along the way.

Without that framework, the only evidence of your state of security is going to be when customers report problems.

Priorities

Any engineer can tell you what happens to priorities when schedules get tight – if a story doesn’t directly support required features, it gets cut. As long as the work is considered a separately prioritized and ultimately optional work item, it will be in constant jeopardy in the schedule.

Consider working with your Product Management to reach an agreed upon strategy for investing in security practices, and then take the day-to-day decisions out of their hands.

We don’t allow Product Managers to cut functional testing because we have an implicit agreement that testing is not optional; seek the same agreement on building in and testing for product security.

Secrecy

Any Legal department is going to prefer some level of discretion when it comes to dealing with security issues. There are legitimate publicity and liability concerns that you will need to be thoughtful about.

However, without some level of transparency, especially within your R&D organization, your engineering team will struggle to make progress and learn from past mistakes. Try to understand the “why” behind the organization’s concerns and provide as much visibility internally as you can in that context.

Note that if fear was your tactic in selling the organization on an SSDLC in the first place, you’re going to have a hard time dialing that back when your engineers are demanding information.

Engineer Buy-in

Some engineers love to dig into security concepts, but many don’t or haven’t had exposure. More often than not, developers are driven to deliver code that works as quickly as possible. Adding “and is secure” is going to disrupt their existing cadence and you may see resistance.

Consider partnering with the individuals who are passionate about security to kick-start new methodologies. They will better understand how changes will impact the development cycle and will have more credibility in getting buy-in from their peers.

For some employees, providing training will be an incentive for getting engaged.

Maintaining Momentum

Once the ball is rolling, maintaining forward progress is going to be a challenge. There are many practices to adopt, and until security concerns are firmly implanted in your team’s mindset you will need to actively manage the change.

Consider setting milestones for roll-out of the SSDLC and keeping progress visible. Also, try to keep each step up in maturity achievable by your organization – move from awareness to action and validation.

Each step will result in a more secure product and allow your organization to grow in its practices at a sustainable pace.