Excelling at application vulnerability assessments is hard, even for the most seasoned organizations. On a surface level, assessing vulnerabilities seems easy: plug-and-play your favorite vulnerability scanning tools, and off you go! However, every security practitioner on the face of this Earth knows that getting the greatest value from even the best tooling takes time, skill, and patience. If assessing vulnerabilities were a mere matter of deploying and tuning tools at the outset, AppSec teams would gladly invest heavily on the front end to get impactful results over the long run. They would be able to siphon only relevant issues to developers, accompanied by easy-to-follow instructions, making application vulnerability remediation straightforward and efficient.
The reality is, though, that application vulnerability assessments have to be part of a holistic program — “program” being the operative word here. To actually achieve excellence, AppSec teams have to build vulnerability assessment programs with defined processes for iterative and ongoing reworking of both strategies for assessing vulnerabilities and tactics for tuning tooling. The program should be centered on how to help the business keep pace with adversaries — especially adversaries keyed into the complexities of modern software development and the depth and breadth of the software supply chain.
If running a bunch of vulnerability assessment tools were enough, the typical AppSec team wouldn’t be dealing with an average of 119,000 alerts at any given time, nor would they have the challenge of deciphering which identified vulnerabilities are relevant to their business, their organization’s software development efforts, and to the individual applications in their pipelines. But talk to any AppSec or DevOps professional and you’ll know that the struggle is ubiquitous; everyone has too many alerts, too many false positives, not enough context for effective prioritization, lack of integration between disparate data sources, and not enough human hands to manually fix every issue.
When it comes to application vulnerability assessments, it’s quite common for both AppSec teams and AppSec vendors to center programs and solutions around the National Vulnerability Database (NVD) list of CVEs, the OWASP Top 10, MITRE Top 25 CWEs, security vendor reports, and analyst reports. Although these sources supply a foundation, they are only a fraction of necessary inputs for any assessment program.
To accurately and effectively assess application vulnerabilities, security teams must build an AppSec program with processes that encompass a combination of strategic practices, tools, and methodologies. OX Security’s list of seven best practices for assessing application vulnerabilities includes:
Routine vulnerability scanning: AppSec teams must build a vulnerability assessment program that starts with regular and automated vulnerability scanning. Importantly, to thoroughly assess the organization’s application security posture, scanning tools must cover the gamut of testing types, from scanning code, open-source libraries, and software dependencies, to scanning the environments in which applications are built, tested, patched, and deployed. Security testing that is integrated with the CI/CD pipeline and covers the entire SDLC is the only way to set a foundation for a successful AppSec program.
Risk-based vulnerability prioritization: As mentioned earlier in this article, many AppSec programs and vendor tools rely heavily on CVEs/CVSS to determine the severity of identified vulnerabilities. However, the people at the NVD never meant for the CVSS to be the final word in vulnerability severity. For greater prioritization accuracy, each organization must have a method to assess vulnerability context, reachability, exploitability, and potential business impact. Not every vulnerability with a “critical” CVE score will be critical for every organization, so applying that context is crucial to the efficacy of the program and the security of the organization’s software.
Threat modeling: Needless to say, as with contextualized prioritization, every business is going to have a unique attack surface, infrastructure, and business risk tolerance. This is why AppSec teams must work with security and risk colleagues to map out application architecture, data flows, dependencies, developer coding practices, and other relevant factors that impact that business’s threat landscape. To remain effective, threat models should be reviewed and revised as both internal and external elements evolve.
Dependency mapping: To simply identify potential issues, understand the effect(s) of a compromised component or module, and make substantive changes, AppSec teams should incorporate dependency mapping — a visual representation of the components and modules used in software development. Doing so clearly illustrates component and module relationships, allowing teams to build more resilient systems.
Continuous monitoring: Valuable security programs incorporate continuous monitoring to ensure that issues and anomalies are identified, flagged, and triaged as quickly as possible. AppSec teams should employ automated monitoring and analysis for development and runtime environments, networks, clouds, containers, access controls, and other policies that will reveal suspicious application activity. Further, teams will benefit from integration, normalization, deduplication, and correlation of data across these tools, simplifying the process of finding the real threats among the noise.
Measuring and reporting: The best and fastest way to improve any security program is through consistent tracking and measurement. Teams should use data from any deployed tools to answer questions like: How many high-severity issues were identified? What was our mean time to remediation last week/month/year? Are response times improving over time? How does the introduction of more secure coding practices impact delivery times? The number of found issues? The risk posture of the organization? During what stages of the SDLC are the most vulnerabilities/high-severity vulnerabilities identified?
Penetration Testing: Complement AppSec and general security tool testing and monitoring with periodic manual penetration testing run by internal red teams and external experts. The combination of testing methodologies will ensure comprehensive analysis of applications, network environments, and human actions. In particular, testers should look for weak or non-existent authentication, business logic flaws, incomplete or missing logs, race conditions, server misconfigurations, query manipulation, and other common application vulnerabilities that standard tools may miss, thereby increasing the organization’s risk posture.
Conclusion
A robust application vulnerability assessment program goes beyond deploying tools — it’s about establishing processes that align security with the business’s broader goals and keeps the business out of the crosshairs of potential attackers. Effective vulnerability management programs allow organizations to shift left, making certain that security is an integral part of the development lifecycle — one that doesn’t slow down development efforts to account for faster vulnerability detection and remediation. Moreover, incorporating a risk-based focus ensures that AppSec efforts can be iterative and manageable, allowing teams to agilely adjust as the threat landscape evolves.
C
