Top 5 Tips for Securing Your Dev & Test Environments, and Why You Should

In his seminal work, The Mythical Man-Month, Frederick Brooks Jr. tells us that software development is homologous to a tar pit where many efforts flounder regardless of the appealing nature of the task or the relative tractability of the underlying physical medium. In what he calls one of the "woes of the craft", the author goes on to explain that the pervasive optimism among programmers regarding the conception of a software project is rarely maintained after we take into account the set of complex interdependencies commensurate with others' skills and objectives. With the understanding that security concerns are a fairly recent addition to the development lifecycle—at least to someone akin to the inherent programming paradigms of the late seventies like Dr. Brooks, one aspect remains unequivocal: programmers are commissioned with the sort of creative work that is unrelentingly attached to the pursuit of perfect usability. This is true, for example, when designing Application Programming Interfaces (APIs)—the set of exposed, intermediary function calls and routines responsible for providing high-level access to predefined software resources and applications whose latticework of dissimilar technologies can be notoriously difficult to secure. It is also common knowledge that to acquire even a subtle resemblance of functionality, software projects must first be anchored to an adequate test environment whereby code isolation can be properly conducted and application behavior safely observed. To the developers, these test environments usually present a number of additional advantages such as access to a broader collection of user data, or to specific backend system logs that would normally be under tighter scrutiny and more robust security controls. This blog post will explore some of the cyber risks associated with insecure development environments and the challenges and trade-offs that system architects must be willing to face in safeguarding them, along with some quick tips and recommendations for the road ahead. Risks of dev environments, and why they get hacked There is no doubt that test environments are a necessary evil. The very tools and applications we've all come to know and love can attribute their primordial existence to one or more of these ecosystems as they relate to the Software Development Life Cycle, SDLC. The staggering rate at which organizations are pushing the software development envelope, and the multitude of choices they face when it comes to hosting platforms or container alternatives, demands evermore careful planning and consideration. Think about iterative approaches like Agile—conceived against the backdrop of the requirement for businesses to deliver results more quickly and more safely in consumable but manageable increments. Think also of the myriad refinements, use cases, code reviews, fuzzing techniques and, more recently, chaos engineering practices modern distributed applications must endure to be deemed production-ready. None of this would be achievable, at the proper scale, without the controlled conditions that exist in a test development environment. That much flexibility and observability, however, comes at a price. For example, test environments are known to have less rigorous security measures and granular controls than a typical 'live' environment would—all under the aforementioned banner of agility. Very frequently, providing developers with this much-desired flexibility is a convoluted effort: too narrow, the privileges and programmers can be trapped in an endless barrage of access woes leading to loss of productivity and missed deadlines; too much access, and the possibility of a data breach increases dramatically. This is similar to what took place in 2018 when Shutterfly, an image sharing and printing company, warned that an employee's credentials had been leveraged by an unauthorized source to gain access to test environments storing a treasure trove of pers...