Secure SDLC Lessons Learned: #5 Personnel 

In this blog series, I am discussing five secure software development lifecycle (SDLC) “lessons learned” from Optiv’s application security team’s conversations with our clients in 2016. Please read previous posts covering:

• Secure SDLC Lesson 1: Application Catalog  
• Secure SDLC Lesson 2: Assessment Toolchain  
• Secure SDLC Lesson 3: Knowledge Management  
• Secure SDLC Lesson 4: Metrics  

Secure SDLC Lesson 5: Personnel

It’s no secret that finding and retaining dependable, well-trained application security professionals is a serious challenge, and has been for years. Part of the problem is that the breadth and depth of AppSec knowledge is rather astronomical; one could argue that it’s exponentially wider than network security and grows at a much faster rate. Based on what I’ve seen, teams tend to be perpetually short-staffed and undertrained. 

Furthermore, many companies struggle with how best to build out their AppSec capabilities. Should application scanning and testing activities funnel through an AppSec team, or should developers be able to launch scans on demand and only engage AppSec SMEs when needed? How much and what pieces of the secure SDLC program should be outsourced?

Plan

Considering the current state of things, there is a tendency for organizations, especially those following Agile and DevOps principles, to have an over-reliance on automated security tools. It’s really no wonder that severe security issues still make it to production today. When secure SDLC programs are built too heavily on technology and too thin on trained professionals, they set themselves up for real trouble. 

In a recent client discussion regarding security policies and standards, one stakeholder admitted their mantra was, “Tools, not rules!” My response was, “That’s great. Now show me how closely your tools align with your security requirements.” The reality is that automated tools have limitations, and relying on them too much is analogous to organizations trying to outsource risk to third-party providers. It’s misplaced trust. The point here is tools are no substitute for skilled subject matter experts, which in turn are absolutely essential to a successful secure SDLC program. 

Build

Just as point-and-click scanners alone are insufficient, leaning too much on too few individuals can lead to constraints and, even worse, burn-out. One way to address the resource shortage is to “train up” more developers into AppSec. 

Unfortunately, finding sources of relevant, comprehensive, professional grade AppSec training is relatively difficult these days. There are many options, from onsite/offsite ILT and on-demand CBT to online webinars and videos. However, as it turns out, developers (and many existing security professionals) actually tend to learn best though more informal sources like blogs, feeds and similar online sources. Consider integrating some of these non-standard sources into the training curriculum.

Additionally, training folks in offensive security can help them code defensively. Again, there are a multitude of choices available, but no single source that would be considered comprehensive. Consider compiling a list of resources that best fit your teams’ needs and are tailored for each role.

Run

Knowing if your organization has the right personnel in the right places can be made evident through secure SDLC metrics, as mentioned earlier in this blog series. It can also be measured by observing how much your teams are leveraging your knowledge management solution. 

Ongoing training should not be neglected. Plan for periodic refresher courses, and consider incorporating training and even certifications into role-specific performance plans. As application security is such a moving target, recurring training just makes sense anyway. 

Though developers tend to get security concepts, they still struggle with connecting conceptual knowledge to prescriptive secure coding practices. By building out your organization’s AppSec capabilities through talent acquisition, training and skills development, you will be well equipped to help them bridge that gap.

Conclusion

Secure SDLC programs tend to be unique to each organization. Application catalogs, assessment toolchains, knowledge management solutions and metrics may be similar from one company to the next, but will often be implemented on vastly disparate technologies. Organizational structure, culture, industry, and many other determining factors will influence how you ultimately develop and implement a secure SDLC program that is truly your own.