Secure SDLC Lessons Learned: #3 Knowledge Management 

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

The term “knowledge management” (KM) refers to using vulnerability mining to turn remediation into lessons learned. Essentially this involves taking knowledge from security remediation activities and placing it within a KM repository that developers, architects and other stakeholders can access. By sharing remediation information across teams, an organization can remove or reduce intelligence silos that contribute to recurring and familiar software bugs.

Plan

After performing applications assessments and other security testing activities for a time, there should be enough remediation data within your defect tracking system to start pulling out the most common security-related coding mistakes. This assumes that security-related bugs are flagged as such. If your organization isn’t already flagging or tagging defects this way, now is the time to start.

Consider also mining qualifying bugs by feature or functional areas like authentication, and/or by vulnerability types like lack of input validation. If possible, separate results by language and/or platforms used. Some data normalization may be required to make this easier. Sort by the number of bugs discovered in each category, and focus on documenting those areas first. 

Build

Again, the end goal for building a KM solution is to store company-specific secure coding best practices and remediation techniques as proactive guidance for development teams. A centralized, accessible location such as a Wiki is well-suited for this task. Content typically will include links to relevant security standards, sample code and design templates for things like tying an application’s authentication into the corporate SSO. By defining coding standards around approved enterprise architecture components (e.g. libraries, platforms), architects and developers can gain confidence when developing on secure-by-default frameworks and patterns.

Alternatively, developers could dig into the bug tracking solution to find other examples of the bugs, and see how they were fixed, but a curated central knowledge base is very effective. It takes time, but it doesn’t cost product dollars, doesn’t interfere with the build cycle, and it saves a lot more time later when other developers encounter similar issues.

Run

Operationally, someone has to take ownership of selecting and publishing this information. For example, when a vulnerability is identified and remediated, a developer should draft up remediation guidance and dump it into the KM solution. Leverage a workflow so a lead developer or other SME can approve the content, make sure comments are adequate to describe the issue, what the remediation was for, include example code, etc. 

Teams should take advantage of the KM solution to proactively watch out for the same mistakes other teams have made. Leverage things like tags, keywords and filters to make the pool of historical knowledge searchable. In the end, the system provides developers assurance that if they’re programming in a certain known-good way, they’re aligned with the organization’s definition of secure development.

Implemented correctly, KM solutions serve as a continuous feedback loop that helps improve code quality at the source. This is another great example of shifting security left, and as mentioned in an earlier post in this series, that can mean significantly reducing both remediation costs and security risk. 

In the next post I will cover secure SDLC lesson #4, metrics.