The Trick-or-Treating Developer
By: Melissa McKay, Developer Advocate at JFrog
Follow Melissa on Twitter @melissajmckay
Halloween is coming up! While it isn’t a holiday that everyone celebrates, it’s one that many fans associate with the tradition of trick-or-treating. Groups of costumed children swarm neighborhoods and ring doorbells so that they can haul hoards of candy home by the end of the night. Halloween is both a sweet tooth’s dream and a dentist’s nightmare. Many children walk the streets in search of sweet treasure until the last porch light dims. I have pleasant memories of Halloween from when I was young. I also remember the first time my parents insisted on carefully inspecting what I brought home at the end of the night. My family and I spread the individually wrapped treats across the kitchen table. Each one was “checked” to ensure that it had not been tampered with. At the time, I didn’t fully understand what was happening, but I’m sure you have deduced the reasoning for their concern – rumors circulated among parents about the candy in the community potentially being unsafe to eat. Thankfully, none of my efforts collecting these delicious morsels were in vain. Aside from the contribution to future cavities, my sugar consumption weeks thereafter proceeded uneventfully.
A security-minded developer knows exactly why this tale is so relevant today! Software is constantly evolving and changing. Each feature we add or bug we fix could result in adding an insecure or malicious ingredient to the mix. Developers spend their days building, testing, and packaging software. Although we may be diligently focused on the quality of the code we are writing, there is a larger portion of our software that is brought in from third-party sources or from other internal software teams. These come in the form of open-source or proprietary libraries, binaries, and other artifacts, including those that compose the supporting frameworks, building blocks, and other components needed to meet the requirements of our code. Application-level package managers like Maven, npm, and NuGet (just to name a few), gather these as “dependencies.” In the context of my analogy, these are the treats collected by trick-or-treating developers. As our software grows in complexity, the dependencies we come to rely on may also rely on dependencies themselves – brownies with chocolate chips and nuts anyone? In this way, we lose more and more control over the reliability and the safety of our own software.
Case in point: I remember the day I learned when it was important to responsibly manage Docker parent container images. Unfortunately, this was a situation when access to the image in its remote, external registry was interrupted. On top of that, the image also included an incompatible binary that required an update. Translation: our build failed miserably and repeatedly. When I say “responsibly manage,” I mean understand how the parent image is built to begin with. Did it come from a trustworthy source? Is it based on a parent image itself? Is it possible to rebuild it? Can developers upgrade necessary components regularly as security vulnerabilities are discovered? These images should be stored in an artifact management system or registry within your purview. You should be able to identify and control any changes. It is our responsibility as developers to perform the due diligence needed when we make the decision to bring in any software binary or artifact from an external source.
What should we do? Should developers just take the risk and hope for the best? Of course, one way to keep from ingesting something harmful on Halloween would be to avoid trick-or-treating altogether. With that mindset, you might prefer to make your own candy from ingredients you grow and harvest yourself. This is quite the challenge for most of us. The equivalent to this in software would be to write everything from scratch down to the ones and zeros. However, this is not a feasible task in our fast-paced and progressive software world today.
But do not fret! We are all on this journey together. The ability to use open-source and other publicly available software dependencies is one reason why developers are capable of creating and delivering the advanced software we all enjoy and benefit from today. With foundational layers available to start with, we can accelerate the development process. Given these benefits, more and more tools are available to help developers mitigate the risk. Vulnerability scanning tools are now easily accessible to a developer even before checking in to source control! If you want to learn more, visit the JFrog booth at All Things Open. Find out how you can develop and deliver your software safely with open-source projects like Pyrsia (pyrsia.io), a solution that helps protect the open-source supply chain. In the meantime, if you choose to trick-or-treat, have a safe and happy Halloween!
The Featured Blog Posts series will highlight posts from partners and members of the All Things Open community leading up to the conference in the fall.