Overworked developers write vulnerable software.

Dave Bittner: [00:00:03] Hello everyone, and welcome to the CyberWire's Research Saturday, presented by Juniper Networks. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities, and solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.

Dave Bittner: [00:00:25] And now a quick word about our sponsor, Juniper Networks. NSS Labs gave Juniper its highest rating of "Recommended" in its 2019 Data Security Gateway Test. To get your copy of the NSS Labs report, visit juniper.net/SecureDC, or connect with Juniper on Twitter or Facebook. That's juniper.net/Secure DC. And we thank Juniper for making it possible to bring you Research Saturday.

Dave Bittner: [00:00:55] Thanks also to our sponsor, Enveil, whose revolutionary ZeroReveal solution closes the last gap in data security: protecting data in use. It's the industry's first and only scalable commercial solution enabling data to remain encrypted throughout the entire processing lifecycle. Imagine being able to analyze, search, and perform calculations on sensitive data, all without ever decrypting anything – all without the risks of theft or inadvertent exposure. What was once only theoretical is now possible with Enveil. Learn more at enveil.com.

Anita D'Amico: [00:01:34] I have been interested in human factors for quite some time. I am an experimental psychologist by education, and I work in the area of application security.

Dave Bittner: [00:01:45] That's Dr. Anita D'Amico. She's CEO at Code Dx. The research we're discussing today is titled, "Human factors that influence secure software development."

Anita D'Amico: [00:01:56] So, I was very interested in the human factors that affect secure code development. I recently was the principal investigator of a research project funded by DARPA to study what are the characteristics of software developers, of development teams, and what are the work conditions that affect secure code development? So, I recently was working on a research project that studied the human factors that affect whether or not code is going to have vulnerabilities in it.

Dave Bittner: [00:02:30] Well, let's explore that some. That's fascinating to me because I think it's so easy – particularly when it comes to all this technology – to think sort of in the cold terms of ones and zeroes, and so on and so forth. But what you're looking into here is the fact that those real-world, everyday human factors that we deal with can actually find their way into the security of code.

Anita D'Amico: [00:02:53] Absolutely. Software is written by people, and people perform differently depending on the circumstances. So, if human factors affect how well a pilot pilots an airplane, if it affects truck drivers, if it affects medical doctors, why wouldn't human factors affect how well a software developer develops code? And I was specifically interested in the human factors that affect both code quality and security. I was a bit more interested in code security.

Anita D'Amico: [00:03:27] And there's been very little research done in this area, so the first thing we did was we did a literature review where we found out what are some of the prior studies that were done that would perhaps shed light on the human factors that affect whether or not there's vulnerabilities in software. And most of the work has previously been done in open-source. And so, we developed a way of mining open-source repositories for indirect measures of human factors.

Anita D'Amico: [00:04:02] For example, we looked at the time of day that code was committed. And there are other studies that have also looked at the time of day when code was committed to find out if it had an effect on code quality or code security. One of the things that I'll be talking about at the RSA presentation is the results of that study. I'll give you a little bit of insight that code is buggier when it's committed between midnight and 7:00 AM.

Dave Bittner: [00:04:35] Huh. I suppose that shouldn't be surprising, but I can't help thinking about that situation that I think so many development teams find themselves in, which is you've got this deadline coming up, and so you've got the crushing, you know, pressure and weight of that, you start putting in crazy hours. And I wonder if what your research bears out here is, do you hit a point of diminishing returns?

Anita D'Amico: [00:05:01] It's a very interesting question. I am interested in how the number of hours worked affects the quality and security of code that is developed. I'm interested in this for several reasons. My doctoral dissertation was actually on the effect of fatigue and circadian rhythm on the performance of watch-standing officers on a ship. And I know from the literature that the number of hours worked, how tired you are, and the time of day that you're working all affect various types of performance. But very few people, if any, have studied it in software development. So, one of the things that we tried to do in our own research was to look at things like how many hours of sleep did a developer get the night before they coded and what was the effect on their code?

Anita D'Amico: [00:05:54] Now, we really don't have any definitive research that shows how the number of hours worked affects software developers, but we do have evidence from other areas that we can learn from. So, if you look at the medical community, you find out that the maximum number of hours that a medical resident can work in a single week is eighty hours. And the truck drivers, the maximum amount of time that they can drive is eleven hours. And there's other areas, for example, in the military, there are certain regulations. And it seems like people are zeroing in on eleven hours as the maximum amount of time that you should work before you really start seeing deleterious effects on performance.

Anita D'Amico: [00:06:48] So, if somebody came to me and said, how long should developers work? I'd probably say no more than eleven consecutive hours. I will tell you that there is something that has been studied that I'm going to report on at RSA, and that is how focused a developer's attention is. If a developer is distributing his or her attention across a lot of different files – basically they're context switching... 

Dave Bittner: [00:07:20] Uh-huh.

Anita D'Amico: [00:07:22] ...Their code is more likely to have security weaknesses in it and some quality issues in it versus the developer who concentrates his or her attention on only one or two files.

Dave Bittner: [00:07:38] I'm curious how much of this is a cultural issue. I think particularly here in the United States, it seems as though the number of hours that you put in can be worn as a badge of honor. And that's not so in other places around the world. Does it seem like that component of our culture could be to our detriment here?

Anita D'Amico: [00:08:03] It's very possible that it could be. Culture is an interesting topic. In fact, the research that is being carried on with this DARPA contract right now will be focusing on the effect of security culture on software developers, to see whether or not there's a relationship between security culture. And I would think that – I'm postulating that security culture may be at odds with the heroics of working an eighteen-hour day. 

Dave Bittner: [00:08:35] Mm-hmm. 

Anita D'Amico: [00:08:37] If you were to look at any other industry – let's say you were looking at bus drivers or surgeons – would you really think that they were performing at their safest level in their eighteenth hour of work? No. So I think that those things are at odds – security culture and the heroics of working really long days.

Dave Bittner: [00:09:02] Well, that's fascinating, too, because I think about how the things that the programmers leave behind – it could be the code that is in that medical device that someone's life is relying on. So it's not as though the programmers, the software developers might not have consequential things left behind from their fatigue.

Anita D'Amico: [00:09:26] Oh, absolutely. We really need to pay attention to the code that's written, both the quality and the security of it, because this code is making its way into airplanes, into medical devices, into power systems – things that our lives depend on. And while we regulate and have safety regulations for the operation of those devices or those transportation systems, we don't have the safety regulations for the development of the code that goes into them. You have ratings of the metal that goes into the pipes that go into an infrastructure, but you don't have these certifications for the software that goes into them.

Dave Bittner: [00:10:18] So, if it's my responsibility to manage a team of developers, what sort of framework should I have in mind? What kind of best practices can I put in place to best serve my team and my organization?

Anita D'Amico: [00:10:34] I have a couple of specific suggestions for anybody who is managing a software development team, and these suggestions are based on scientific evidence. So, the first is stop coding after about eleven hours of work. Really take a break, and probably put it down until tomorrow. Any code that is developed between 10:00 PM and 6:00 AM in the morning should be carefully reviewed. There is a phenomenon called "circadian rhythm." It is a change in your body's level of alertness, and it is universal. And your body's alertness goes down significantly between 10:00 p.m. and 6:00 a.m. in the morning, and people are more likely to make mistakes. So, if you have a team that's working those late hours, be sure to review their code carefully.

Anita D'Amico: [00:11:31] I would also suggest that you keep developers focused on just a few files. Don't spread them across many different ones. Because the more you spread a developer across a lot of different files, the more likely they are to accidentally insert quality or security issues. Also, keep your development team to a relatively small number. There's evidence that shows that the more developers that you add to a team, the more security issues. The number is roughly about nine developers. So, you want to break out your software development work into units of fewer than nine developers.

Anita D'Amico: [00:12:15] I would also very carefully look at the code that's written by developers who are inexperienced with the codebase. So, the studies of open-source show that developers who are infrequent contributors to that open-source library are more likely to have quality and security issues in their code versus developers who have a lot of experience with that codebase.

Dave Bittner: [00:12:43] Interesting.

Anita D'Amico: [00:12:44] I would encourage people to come by the presentation at RSA, and we have an active research project going on right now to study the effect of human factors on software developers. If people are interested in participating in this project or they're interested in having their software repository analyzed, then we're looking for people to collaborate with us on this research.

Dave Bittner: [00:13:12] That's Dr. Anita D'Amico. The research is titled, "Human factors that influence secure software development." We'll have a link in the show notes.

Dave Bittner: [00:13:23] Thanks to Juniper Networks for sponsoring our show. You can learn more at juniper.net/security, or connect with them on Twitter or Facebook.

Dave Bittner: [00:13:32] And thanks to Enveil for their sponsorship. You can find out how they're closing the last gap in data security at enveil.com.

Dave Bittner: [00:13:40] The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Elliott Peltzman, Puru Prakash, Stefan Vaziri, Kelsea Bond, Tim Nodar, Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Peter Kilpe, and I'm Dave Bittner. Thanks for listening.