Modern software development practices such as industrialized code reuse and artificial intelligence (AI) assistance enable developers to produce increasingly complex and capable software more quickly and cheaply than ever before. The tools to ensure that all this software is well-tested and that all of the included code is well-tailored to the deployment scenario, however, have lagged by comparison. Modern applications often include hundreds to thousands of libraries and other dependencies, with often only a small portion of the code in each being ever needed by users in each deployment scenario. The excess code that remains often tends to be less used in general, less well-scrutinized, and full of obscure features that will often be found (sometimes only years later) to contain vulnerabilities. To address this problem, numerous tools have been developed to identify bloat and then modify the software by removing unneeded code [Ref 1]. Configurations, usage logs, and tests that are fed as inputs to code transformation tools to tell them what to cut are referred to as the debloat specifications [Refs 1, 2]. Because the economics of code reuse will continue to drive library and package developers to maximize generality, debloating must happen through a separate process that begins after those components are built into a specific application. The fact that another process will be modifying code separate from the original one that designed, implemented, and tested those components adds risk—it is not uncommon to see flawed or incomplete transformations. Evaluation results in [Ref 2] showed that 37% of the debloated binaries they created failed to correctly execute the functionality they were intending to retain. Many factors can contribute to a transformation yielding a broken application, but one of the biggest is a low-quality debloat specification. Developer-authored tests are often limited and the users of debloating tools rarely can specify in exact detail all the features they actually need for a given deployment scenario. These incomplete specifications can lead tools to be overly aggressive in things like security checks and exception handlers that are critical to application safety and robustness [Ref 3]. To better address the problem of low-quality and incomplete debloat specifications, new technology is needed to more fully incorporate and automate the capturing of desired software behaviors for input to a debloat tool. The technology should be able to take advantage of code analysis as well as analysis of related artifacts such as documentation, build configs, existing tests, and even user input, as long as it can be made practical and easy for a user to answer. Various works have explored methods and techniques for capturing exception handers [Ref 3], balancing reduction with a targeted amount of generality [Ref 4], and leveraging AI to incorporate new tests [Refs 5, 6, 7]. All may inform strategies for automated test generation and augmentation that can lead to higher quality debloat specifications.
No documents are available for this record yet.