How organizations can prepare for AI accelerated vulnerability discovery

AI assisted vulnerability discovery has added a velocity dimension that can target a set of vulnerabilities together unlike ever before. The frontier model rankings are of less significance due to the temporal nature of performance that changes with releases. More important realization is that this is the new normal. While short-term outlook looks challenging, long-term indicates the potential of AI accelerated security outcomes, requiring fewer patching cycles. So what can organizations do now.

Challenges of moving fast

Incorporating secure development practices is a noble goal, however it is not an easy pivot even if an organization fully commits to it. Keeping technology aside, people and process across the organization need to adapt to the change as well, which is a big shift. Developing security posture takes time and making it the first fundamental goal may slow down adoption of new technologies and impact developer experience. Further, the pace of adoption of secure development practices can vary greatly depending on the complexity of the IT estate and processes for a given organization.

Even with a workforce trained and ready on security, an organization will likely require a phased and prioritized approach. Fundamental influences include feature releases and application availability where faster (i.e. frequent) upgrades can break applications. As an example, consider a new application feature built using latest libraries that fails due to compatibility issues with existing applications. Even if compatibilities issues do not arise, ensuring that the application itself works as expected post upgrade without comprehensive testing can result in availability issues, requiring rollbacks.

Moving fast and managing challenges

There are ways to tackle the challenges of moving fast that otherwise can jeopardize faster upgrades. The following are key options to consider:

Separating application dependencies

Separate underlying technology stack from code to identify what components can run on the latest upgrades (i.e. patched versions) without impacting the application. Typically, VM/Containers/Serverless should be able to upgrade (including fixes for mis-configs or weak configs).

Option 1 does create a time problem where eventually a subset of technology stack can no longer upgrade without breaking the supporting application. This can happen when frequency of upgrades exceeds the time it takes to resolve dependency issues on newer releases. Regardless, partitioning technology stack from application code can allow for faster upgrades and help to reduce vulnerability exposure.

When option 1 does not work (at all or eventually)?

It is a possibility that application dependencies cannot be resolved to work with the latest upgrades without significant changes. This can impact upgrade timelines. In such a situation, a custom application, running on the latest version, all the way up from underlying technology stack to the application code can be an option. Such a custom application can act as the translation layer for the unpatched applications while minimizing vulnerability exposure.

The protection provided by the translation layer depends on its ability to sanitize inputs, manage race conditions, address design issues etc., which in turn depend upon application complexity. As an example, an application using proprietary protocols/standards will likely require significant effort and customizations compared to another application built on industry/open standards. The engineering required in any case is non-trivial.

When you have a vendor software

Option 3 can be an alternative here as well. If the translation layer falls short to effectively minimize vulnerability exposure, the choice is limited other than to wait for the vendor to provide the patch/upgrade. As an example, while the translation layer may address input validation flaws, it may be limited to address authorization issues. At minimum, you should be able to leverage other control mechanisms such as a Web Application Firewall to block attack patterns (which can work as a mitigation strategy to an extent in all cases).

Getting ready with canaries

The use of translation layer will eventually hit scaling limitations as the number of applications grow owing to complexities and need for customizations. Another alternative can be canary deployments for applications on the latest versions in production as beta testing. This testing in production helps to validate if the application functions correctly with the latest releases, which can greatly improve confidence and provide feedback from the production environment. The toggle of a simple switch with disclaimers in the application can ensure that users who know what they are doing participate (likely from the organization).

The beta testing should be used for function validation in production with the goal to provide an ever-ready, fully upgraded environment that actually works successfully, proven by data. Beta here does not imply that production security controls are bypassed. It also does not replace the need for mature testing as part of production releases.

Where AI can also help (in addition to security)

Changes to infrastructure and applications are complex not because of the change to the component (alone) but also how the changes impact upstream and downstream components. As an example, a new library may no longer support or change API behavior resulting in errors. AI can help with the discovery of incompatibility issues through comprehensive testing at scale. While the effort may appear tactical, it has a strategic advantage to increase test maturity and automation where releases are benefited from a mature testing capability built over time. Improved testing can reduce application failures and increase confidence in deployments, which in turn can accelerate faster deployment cycles and reduce time to patch.

Key takeaways

Moving fast with newer releases requires additional considerations to account for upstream and downstream dependencies. While upgrades may help with patching, lack of testing and validation can result in unintended outages. Complex applications can increase dependency challenges, which may limit upgrade options. Approaches like translation layer and canaries increase readiness and reduce vulnerability exposure. The options also enable organizations to buy time when dealing with complex applications. At the same time, investment in AI can help with comprehensive testing capability to increase confidence in deployments to go faster.

NO AI TRAINING: Without in any way limiting the author’s exclusive rights under copyright, any use of this publication to “train” generative artificial intelligence (AI) technologies is expressly prohibited without author's explicit consent. The author reserves all rights to license uses of this work for generative AI training and development of machine learning language models.

Author: Anurag Jain