I find myself talking with customers about program maturity a lot these days. Our customers all have application security programs in place, but each one is a little different with different approaches, requirements, priorities, and sitting at different stages of maturity. Each program also has things in common as well such as testing techniques and the overall goals of catching security coding flaws early on or preventing altogether.
So how do we define program maturity? The concept is ambiguous, and most of us have different ideas of what constitutes our programs, and consequently what maturity refers to. I’ll start with some examples to get us thinking along the same lines. When I think about an appsec program, I think about all of the day to day operational activities like working with developers to get their applications tested, analyze results, and make commitments to remediation. I also think about the strategic objectives like reducing risk and technical debt in a measurable way. We can do this by measuring and trending our testing activities and observing several things. We’ll be interested in seeing:
This is just a basic list and you may be doing other things as well. So what about program maturity? This term can also mean a lot of things to a lot of people. So I tend to think about maturity in the way we observe our (or others’) kids. As they mature, they tend to be more independent, and we spend less time being directly involved with mundane activities like getting them dressed and helping them eat. At 2 years old, we need to make sure the toddler isn’t throwing his bowl of cereal on the floor. By the time she is 10, we still have to make sure she eats balanced meals, but we generally don’t have to be as concerned about cereal bowl throwing. So our oversight requirements change and we are able to focus on bigger issues like their schoolwork and social activities.
Our appsec programs follow a similar model. As we begin formalizing them, we have to be concerned that developers aren’t following the process correctly and test results may be suspect. We spend a lot of time on operational tasks as we shepherd the process. But as the process becomes better socialized throughout the organization, we can focus less on the mechanics and operational aspects and let momentum take over which frees up resources to focus on more important items. Make no mistake, you will still need to train and socialize the process with new team members, or with teams that do infrequent code updates, but the amount of time spent is greatly reduced. Now, the same investment we made last year in people, process, and technology is now providing a lot more value, which by definition, is increasing our ROI.
Hopefully this idea is getting you to think about the investment you are currently making in people, process, and technology and how you can get more from that investment. Our SPMs and CSMs are constantly thinking about these things, and one of their goals is to drive adoption through better socialization in order to help their customers achieve more and get to the next level of maturity. This should be a topic during every quarterly business review (QBR) you have with them. If you haven’t had this discussion in a while, don’t wait for the next QBR! Strategizing with CA Veracode Services will pay off quickly, which is one of the reasons we always want to partner with our customers.
Did you enjoy this post? Jeff Groman will be presenting in a CA Veracode webinar on Wednesday, August 28th. The webinar, titled "Work Smarter Not Harder: How you can get more from a mature security program," explores the concept of security program maturity and will outline strategies for maintaining a efficient and successful appsec program. You can register for this webinar by clicking here.