Why it’s important to have a complete application security program

Why it’s important to have a complete application security program

Security_Guest Absent Member.

Guest post by Harley Adams, Sr. Product Marketing Manager 

Last month I wrote about The Top 5 Application Security Risks Threatening Your Business based on analysis from Fortify’s Software Security Research (SSR) team in the report titled, “Application Security Research Report 2017.” Alexander Hoole gave a great webinar digging deeper into these points—check it out if you haven’t already. 

I had a chance to recently take another look at the full report, and a couple more items jumped out at me: 

1. The importance of a complete application security program that includes both static and dynamic scanning.

apps.jpgOne of the limitations of static code assessment, during development and testing, is that it does not consider the context of the resulting program when it is executing. Because dynamic analysis evaluates a program during execution, it is capable of detecting vulnerabilities that are caused by configuration and environmental flaws that are not present during static analysis and code review. However, dynamic analysis is also not able to detect certain vulnerabilities in a program during runtime because it does not have access to the underlying code. 

Static code analysis helps identify potential zero-days in organic code. A zero-day in dependencies, however, is what often creates a blind spot when the source code in the dependent library is not available to analyze or was not included in the analysis. Dynamic analysis and runtime monitoring may help compensate for those blind spots. 

2. Costly Remediation— the most efficient and effective approach is to help developers detect vulnerabilities early.

 The analysis considered issues that were both detected and fixed (triaged and closed—not necessarily remediated) within the same yearlong period. Overall, more than 70% of the issues under study were remediated (fixed directly in the application’s code or configuration). This includes 55% of issues that were confirmed to be fixed. By eliminating the issues fixed by other means not in the code, almost 85% of all triaged issues in the dataset were addressed. 

Looking deeper into the issues that were not fixed, the following were the top reasons for not fixing them:

  • the issue is to be fixed in a different module by a different team
  • the issue is to be remediated using a compensating control
  • the issue is to be deferred for a future release

 Most of the mediums and lows are fixed before the critical and high issues. By splitting the range further, almost all mediums are addressed within the first 15 days, while it takes almost two months to address the critical and high issues. This implies that certain issues with higher severity may be more complicated to fix, thus taking longer than most issues. For example, a majority of the code quality issues are fixed in the first range, while more input valida­tion and representation issues are carried over to the second range. 

If you haven’t seen the full Application Security Research Report 2017, download it now. Let me know what stands out for you. 

And stay tuned for the updated 2018 report.

0 Kudos