CyberWire Daily - Overworked developers write vulnerable software. [Research Saturday]

Episode Date: March 7, 2020

Why do some developers and development teams write more secure code than others? Software is written by people, either alone or in teams. Ultimately secure code development depends on the actions and decisions taken by the people who develop the code. Understanding the human factors that influence the introduction of software vulnerabilities, and acting on that knowledge, is a definitive way to shift security to the left.  On this Research Saturday, our conversation with Anita D’Amico from CodeDX on which developers and teams are more likely to write vulnerable software. The research can be found here: Which Developers and Teams Are More Likely to Write Vulnerable Software? Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. 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. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security.

Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI.

Learn more at zscaler.com slash security. 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. That's Dr. Anita D'Amico. She's CEO at CodeDX. The research we're discussing today is titled Human Factors That Influence Secure Software Development. 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. 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 zeros 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.

deal with can actually find their way into the security of code. 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. 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. 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 a.m. 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 pressure and weight of that. You start putting in crazy hours. 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? 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 watchstanding 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. a developer get the night before they coded and what was the effect on their code. 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 80 hours. And the truck drivers, the maximum amount of time that they can drive is 11 hours. And there's other areas, for example, in the military, there are certain regulations, and it seems like people are zeroing in on 11 hours as the maximum amount of time that you should work before you really start seeing deleterious effects on performance. So if somebody came to me and said, how long should developers work? I'd probably say no more than 11 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. 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. 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? It's very possible that it could be. Culture is an interesting topic. In fact, the research that is being carried on through 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 18-hour day. 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 18th hour of work? No. So I think that those things are at odds, security culture and the heroics of working really long days. 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. Oh, absolutely.

We really need to pay attention to the code that's written, the quality and the security of it, to the code that's written, but 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 this software that goes into them. 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? 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 11 hours of work. Really take a break. And probably put it down until tomorrow. Any code that is developed between 10 p.m. and 6 a.m. 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 p.m. and 6 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.

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 is 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. work into units of fewer than nine developers. I would also very carefully look at the code that's written by developers who are inexperienced with the code base. 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 code base. Interesting. 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 in this research. 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.

And now a message from Black Cloak. Did you know the easiest way for cyber criminals to bypass your company's defenses is by targeting your executives and their families at home? Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected lives. Because when executives are compromised at home, your company is at risk. In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7, 365, with Black Cloak. Learn more at blackcloak.io. The Cyber Wire 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 Cyber Wire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Valecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilby, and I'm Dave Bittner. Thanks for listening.