Voix Security: Secure SDLC Processes

I was reading about the differences between weak and strong typed computer languages and I came across the following sentence in Wikipedia “Programming languages are often colloquially referred to as strongly typed or weakly typed. In general, these terms do not have a precise definition”. This got me to thinking about a recent conversation I had about Software Development Life Cycle (SDLC) and mentoring.

The terms SDLC and mentoring are used often in conversations but like strongly typed or weakly typed languages both terms do not have a precise definitions, worse is the definitions between organizations both commercial and academia can differ vastly.

Mentoring is more than just answering occasional questions or providing ad hoc help. It is about an ongoing relationship of learning, dialogue, and challenge. Often it is the senior person given the responsibility to mentor the junior person. To begin this conversation lets settle on a broad definition of mentoring…. A relationship in which a more experienced person helps to guide a less experienced. However, true mentoring is more than just answering occasional questions or providing ad hoc help. It is about an ongoing relationship of learning, dialogue, and challenge.

How do we mentor secure coding/development to an organization? Who do we need to mentor? Upper management to add development time and cost to make sure the delivered product is secure for the organization, users both internal and external. With upper management we certainty need to use formal and informal transmission of knowledge and social capital. But we are hardly in a true mentoring relationship.

Peers, Peers have their eyes set on the goal of getting their projects into production. Most project incentives are based of development cost, meeting timelines, getting thru QA and getting user acceptance, not on being secure. Add all those pressures together and trying to throw secure coding into the mix except a few points about sql injections usually falls of to the floor while more pressing issues to ship the product take front stage.

Let’s move off mentoring for a moment and move to SDLC. With SDLC, we have XP, Agile, JAD, RAD to mention a few. But now with Secure Software Development Life Cycle we can add OWASP’s OpenSAMM, Microsofts SDL, CIGITAL BSIMM just to name a few. To make matters worse every organization I have every been associated with takes various pieces of each SDLC and uses the methods they like best and even within those methods they not fully use the entire method as it was defined. To further muddy the waters most development organizations add their own brand of project management to their SDLC processes.

So how do we have a meaningful conversation on these? Maybe we don’t. Do we have each party give out a fully disclosed document on their definitions? Are our definitions only related to each other past experience or a combination of experience and professional research and training? Or at best muddle thru hoping each person understands the other.

I know I really don’t have an answer but the conversations are always fun. Maybe that is part of the answer instead of looking for the right answers lets talk about what strategies have work for us and what in the past did not work and where we want to go.

What strategies do you use in your organization? Do mentoring and SDLC and security come together or is each item separate? Can you write down what your organization definition of the SDLC is? The steps it follows and where it defers from the published guidelines for that SDLC? If not is your organization using an ingrown ad-hoc SDLC that is documented and does your organization follow that document to the tee or a partial implementation? Remember seat of the pants is not really the way to go. No matter what S-SDLC you use, a plan is better than no plan at all.

Tim Rains of Microsoft just release a blog post on developers using secure SDLC. Microsoft’s survey showed “security wasn’t considered a “top priority” when building software by 42% of developers worldwide.” His blog post goes on to say “While security development processes have been shown to reduce the number and severity of vulnerabilities found in software, almost half of all developers (44%) don’t use a secure application program/process today.”