Should Vulnerabilities be Treated as Defects?
Security functions within companies are usually their own organization that are for the most part outside of the development infrastructure. Security people often are not actively integrated into daily development activities. Let's face it; we aren't actual team members in the normal sense. So does it make sense that security vulnerabilities are treated as defects? I believe the answer is an emphatic "yes" but with caveats.
Security Is Often An Island
For years I advocated NOT making security vulnerabilities part of the development QA bug tracking system. It's like mixing apples and oranges. From my days as a developer and in QA, even huge software bugs vary in priority on being fixed. It's all about the cost/value decision, customer tolerance, and how many are affected, and if there is a workaround. Security vulnerabilities, on the other hand, can be about liability for exposing something like credit cards, breaking the software for fun and profit, and shaking belief that the product is not safe to use. Sitting in bug triage sessions I witnessed how product owners are on the hook by large customers for a fix that was promised versus the small voice of the security group to fix something that "maybe" will cause an issue.
Don't Be An Outsider
But with experience, I have recanted. It is in the interest of security to integrate vulnerabilities solidly into development's bug-tracking culture as defects. Not treating security vulnerabilities as defects is actually avoiding the realities of software development and Information Security's still developing role. The purpose of development is to make software that satisfies customer needs and fixing bugs is part of it. It is up to security to adequately translate security vulnerabilities into the language of development and at a priority level that warrants their response. Security loses because development often does not understand security or control security's efforts. Security needs to educate in the context of development's perspective.
So, How Do You Do It?
With Agile methodologies and other rapid development models, the more concise and specific an approach the better. Simply creating extracts from the PDF scan reports or pointing to general security guidelines is not enough.
Here are some starting points:
Make The Work Easy
When possible, use tools that create bug tracking entries for loading. Development or QA then has no manual entry and things are consistent. If necessary, security should create the tracking entries for upload; we want the fixes, so putting it in the right form is our cost. Development will be much more receptive if they do not have to do a lot of manual work for consistent entries.
Be sure there are links or IDs that match their security bugs to yours. Security will probably track a variety of additional information that development does not. Mismatches between the two systems can happen and cross-referencing will help.
Identify a specific solution for the fix to a security vulnerability. You might have multiple solutions, but developers need a specific solution they can run with that does not need a lot of discussion.
Leverage the same defects or combine multiple security defects. Using a consistent, even rigid, approach to identifying defects in bug entries allows for coding that might be reused or turned into centralized modules to fix a flaw, such as fixes for input validation.
Don't enter all 1,000 flaws of a certain type, like cross-site scripting, that will swamp developers. Instead, create a single defect that needs the same solution. Then apply the code reuse or centralized modules from earlier to address the issue.
Help Development Own the Security Bugs
Be part of bug triage sessions where security defects are considered. Development often does not have a security perspective and might prioritize regular fixes with a more visible bottom line. Security's input educates and advocates. Not there = no say.
When possible, identify a consistent single solution. But also offer a good, better or best solution to let developers choose a particular security bug fix based on time and resources.
Resist being given access to the bug tracking system. You having access shifts the ownership and responsibility of tracking bugs more to you. By development pulling security fix metrics and tracking outstanding security defects they then manage the security defects like any other bug.
Integrate Into Development's Psyche
Use the bug tracking system as the same language to talk about the efforts put into security. Software development heavily relies on metrics to manage fixing code bugs. Management follows metrics that they buy into and understand, and adding security to that system expands their view. For Security, the metrics help determine whether a security effort is making progress within Development.
Use outstanding security bugs to affirm Development's ownership for their fixing. Security often finds vulnerabilities and, since they are seen as somehow outside of the bug process, must drive (and hound) Development to fix them. Once in the bug tracking system, Development then becomes the driver of the security bugs.
Visibility is the name of the game. If security vulnerabilities are in a bug tracking system then they are real. If Security stays active in triage, follow-up, and tracking them, then Security becomes more real within the teams that fix the bugs.
Just Part of The Solution
Treating security vulnerabilities as defects is just one approach to building security into software products. This approach requires being an active participant in working the security bugs and keeping focus on their priority, just like the development teams work their other bugs. By making security vulnerabilities part of the vocabulary and burn-down list for Development, Security identifies a bug in a familiar language. Other steps then follow that include educating Development on mitigations for specific vulnerabilities, how to test for these types of flaws, and how to design products where vulnerabilities don't happen to begin with. Nobody said that software security would be easy, but treating vulnerabilities the way Development treats their quality issues is a good start.
~ Kenneth
