You’ve probably heard the phrase “Nature vs. Nurture” at some point; it’s one of the oldest topics of debate in psychology circles. In a nutshell, the debate centers on whether who you are is defined by what you’re born with (genes) or by how you’re raised (environment). We can all think of personality quirks we’ve inherited and others we’ve learned, so there’s obviously some amount of nature and nurture in us all. But the question is which matters more. I’m not a psychologist, so I won’t even attempt to answer that question. But I will share some thoughts on how it applies to software security based on some recent joint research between Cyentia and Veracode.
Veracode publishes the State of Software Security (SOSS) each year, the most recent edition being their 11th. It’s one of the longest-running reports in the industry and kudos to them for continuing to share their valuable perspective with the community. Veracode began partnering with Cyentia for the data analysis behind the SOSS three years ago, and each time I’ve been pleased with the insights unlocked by the team. Volume 9 dove into factors that affect flaw fix time, Volume 10 focused on overcoming the challenge of growing security debt, and – you guessed it – this year’s edition explored the concept of nature vs. nurture in software security.
How the heck does that psychological concept apply to software security? It’s not as much of a stretch as it might initially seem. We found there are some factors that teams have a lot of control over (nurture), and some they have very little control over (nature). On the “nature” side, we looked at things like size of the organization, complexity of the application, existing security debt, etc. On the “nurture” side, we looked at factors such as how often applications are scanned for security flaws, the types of scanning used, whether open source libraries are scanned, etc. Here’s a full breakdown as shown in the report:
Now we’re ready to circle back to the question we started with regarding the relative importance of nature vs. nurture in software security. In the report, we used a technique called survival analysis to measure the time it takes developers to fix flaws in code. We then created a Cox proportional hazards model to measure how each nature and nurture factor described above affected flaw fix rates.
Things don’t usually work out this cleanly in the realm of model building, but turns out all “nature” factors negatively impact fix rates and all “nurture” factors have a positive effect. The figure below from the report bears this out, showing how each factor speeds up or slows down the median fix rate. It’s clear that the various developer-controlled behaviors in yellow fall on the left (shortening fix times) and the inherited organizational and application factors fall on the right (lengthening fix times).
Looking at the number of days associated with each factor in the chart above, you begin to get the sense that the negative impact of adverse conditions outside developers’ control outweigh the positive impact of their efforts to make software more secure. For instance, the strongest nurture variable, using DAST in addition to SAST, reduces flaw closure time by 25 days, whereas the strongest nature variable, high flaw density, adds 63 days. Furthermore, a little math reveals that the net benefit of three most beneficial behaviors is roughly equal to the single factor of dealing with flaw-dense applications. That suggests the variables you can’t control as a developer have more influence on software security than those you can control. And that’s rather depressing…but there is a silver lining here. No matter what kind of cards you’re dealt, the way you play the hand makes a real, measurable difference.
There’s a lot going on in the figure below, but here’s the gist. We set up four scenarios representing different combinations of nature (“attributes”) and nurture (“actions”) factors. In a worst case scenario of poor organizational/application attributes combined with poor developer actions, it takes about 10 months to fix half the flaws in an application (see yellow line). Changing to employ good secure development actions in that same poor-attribute environment has a noticeably positive effect, reducing flaw half-life by 4 months. If, by some miracle, you could turn the organizational/application attributes in your favor AND continue using good secure development actions, things get demonstrably better (see black line furthest to the left) and flaw half-life plummets to a comparatively scant 2 weeks. Told you there was a silver lining.
It’s not terribly surprising to learn that good behaviors have a positive effect on software security. But I was surprised at how much the nature of the application contributes to its security destiny. My takeaway is that we should absolutely continue seeking to incentivize and improve secure software development behaviors, but these results tell me that we need to do more than that. In the realm of psychology, nature can’t be changed. But I don’t think that’s necessarily the case with the factors we’ve categorized under nature here. Admittedly, you can’t change the size of the organization you’re working for (without quitting and finding another job), but we can strive for less complex, old, and flaw-dense applications. If you’re building a new application, keep an eye on size and complexity. If you’re stuck with an old one, perhaps retiring it or refactoring it to use microservices may help alleviate some of the legacy security debt holding it back from better performance.
The potentially good news is that modern cloud services, devops, etc. seem to be trending that way now, which may have positive spillover to the software security. The bottom line is that this research gives good motivation to attack both the nature and nurture sides of software security. What factors do you control and where can you have the greatest impact?
Looking for more findings and commentary pertaining to nature and nurture in software security? Or want to see what other analytical treasures we were able to dig up from Veracode’s vast dataset? Great – download SOSS v11 today!
Leave a Reply
Want to join the discussion?Feel free to contribute!