As software development increasingly relies on external collaboration, organizations face new risks of intellectual property leakage beyond traditional concerns about deployed software. Even when the source code is protected, adversaries may infer sensitive internal program specifications by observing the program behavior during the development and testing phases.This paper addresses the problem of specification leakage through behavioral observation in collaborative software development. We propose a novel software development method that centers on specially crafted test doubles referred to as secure mocks. Secure mocks serve as drop-in replacements for original components during development and testing while preventing the exposure of sensitive internal specifications through observable behavior. We formalize the correctness conditions for secure mocks and define the secure mock construction problem as a constraint satisfaction problem parameterized by the program to protect, the development specification, and a security policy. Our approach enables secure test-driven development (TDD) with external collaborators, bridging the gap between traditional TDD styles. We discuss the implications for secure collaboration with external developers and outline future research directions for automating secure mock generation and integrating this paradigm into real-world development pipelines.

Third-party libraries are widely used and constantly evolving. When migrating client code to a new API, a major challenge is editing client code to adapt to incompatible changes of the API. Some tools provide automated migration that synthesizes a generic patch from migration samples in a pair of beforeand after-migration snippets. However, they still have limited applicability due to the difficulty in retrieving an adequate pair in which before- and after-migration snippets invoke the sourceand destination-API of the migration respectively. In this paper, we present AUTOMIG, which addresses the problem by a patch synthesis from a single API usage example that invokes the destination-API. Due to the absence of a beforemigration version of the API usage example, it is nontrivial to find out the invariant context of API invocation through the migration. To synthesize a patch that preserves the context in the client code, AUTOMIG synthesizes patches in two-stage patch synthesis procedure. The first stage synthesizes a generic patch to describe a replacement of API. The second stage modmes the generic patch to preserve the context of the API invocation in the client code. Our experiment using a dataset that provides real-world Java codes shows that AUTOMIG synthesized a correct patch for 92.2% of the code on average. Our manual investigation on synthesized patches shows that AUTOMIG can synthesize highquality patches that preserve the context of API invocation of each client code.