Shift Left(er)

December 7, 2022

A Case for Governance in The Secure Software Development Lifecycle

Shooting billiards is all angles and vectors. It’s a fascinating process in where we begin with the end in mind and work backwards. Corner pocket, eight ball, the cue ball banked off the side railing. You calculate the shot and your stick strikes the cue ball at just the right angle and pace.

You can watch the shot unfold, just like you planned, complete with all the rewarding sights, sounds and feels of a perfectly executed shot. Or, you can haphazardly strike a cue ball and see, if by complete random chance, you strike any other ball on the table and maybe get it close to a pocket. This is how I typically play.

Such is securing the software development lifecycle (SDLC) for most of us.

What we should be doing is seeing the end from the beginning and planning our security activities accordingly. But, we end up with randomly struck balls scattering around the table and a tear in the felt from our cue stick. That way, there’s plenty of action, but not a lot of meaningful progress.

Luckily, there’s a way to stop haphazardly implementing security tools and policies with the best of intentions. To end up with a more secure SDLC, and as a result more secure software, we need to shift left(er).

To The Left, To The Left

In any of the traditional SDLC models when we say, “shift left,” what do you think of? Coding? Design? Security requirements? These are all common answers and certainly are “left”, or early in the SDLC. Implementing security tools and measures at the beginning is certainly an improvement from just having them in a dedicated testing phase, which is further “right” in the SDLC.

Image

But these implementations aren’t left enough. We need to shift further left, beyond refined code, great design and solid security requirements.

How far left? We need to leave the confines of the traditional SDLC into enterprise-level activities that involve everyone from engineers to executives. This is known within the OWASP SAMM framework as Governance.

Image

According to OWASP, Governance as a function “focuses on the processes and activities related to how an organization manages overall software development activities. Specifically, this includes concerns that impact cross-functional groups involved in development, as well as business processes established at the organization level.” We include personnel up to C-level, as well as policies, standards and strategies at the enterprise level.

I’ll dive deeper into each area in future posts of this series, but like a beautifully executed combo shot that buries the ball in a side pocket, here’s the type of magic that happens when we focus our security activities left.

Strategy: Create and Promote

There are many different tools, tactics and practices that come along with application security. More are flooding the market as you read this. Without a well thought out goal and strategy, you might end up spending a lot of time and money on security but end up with misaligned tools and tactics that don’t work well together.

Begin with a gap analysis of the current security posture within your SDLC. From that analysis, you should decide on goals for application security and a roadmap to get there. With a well-defined strategy and roadmap you can be more efficient and effective with your time and money and see sizeable returns.

Later in this blog series you can discover ways to build a scalable strategy in an iterative fashion that will have your efforts neatly aligned. An example of what elements might appear in a strategy document may include:

Training and Awareness

With a clear strategy in place, it’s time to equip everyone associated with software development with knowledge and guidance to execute the plan. Improving general security awareness across your enterprise is a great start. Those directly involved with application development need better, more targeted training.

What more mature organizations are implementing is a two-layered solution.

In the first layer, everyone involved in the SDLC, from project managers to engineers to incident management, has application security specific training. Think OWASP Top 10, secure design concepts and application security principles at a high level.

The second layer takes the broad topics above and drills down even further to provide trainings specific to certain roles within your SDLC. Developers receive secure code training specific to the languages they code in. Testers receive training on the tools they use.

Organization and Culture

As necessary as strategy may be, the old adage goes, “culture eats strategy for breakfast”. Many organizations draft a plan, assign training for their personnel and then cross their fingers, hoping the results will come. Making an intentional investment in building a security culture within your SDLC may seem like an uphill march. But there are simple, subversive and wildly effective tactics to transform the concept of application security from a nuisance into a seamlessly integrated part of your SDLC.

When implementing Governance practices, a little goes a long way. In the following posts of this series, I’ll deliver some practical steps to implementing strategy, training and culture solutions within your SDLC.

Just like billiards, the slightest of changes to how we strike the cue ball, in angle, pace or both, will have a dramatic effect on the results. A degree or two in angle, a pound or two more of pressure will greatly change the outcome of our shot. Likewise, decide to iteratively shift left(er) towards a Governance-focused SDLC based on this series and enjoy the wonderful feeling of burying that eight ball in the corner pocket.