Skip to main content
How to improve your appsec program.
December 7, 2016

Where Does Our AppSec Program Go From Here? Ask Yourself These Questions

If you’ve just begun an application security program, but aren’t sure where to go next, here are a few questions to help point you in the right direction.

Are you using more than one type of assessment technique? If not, how certain are you that your one method is locating every type of vulnerability?

There is no application security silver bullet. If you’re only testing with static analysis, or only doing pen testing, you are missing vulnerabilities.

How can we be so sure? We recently compiled some pretty compelling data. In our latest State of Software Security report (based on the intelligence we have accumulated scanning more than 2 trillion lines of code), the data clearly illustrates that there are significant differences in the types of vulnerabilities that are commonly discovered by looking at applications dynamically at runtime, as compared to static tests in a non-runtime environment.

For instance, static assessments were better at finding CRLF injection and SQL injection, but dynamic was much better at illuminating command or argument injection and information leakage.

The point is that neither type of test is necessarily better than the other, they’re just different. As such, it is important for security managers to remember that no single testing mechanism is going to solve all of their application security problems. If you are only employing one assessment type, take a look at the other application security testing methods, and consider boosting your security by adding them to your solution.

In the software you write, as much as 70 percent is made up of code your developers did not write. Do you know which open source components developers are using, and if they’re secure?

With the extreme pressure on developers to get working code delivered quickly, it’s a common development practice to use pre-built open source software components and code. But, as we learned from Heartbleed and Shellshock, these components often contain serious vulnerabilities that expose organizations to significant risk.

And the risk is higher than many would think. Our recent research found that approximately 97 percent of Java applications have a component with at least one known vulnerability.

But components aren’t going away, nor should they. There is a better, more effective way to reduce the risk associated with open source component usage, without slowing down development efforts. The best strategy is to gain complete visibility into all of the components development teams are using, as well as the versions being used. Consider adding technology that can help you keep track of your component usage into your AppSec mix. Only then can security teams ensure they can quickly patch and/or update the component version when a new vulnerability is disclosed.

Do you think about the security of apps once they reach production?

Vulnerabilities will make their way through to production. Time to market often trumps security, and apps are deployed with vulnerabilities. Or maybe new vulnerabilities are introduced as applications are updated.

What if your apps could protect themselves in production, giving you time to remediate vulnerabilities without having to play catch-up with the bad guys?

Runtime application self-protection (RASP) technology identifies and blocks application security threats in real time. By adding detection and protection features to the application runtime environment, RASP enables applications to “self-protect” by reconfiguring automatically, without human intervention, in response to certain conditions.

What percentage of your developers are sufficiently trained in secure programming techniques? How do they keep current on emerging trends or access the expertise they need?

Do your developers know what to do with scanning results? Do they know how to avoid introducing the same vulnerabilities in the future? Probably not, considering even the top computer science programs do not require cybersecurity classes. Help your developers create more secure code faster with training and remediation coaching.

Pulling from our new State of Software Security report once again, the data reveals that best practices like remediation coaching and eLearning can improve vulnerability fix rates by as much as 6x.

What’s next?

Adding each of these elements to your application program will help reduce your chance of breach, without slowing development cycles. Keep in mind that application security is not a one-and-done project; your program should grow and change over time.

Where are you in your application security journey? Need guidance figuring out next steps, or explaining them to others in your organization? Check out our new eBook, Top 6 Tips for Explaining Why Your Application Security Journey Is Just Beginning.

Suzanne is part of the content team at Veracode, working to create resources that shed light on AppSec problems and solutions. 

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.