Over the past 11 years, we have explored the challenges in secure application development against the backdrop of new threats and evolving expectations in our annual State of Software Security report. For the 11th report, our focus is to look ahead and identify how developers can continue along their software development journey to make applications better and more secure.
This year, we found that most apps are still vulnerable, fix rates remain slow, and that vulnerabilities in third-party libraries are a growing problem. But we also uncovered data that highlights developer actions that dramatically improve fix rates, even under less than ideal conditions.
Read the report to gain valuable perspective on the state of software security today.
130,000
applications scanned over 12 months
/sites/default/files/white-rocket.svg
76%
of apps have at least one security flaw
/sites/default/files/white-trophy.svg
1/3
Almost 1/3 of apps have more security findings in third-party code
/sites/default/files/white-documentation.svg
17.5
Scanning via API reduces the time to fix 50% of flaws by 17.5 days
/sites/default/files/white-gear.svg
State of Software Security v11 Key Findings
The 11th volume of the State of Software Security report found that 76 percent of applications have at least one vulnerability, and that half of security findings are still open 6 months after discovery. We also found that almost one-third of all applications have more security findings in third-party libraries than the native codebase.
But we also uncovered data surrounding actions that have a significant positive effect on software security. For instance frequent scanning, using more than one testing type, and scanning via APIs all reduce the time to close half of security findings by several weeks.
For more of the top takeaways from this year’s report, check out the infographic.
What leads to this year’s state of software security? Is it nature or nurture? Is it the attributes of the app that the developer inherits – it’s security debt, its size – or is it the actions of the developers – how frequently they are scanning for security or how security is integrated into their processes? And if it’s “nature,” is there anything developers or security pros can do to improve security outcomes?
This year’s research unearthed some surprising – and promising – data surrounding ways to “nurture” the security of your applications, even if the “nature” is less than ideal.
Vulnerabilities by Language
This year, we looked at how the choice of programming language affects software security. The interesting thing about the language breakdown was the fact that the most common flaw type was different for each language. The most common flaw type in .NET applications was information leakage, while it was Cross-Site Scripting for PHP, and CRLF injection for Java applications.
Get details on the most common flaw types in your language in our infosheet.
State of Software Security v11_
