This article is based on reporting originally published by SD Times, sourced from the 2017 Application Security Report published by Cybersecurity Ventures and sponsored by Code Dx.
The Scale of the Problem
Software development has never moved faster—and neither has the attack surface that comes with it. According to the 2017 Application Security Report, approximately 111 billion new lines of software code were projected to be written in 2017 alone. Each line introduces the possibility of a defect, and a meaningful subset of those defects are exploitable security vulnerabilities.
The report was blunt about the state of application security at the time: “Applications have become inviting targets for malicious actors, but securing those programs has proven to be challenging to both security teams and developers. Too often, key vulnerabilities get buried in a blizzard of information created by tools unable to prioritize defects in software.”
That signal-to-noise problem—where developers are overwhelmed by vulnerability reports they cannot prioritize—remains one of the central challenges in AppSec today.
Why Application Security Is a Distinct Discipline
A common misconception is that cybersecurity is primarily a network-layer problem—firewalls, intrusion detection, endpoint protection. Application security operates at a different layer entirely: the code itself.
Anita D’Amico, then CEO of Code Dx, framed the human side of the challenge clearly: “In general terms, it means getting the workforce to comply with security processes. With respect to application security, it means getting the software developers and testers to recognize the need to find and fix application vulnerabilities early in the SDLC.”
Shifting security left—catching vulnerabilities during development rather than after deployment—reduces remediation cost, risk, and time to market for secure software. This principle was well established by 2017 and remains foundational to DevSecOps practice.
The Recommended Approach: SAST + DAST + RASP
The report advocated for a hybrid testing model that combines three complementary techniques:
- Static Application Security Testing (SAST): Analyzes source code, bytecode, or binaries without executing the application. SAST tools can be integrated directly into the IDE or CI pipeline, giving developers immediate feedback on vulnerabilities as they write code.
- Dynamic Application Security Testing (DAST): Tests a running application by simulating external attacks. DAST finds vulnerabilities that only manifest at runtime—such as authentication flaws, injection points, and insecure configurations—that static analysis cannot detect.
- Runtime Application Self-Protection (RASP): Embeds security controls directly into an application’s runtime environment. RASP can detect and block attacks in real time, from within the application itself, rather than relying solely on perimeter defenses.
The report noted that RASP’s value extends beyond production protection: “RASP was created to protect applications under attack in real time, but, when combined with dynamic testing, it has proven to be useful in helping developers prioritize vulnerability findings. That not only reduces the risk of an app making it to market with a major security defect but it accelerates the time it takes to put a secure app in a user’s hand.”
Integrating AppSec into the Development Workflow
One of the report’s core arguments was that security testing must become a native part of the development process, not an afterthought or a separate audit gate. D’Amico described the practical implementation:
“Software developers and testers can build security testing directly into their development environment. They can make it a normal part of the development process, not a resource-intensive additional activity. A new breed of AppSec tools, called Application Correlation and Management Systems, embeds the source code testing tools into the integrated development environment, and interfaces with continuous build servers like Jenkins and with issue trackers like JIRA.”
This integration pattern—AppSec tooling connected to the IDE, CI server, and issue tracker—is now a standard expectation in mature DevSecOps pipelines. The report was describing, in 2017, an architecture that many organizations are still working to fully implement.
The Role of Automation
Given the volume of code being produced, manual security review cannot scale. The report highlighted automation as a critical enabler—automated scanning must be embedded in the build pipeline so that every commit is evaluated for security defects without requiring manual intervention for routine checks.
Automation also addresses the prioritization problem. When tools generate thousands of findings, developers lose confidence in the results and begin to ignore them. Modern Application Correlation and Management Systems aim to aggregate results from multiple tools, deduplicate findings, and surface the highest-risk issues first—making the output actionable rather than overwhelming.
Market Context (2017 Projections)
The report projected significant market growth for application security, estimating expansion from approximately US$2.24 billion in 2016 to $6.77 billion by 2021. Steven C. Morgan, founder and editor-in-chief of Cybersecurity Ventures, noted that AppSec was expected to outpace overall cybersecurity market growth:
“While we anticipate 12% to 15% year-over-year growth of the cybersecurity market through 2021, our synthesis of various research has led us to expect the application sector will grow by 16% to 18% during that period.”
These figures are presented as they appeared in the original 2017 report. Actual market outcomes may differ.
Key Takeaways for DevOps and Security Teams
- Volume demands automation: At the scale of hundreds of billions of lines of code annually, manual review is not a viable primary control. Automated SAST and DAST in CI/CD pipelines are baseline requirements.
- Prioritization matters as much as detection: Tools that generate unprioritized lists of thousands of vulnerabilities create alert fatigue. Invest in tooling that ranks findings by exploitability and impact.
- RASP complements preventive testing: Even rigorous pre-deployment testing will miss some vulnerabilities. RASP provides a runtime safety net and can generate telemetry useful for improving testing coverage.
- Security must be a developer workflow concern: Security gates at the end of the SDLC are too slow and too expensive. Embedding security tooling in the IDE and CI server makes it part of normal development rather than an exception process.
- AppSec is not the same as network security: Organizations that focus exclusively on perimeter and network defenses leave application-layer vulnerabilities unaddressed. A mature security posture requires both.
The 2017 Application Security Report was published by Cybersecurity Ventures and sponsored by Code Dx. Original coverage appeared on SD Times.