Posted by on Monday, September 20th, 2021

Building an effective application security program for your organization begins with establishing policies and processes.

Psychologist Abraham Maslow wrote, in 1964, “Give a small boy a hammer, and he will find that everything he encounters needs pounding.” This is commonly rephrased as “if you have a hammer, everything looks like a nail.” 

This applies especially well to doctors and surgeons—they want to do the thing that they know how to do, whether that is prescribing pills or performing surgeries. Even when your particular situation and symptoms don’t exactly match the conditions that they treat, they’ll still be inclined to do the thing that they know how to do, just because the alternative is saying either “I cannot help you,” which no doctor wants to say, or “I do not understand what is going on with you,” which no doctor wants to say. 

It applies equally well in the technology world. People tend to latch on to the latest shiny new technology as the way to solve many kinds of problems. It is easy to get swept away by the enthusiasm of the latest movement while forgetting about the more mundane aspects of your life or your business. For more perspective on shiny objects, including a shout-out to Maslow, read Dan McKinley’s excellent essay about the perils of selecting software components, Choose Boring Technology. 

Application security

In the domain of application security, it’s easy to get swept up in shiny new tool features, and indeed, exciting things are happening. 

One of the foundational application security tools is software composition analysis (SCA), where an exciting new development has to do with code reachability. An SCA tool normally determines the open source software components that have been used to build an application so that associated known vulnerabilities can be identified. In Synopsys Black Duck, a feature called reachability goes one step further, figuring out if you’ve actually invoked the vulnerable code in the identified software components. 

Another exciting development has to do with handling the flood of vulnerabilities that result when you start running application security testing (AST) tools. Our vulnerability aggregation and analysis solution Code Dx takes the results of multiple AST tools, then aggregates, de-duplicates, and prioritizes the results. In addition, Code Dx can use machine learning (ML) to understand how engineers triage vulnerabilities and provide automated guidance for future vulnerabilities. 

Sometimes you just need a knife

Developments such as these are exciting and point to the future of application security. But you have to take a holistic look at your application security to understand what you really need. If you need something to spread cream cheese on your bagel, you don’t need that fancy light saber; a butter knife might work fine, or you might consider something a little more specialized like a cheese spreader. Nevertheless, it is important to keep in mind the realities that are in front of you now. 

If you need to improve your application security, begin by concentrating on fundamentals. You need to find vulnerabilities so you can fix them, and you need to integrate security to your existing processes for minimal disruption. Many development groups have a workflow based around issue tracking software; a good first step for application security would be automated runs of security tools in the build and test cycle, with results integrated into the existing issue tracker. 

For engineers, it is easy to slip into a mindset where application security is all about the tools you run, but this is an illusion. The reality is that application security is as much about policy and process (not very exciting) as it is about tools (fun!). 

Start with an application security policy and process

The right place to begin is with policy. Writing application security policy forces you to think about the way things should be—what design-time activities must happen, what education you provide your engineers, what kind of testing applications you must use, and what kinds of results are acceptable.

Once you’ve settled on policy, you can start building the application security processes that will get you there. At this point you can get more specific about tools, how they are automated, and how they integrate to existing components in your processes. It is important to select good tools, but always choose them to fit into the framework of your policy. 

Stay on target

No matter what shiny new tools are available, your policy guides how you implement application security. The end goal is risk reduction—get the tools that help you achieve the goal and put them inside the framework of your existing processes so that application security is inseparable from development.