AppSec Mistake No. 1: Using Only One Testing Type
We’ve been in the application security business for more than 10 years, and we’ve learned a lot in that time about what works, and what doesn’t. This is the first in a blog series that takes a look at some of the most common mistakes we see that lead to failed AppSec initiatives. Use our experience to make sure you avoid these mistakes and set yourself up for application security success.
The myth of the AppSec silver bullet
There is no application security silver bullet. Trying to pick the “best” testing type would be like trying to pick the best eating utensil – fork, knife, or spoon? Well, it depends on the meal and, ultimately, each plays a different role, and you need all of them. Morning cereal? Spoon best. Steak dinner? Knife would be good, but not so useful without a fork. Think of application security testing types the same way – each has different strengths and weakness and are better in different scenarios, but you won’t be effective without taking advantage of them all.
Why you need both static and dynamic analysis
Effective application security programs analyze code both statically in development and dynamically in production. Why are both these testing types required? Because each find different types of security-related defects. For example, dynamic testing is better at picking up deployment configuration flaws, while static testing finds SQL injection flaws more easily. We examined this issue in one of our recent State of Software Security reports. These were the top five vulnerability categories we found during dynamic testing:
1. Information leakage
3. Deployment configuration
Two of these were not in the top five found by static testing:
- Encapsulation (dynamic found in 39% of apps; static only in 22%)
- Cross-Site Scripting (sixth on the static list)
And one category — deployment configuration — was not found by static at all.
In addition, effective application security secures software throughout its entire lifecycle — from inception to production. With the speed of today’s development cycles — and the speed with which software changes and the threat landscape evolves — it would be foolish to assume that code will always be 100 percent vulnerability-free after the development phase, or that code in production doesn’t need to be tested or, in some cases, patched.
Why you need software composition analysis
Applications are increasingly “assembled” from open source components, rather than developed from scratch. With the speed of today’s development cycles, developers don’t have time to create every line of code from scratch, and why would they, when so much open source functionality is available? However, neglecting to assess and keep track of the open source components you are using would leave a large portion of your code exposed and leave you open to attack. Effective application security entails both assessment of your first-party code, plus assessing and creating a dynamic inventory of your third-party code.
Why you need manual penetration testing
Automation alone is not enough to ensure an application is thoroughly tested from a security perspective. Some flaws, such as CSRF (Cross-Site Request Forgery) and business logic vulnerabilities, require a human to be in the loop to exploit and verify the vulnerability. Only manual penetration testing can provide positive identification and manual validation of these vulnerabilities.
Learn from others’ mistakes
Don’t repeat the mistakes of the past; learn from other organizations and avoid the most common AppSec pitfalls. First tip: Don’t rely on one testing type; that’s like trying to eat all your meals with only a spoon. Effective application security combines a variety of testing types and assesses security throughout an application’s lifecycle, from inception to production. Get details on all six of the most popular mistakes in our eBook, AppSec: What Not to Do.
Related Posts
