'Playing Around' with Code Keeps Security, DevOps Skills Sharp

Put six adults together for 41 hours with a pile of parts and a vague goal and what do you get? In my case, amplified lessons in secure software development — and a game where you take a robot to do battle.

So last weekend I participated in a make-a-thon. Described as "like a walk-a-thon with less walking and more making," it was a fund-raiser and a way for me to scratch my ongoing geek itch. Since mechanical engineering isn't my forte, I was assigned to be half the programming team. And, as is true for so many real-world dev projects, we began on Friday night with only a vague sense of what the hardware would ultimately look like.

So the first thing I did was sit down, write careful specifications, and start hand-crafting the finest in artisinal code, right? Of course not: I headed for the Internet and started grabbing routines described as doing what I wanted to do. And just like that, I was neck-deep in the reality of most agile and dev-ops software shops.

Now, I was lucky in several respects: I was doing classic OT stuff in a variant of C — I could look at the code and tell what was going on. But the thing that struck me in retrospect was just how easily I was grabbing routines and throwing them into my application, and just how little regard I was giving the variables and code that didn't have an immediate impact on my job.

So that's the first amplified lesson: do a security scan on downloaded code before you slap it into your application. GitHub's Semmle acquisition should make this easier for a lot of open source projects, but it's got to be considered a critical step regardless of where the code comes from.

The next amplified lesson comes straight out of the instructions for blue jeans: Shrink to fit. At times during the development process we had great herds of unused variables and function names roaming across the rolling plains of our code. The combination of code from repositories and debugging routines left detritus that we ultimately had to clean up late in the process because things were getting confusing.

Unused variables and routines left in code are catnip for attackers. In the heat of a sprint (or a 41-hour deadline), it's too easy to leave things in place rather than cleaning up as you go. But even in cases where you go back at project end and clean up the code, be careful — it's all too easy to miss lines tucked up under comments or buried in the middle of complex routines.

As the hardware specs matured, we were able to do more testing and pruning, but we were also passing code back and forth more and more frequently. And that brings up the third amplified lesson: be sure your team communication mechanisms are secure.

In our case, security wasn't a great concern — in the worst case of intrusion, a toy robot would get whacked by a wooden hammer. But where we ended up tossing code back and forth on our team's Slack channel, code that truly matters to, oh, anyone, should be shared in a secure private repository. Since there were only two of us, we also didn't have a lot of trouble figuring out who had last touched a given piece of code. With a larger team a more rigorous change process is critical for both security and reliability.

The last amplified lesson I learned is the one that will, I think, have the longest impact: It's important to get out there and do stuff. It had been a while since I buckled down to a software project with a deadline and expectations that came from someone other than me. It was fun, it was exhausting, and it was educational in all the best ways. It's easy to fall into a pattern of tossing out opinions gathered from other sources, but it's important to get some hands-on time to check your assumptions and find out just why those opinions are right (or wrong).

Oh, and the make-a-thon? My team won, largely because the teammates who took on those mechanical engineering roles were really good. As for the code — well, we've still got two months before the next time the project shows up in public and there's some display driver code that needs serious attention…

Related content: