Application Security - Thoughts & Considerations

Introduction

In many ways, traditional Application Security is among the easiest of established cybersecurity sectors to understand: at the highest of levels, developers leverage a broad combination of pre-packaged Low/No Code capabilities, custom coding, and other DevTools / Platforms to develop & integrate home-made code, copy-pasted open source / container functionality, and APIs / integrations to develop a functional application. Throughout the design & deployment process, these applications are continually tested for functional & security flaws, and subsequently released via provisioned infrastructure and monitored post-deployment in the cloud. Simultaneously, applications are subject to constant, automated code scans, test scenarios & other QA / QC feedback loops to ensure they remain error & breach-free.

However, as we all know, the reality of Application Security is more akin to the wild west, particularly within 2023 and looking ahead. Frameworks have long-since shifted from periodic waterfall releases to near real-time CI / CD & DevSecOps approaches, driving pressure to coordinate the efforts of dozens (or hundreds!) of developers for rapid daily / weekly releases, while integrating with an ever-growing array of cloud infrastructure & additional third-party vendors. This has led to a massive effective increase in the contemporary application attack surface: more developers, working with more custom + open source (and now AI-generated!) code, across more applications, each with more interactions – all releasing & updating on an exponentially faster basis. And a quick look at Veracode’s State of Software report confirms what we all know --> that applications continue to release under imperfect conditions, with vulnerabilities abundant. Over a 3-month period, 50% - 70% of flaws are likely to remain unaddressed – even after a year, there’s still a 25% - 40% chance that these issues remain.

This application security blog hopes to provide a clear, layman's view of:

I. “Traditional” Application Security – A high-level overview of the bulk of the core market today

II.?Currently Rising Trends – An introduction to newer themes & rising areas to watch within

III. Speculation On Future Challenges – Speculation on upcoming challenges & evolution of the application threat landscape as innovation continues to press forward

I. Level Set: Traditional Application Security Overview

Historically, Application Security has revolved around several views of “testing or scanning” an application, designed to help customers identify, prioritize, and reduce flaws within an application, as well as protecting it in runtime. Presumably, these large categories have historically compromised the majority of the relevant application security market – logically confirmed by looking at several of the largest vendors’ solution offerings (Veracode, Checkmarx, Synopsys, Snyk, Contrast, etc.). Historically, CISOs, Dev teams, and other Application Security practitioners have leveraged some combination of the below to test applications, identify flaws, and subsequently fix poorly-functioning or risky application code in a fairly simple, repeatable process (build code, scan / test code, fix code, scan / test code, rinse & repeat):

1. SAST: Static testing generally scans the code comprising an application at any time, typically searching for any known flaws / misconfigurations at the code-level, and will surface a view of known / discovered errors, ideally with a view of severity / relevance to facilitate prioritization. Given that this is an “inside out” code search and may not require a functional application, this is often logically the “first line of defense” within the QA / QC cycle, and can identify exactly which lines of code need fixing, even before the app is finished
2. DAST: Dynamic testing works inversely to SAST, essentially running simulated black-box attack testing on a functional application from an “outside in” vantage, gauging how the application reacts. DAST’s major advantages are also its drawbacks – it requires a functional application and simulates “in the wild” attack & engagement activity to surface functional / security flaws; however, this back-loads testing and may not point developers to the code lines requiring fixing, and ultimately depends on the efficacy of the tests
3. IAST: For lack of a better technical term, interactive testing often brings the best of both worlds – it scans & executes code from within the application, with full access to code, runtime control, information flows & requests, etc, which help both identify flaws, as well as point to the relevant code issues (both in development & production). However, it certainly does have drawbacks (language-dependent, only scans executing code, and requires a functional application)
4. SCA: Provides visibility into code composition, identifying open source / third-party code and facilitating security / compliance / licensing analysis.
5. RASP: Sits within an application / runtime environment and approves / prevents code execution, essentially identifying & preventing attacks in real-time

II. Rising Trends – Areas To Watch

As mentioned in the introduction, traditional application security is beginning to fall short – if anything, primarily as a result of the exponential attack surface increase & the application network effect, combined with a lack of developer capacity. Organizations no longer leverage small handfuls of isolated on-prem applications updated with periodic releases; rather, the 2023 landscape looks more like dozens (if not hundreds) of hybrid / cloud applications to secure, with increasingly frequently releases, each with massive open source components, all interacting & integrating with one another, and there are only so many developers available to fix flaws. Gartner is seeing applications themselves – as well as the complexity of both applications themselves as well as the infrastructure they’re deployed in – growing magnitudes in complexity, and so must the solutions used to effectively manage risk.

What once might have been 10-20 individual applications for a company to manage has now evolved into what could be dozens (or hundreds!) of different applications – each more complex and connected than the applications of past, all needing to integrate & function coherently. As a dangerous combination, faulty open source code can proliferate more & more quickly, potentially placing the entire backbone of application security at risk (e.g. Log4j). The overarching theme at the moment represents the million dollar question – which applications are at risk, which risks poise the greatest threat to me, and what is the economic / security risk we’re currently facing with our current posture?

Evaluating the current landscape, Application Security practitioners can leverage several next-gen extensions to further enhance their overarching Application Security posture:

1. Application Security Posture Management: Though nothing new on paper relative to the rest of security innovations, the concept of applying correlation, automation, and orchestration (read – SOAR for Apps) across a wide number of applications, their environments, and varied data sources can be quite effective in centralizing & unifying a view of organization-wide application security & risk posture. Do we prioritize a low-risk vulnerability in a high-priority application, or a high-risk vulnerability in a low-priority application? Where is the root cause of this issue, and what tests, changes or policies are required to address this successfully? If implemented successfully, ASPM can address these key questions and help maximize the efficacy of existing SAST / DAST / IAST capabilities with improved reporting, prioritization, & triage, and can even be digested into a broader bucket such as XDR to play a factor in overall enterprise security posture.
2. Incorporating Application Relationship Behavior: Though not necessarily unrelated to ASPM above, this angle is absolutely worth a call-out given the importance it plays in determining overall application risk. At this stage in innovation, applications quite frequently interact with users, data sources, and each other – via reading, writing, or both. Tracking & controlling these relationships can add critical information to existing ASPM above – what if that low-priority application has a high-risk vulnerability, AND read / writes to a high-priority application that doesn’t appear to have severe vulnerabilities on a standalone basis? What if the application IS secure, but shouldn’t be accessing this data, or accessible by certain users? Combining microsegmentation / policy control can also accelerate time & efficacy of response by alleviating this issue with real-time control & rollback capabilities.
3. Shift Left? Or Shift Right?: In an ideal world, applications would be developed, tested, and released flawlessly – however, at current rates, we all know this will likely never be the case. Instead, technologies such as RASP, CNAPP, etc. bypass the code scans, opting to focus instead on securing & monitoring the application (or its underlying environment) in motion, ideally providing functional security, regardless of innate / coded security
4. SCA Becomes SBOM: As witnessed by Log4j and too many similar threats, securing the software supply chain continues to be a critical component within application security. GitHub cites over 97% of applications leverage open source, while RedHat cites almost 90% of IT leaders believing enterprise open source to be as or more secure than in-house, and Synopsys estimates over 75% of codebase composition is open source. Even if both facts are true, third-party code continues to be a critical component of security – if for no other reason than the magnitude of impact upon a critical breach across numerous enterprises integrating the same flawed code (see Log4j & similar cases). While SCA is nothing new, the idea of generating and sharing / comparing that “composition – or bill of materials” with other vendors within the ecosystem has garnered traction recently, with a plethora of younger vendors facilitating the packaging, sharing, analytics, vulnerabilities – and even managing the open source developers to facilitate a more external-facing view of software vendor risk.

This is far from comprehensive, however, if you’re still with us, our overall point thus far is that application security has actively evolved from a siloed app-by-app viewpoint into a more well-informed, overarching application security strategy designed to focus on multiple internal & external factors. We are well past days where individually testing each application will suffice at the enterprise-level; instead, the contemporary vendor must view application tests within context, evaluate SBOMs of key vendor integrations, monitor application behavior, interactions & access, and bear greater responsibility for copy / pasted code & containers.

III. Speculating On Future Challenges

The future is always unknown, and we’ve seen overall technology innovation drive critical cybersecurity threats & opportunities on the flip of a dime – from the inception of the internet, to cloud, to recent interest upticks around AI / LLM capabilities. As such, it’s fun to ponder on the future of application security – even though we could be entirely incorrect! Below are several key themes we believe may play a role in shaping Application Security over the near & far-term:

1. Regulations May Tighten Around Software Supply Chain Reporting & Disclosures: The prevalence of open source at the enterprise-level today is much akin to an entire college copying off one another’s exams – and among other instances, Log4j is a prime example showing that if one student fails, the whole university falls as well. While the government is already implementing SBOM requirements at the federal / agency level, we see it likely that over time, this evolves into SBOMs becoming critical for nearly every enterprise. This may not be a direct mandate (e.g. “all enterprises must provide SBOMs”), but may be a foreseeable indirect network effect (e.g. if Microsoft serves the government, Microsoft needs an SBOM, so every vendor working with Microsoft may need an SBOM – which is a massive pool of vendors). This effectively would extend SBOM to an nn type model – where vendors need to evaluate i) their own software; ii) the software of their suppliers, and iii) their suppliers’ suppliers
2. Generative AI Will Throw A Wrench In Application Security: We clearly currently have existing solutions for custom code & open source code (scanners that look for known vulnerabilities / misconfigurations). Generative AI has already been utilized for developing & finding code – but where does this come from? (Is it being created afresh? Pulled from open source, but not tagged as such? Could it be pulling from a faulty LLM training model?) DevOps cycles are already moving incredibly quickly, but as Generative AI increasingly shifts into mainstream development, this may introduce an added need for code-signing, alternative vectors for software supply chain management, and “unknown unknowns” into the model, and may require i) absolutely secure underlying LLM training data or ii) a more logic-based ability to inherently scan / test code, beyond solely searching for “known knowns”
3. Automation, Automation, Automation!: Code creation & updates will clearly continue to proliferate faster & faster – likely beyond the rate of developer headcount / capacity. Some level of automated remediation will likely be essential, and we’ve already seen Veracode snatch up Jaroona’s automated remediation assets last year. Whether these will be real-time “one-click” suggestions to the developer, an automated code-fix tested in virtualized environments before automatically updating the live repository, or a future, alternative solution, it’s not insane to imagine an era of relatively automated patches – at minimum for the most egregious flaws
4. AI Can Help Too!: While AI can absolutely harm security posture (via introducing unknown code, or providing hackers with new tools to attack applications), it can absolutely be a blessing as well. How many lines of code have been scanned over the last year? Last decade? Though we doubt this is a 2023 release, we wouldn’t be surprised if larger vendors save historical learnings from various code tests & scans, aggregate the data / learnings, and apply AI to provide a more “code-logic-based” AI solution ?that can address many of the unknowns created by new code / threats / AI itself. After all, if AI can understand code well enough to help attackers break it, it can absolutely understand code well enough to help protectors play defense

Closing Thoughts

Application Security is quite an interesting space ripe for innovation & evolution – and at minimum, we hope after reading this you’ll agree! Over the last year or two, we’ve already witnessed a sharp shift in the space from siloed scanning towards a more cohesive, collaborative framework of overall application posture management, and with the rise in AI, we anticipate this will continue at very least – if not accelerate! Whether a security practitioner, early-stage VC, or just a curious reader, we remain excited about the space and more than happy to extend our network & have a coffee or conversation!

NightDragon is committed to staying at the forefront of the Application Security landscape, supporting and collaborating with founders developing cutting-edge security solutions, investors in these technologies, or vendors / CISOs seeking appropriate implementation opportunities. If this interests you whatsoever, we’d love to hear from you!

?