I recently had an MRI, and, being a security geek, it got me thinking about scanning and application security. They checked my brain out, and despite some people’s expectation, found one there. Luckily there was no big problem with the brain they found, but I am following up with a neurologist. My general practitioner has to have a specialist look at it, understand the real problem, and recommend the treatment. But, since it’s a specialist, I have to wait a while to get an appointment. I am sure it’s a familiar story to any of you who have dealt with the American medical system.
This can be instructive in helping to think about what actually needs to happen when rolling out static analysis tool. You cannot have an MRI system do anything useful without a series of specialists with education, training and experience to do several things. First, you have to know when to apply the technology, which in my case was my GP ordering the test based on my symptoms. Then you need to know how to actually run the MRI, which was a very nice Radiologist. Then someone has to review the results, and decide what has to be done about it, which in this case is the Neurologist. All of these are limited, expensive resources with specialized education, practical training, and experience in their field. In addition there is a process in place and each of these people exchange information with each other about me and perform their specific role in the process.
In too many cases, with code scanners, an organization will buy one without putting in place the education, training, process and expertise to use it. This is like buying an MRI, sticking your head in, and expecting to be able to figure out how to best use it and interpret the images. You need education and training on when and how to run the tool, and then the knowledge and training to deal with the results. You also need a process so that all the proper steps are followed and nothing falls between the cracks. Here are some tips I have learned from others in the industry:
- Start with people and process, not the tool. An SDLC gap analysis is a good way to start. Make sure everyone agrees on the requirement and is committed to following through on their piece of implementing the changes needed.
- Commit time and resources to education and training. These are not synonyms. Education is getting general knowledge awareness about application security, process, and how the tool will fit in. Training is specific knowledge that is applied to using the tool and then prioritizing and fixing what is found. Doctors go to school, and then do internships.
- Take an iterative, problem solving approach. Security vulnerabilities in applications, like bugs, are going to happen. How they are handled and learned from will determine whether you reduce them in the future or get stuck on a treadmill with the same problems over and over.
- The scanner is a tool, not an end. It is part of the overall process of producing an application. You cannot scan security in any more than you can test quality in. Application security depends on the knowledge and practices used by all parts of the application development process and how the inputs to the tool are produced, when and how the tool is run, and how the outputs from the tool used.
Run two scans and call me in the morning. Everything will be fine.
