
The security of business applications remains poor, according to a new state of software security report. The percentage of apps with high severity flaws has swelled by 181 percent in the last five years, the time taken to fix flaws is up by 47 percent over the same period, and 70 percent of applications have security issues in third-party code.
The data was gathered by software security company Veracode from scans conducted via its platform, covering nearly half a million applications. The majority of the data comes from static analysis, supplemented by dynamic application security testing (DAST) and software composition analysis (detecting open source components in use).
According to the report most applications (80.3 percent) have some flaws, and 47.7 percent have issues among the OWASP (Open Worldwide Application Security Project) top 10 web application risks, such as broken access control, cryptographic failures, injection vulnerabilities, security misconfiguration, or vulnerable/outdated components.

It is notable that more security issues are found in third-party libraries or components (70 percent of applications) than in code written specifically for an application (64 percent); and that the issues in third-party code tend to be more severe. The report states that three in ten organizations have more than 96 percent of their critical security debut in third-party code.
The report has a section focused specifically on open source code, stating that while the proportion of security debt tied to such code is “fairly low,” it nevertheless has a high proportion of the most critical flaws. A further problem is that issues in open source code tend to take longer to fix, with a half-life of 12 months compared to 8 months for first-party code.
There are multiple reasons why third-party code may be more problematic for security. Libraries may have many dependencies, which cannot be updated easily because of breaking changes in newer versions, or because an open-source project has become less active and is no longer well maintained. Refactoring an application to remove one library and replace it with one that is more secure may be difficult.
Assessing the real risk of a vulnerability takes more than static analysis. Some security issues detected as high severity may not be relevant because they involve functions that are never called, or are prevented by other security measures in place. “Modern software security is about remediating real risk which requires contextualizing more,” say the report authors, though this is a non-trivial task.