Developer working on laptop with source code showing vulnerable code

New Reports: Developers, Overwhelmed by Security Issues, Pushing Vulnerable Code and Missing Over Half of Reported Vulnerabilities

Two new reports find that developers are struggling to keep up with an endless flood of security issues, and that overall security is suffering as a result. 42% self-reported pushing vulnerable code at least once every month, and they are only able to get to 32% of known vulnerabilities.

Developers point to the isolation of teams as the leading reason for these shortcomings, with poor communication leading to failure to screen out an overwhelming amount of false positives among other issues. In this environment, developers also overwhelmingly do not regard application security as a top priority.

Developers working in deficient security cultures; average incident cost shoots up to $3.8 Million

The first of these reports, “The State of Developer-Driven Security Survey 2022” from security and training platform provider Secure Code Warrior, queried 1200 working software developers from organizations around the world in December 2021. The headline item from this survey is that developers are still rarely treating security as a leading priority. Only 14% of the respondents said that it was their top priority, though 66% acknowledged that change is brewing in the industry and felt that emphasis on application security was going to increase in their job in the next 12 to 18 months.

Management respondents echoed this anticipated shift: 82% that dealt with hiring said that they were “much more likely” to hire new developers that have secure coding skills. This was much more of a priority for larger companies (90%) than smaller ones (72%).

Yaniv Balmas, Vice President of Research at Salt Security, expands on this particular point: “While these findings show that developers and hiring managers are recognizing the growing priority of security for DevOps, it’s not enough to ensure your application security. This is particularly true in the case of APIs. Because APIs aren’t just straight code, you must see them being exercised in order to spot logic flaws. You need the ability to monitor them in runtime in order to spot anomalies and find areas where APIs might be exposing critical data … These survey findings – while raising an important red flag for businesses – aren’t that surprising. The RapidAPI 2021 State of APIs developer survey uncovered similar issues. Its research found that just 4.3% of developers conducted security testing on APIs. Although developers write APIs, their testing falls short for security. To accurately see what’s going on with APIs, you need to exercise the API – even in pre-production.”

Some of the coding security issue is owed to deadline pressures. But at least some part of it appears to be due to perception of security requirements among developers. The survey results suggest that developers tend to regard code security as something that is done after code is created; 37% said that examining existing code was a top practice, as compared to just 29% focusing on actively writing secure code as they develop. 22% responded that code security was simply not their responsibility and that a third party of some sort was supposed to review it and clean up that aspect after the fact.

But not all of this can be pinned on developers having a “not my department” view of code security as an individual attitude. There appear to be systemic cultural issues in organizations with defining when code meets the threshold of “secure.” 61% of respondents said that code is considered secure so long as it pulls from a secure library. 28% said it is considered secure so long as no breach reports come in within a few months after it is deployed.

However, whether it is company culture or an individual attitude, developers do appear to be commonly shipping vulnerable code with the full knowledge that there are weaknesses in it. 67% said that they do this, with 48% saying that they do this on every project. As to why this is so common, developers most frequently blame libraries (45%) even though this appears to be the leading metric by which organizations are judging code security.

Developers were also able to weigh in on what was keeping them from securing code properly. Unsurprisingly, deadlines were the leading issue (24%). Other common challenges include lack of a plan for secure code at the organization, lack of interest from management, and lack of needed skills to address vulnerable code. More than half also said that writing secure code was a significant difficulty. And when presented with a list of seven common vulnerabilities, more than half said that they were not confident that their code was secure against them.

Vulnerable code often the result of “siloed” departments

The report from security management platform Tromzo, “Voice of the Modern Developer,” surveyed 400 working developers in the United States who make use of CI/CD tools and regularly deal with potentially vulnerable code.

This report reflects what is becoming an age-old problem; security reports a constant blizzard of alerts that mostly turn out to be false positives, and gradually developers start to tune most of it out. The report suggests that departments being isolated from each other is exacerbating this state of affairs.

Some of the numbers reflect what was found in the Secure Code Warrior study: 42% of developers said they push vulnerable code at least once per month, and they only address about 32% of vulnerabilities. That is not necessarily a bad number, depending on how many vulnerability reports turn out to be false positives; however, the survey’s own numbers suggest that only about 1/3 of these are actually false positives, suggesting that developers are missing about half of the alerts that could turn out to be a real problem.

Generally speaking, organizations want a few security tools that work really well in spotting weaknesses in vulnerable code. The opposite seems to be the most common case, however; 62% of application testers say they are using at least 11 tools. The organizations that use at least 20 tools are less confident in their security posture than those that use 11 to 19, and are not tremendously more confident than those that use eight or fewer. Despite all of this, there appears to be general confidence that nothing really bad will happen as 80% said that they would be surprised to see their company in the news due to a security breach.

Reports reflect an age-old problem; #security reports a constant blizzard of alerts that mostly turn out to be false positives, and gradually #developers start to tune most of it out. #respectdataClick to Tweet

Respondents were also asked what they consider to be the #1 challenge of their application security program, and the leading response was “developers not doing what the security team tells them to do.” Archie Agarwal, Founder and CEO at ThreatModeler, commented on the need for addressing vulnerable code to be an integrated effort given the current landscape: “Recent breaches further stress the fact that companies don’t have a firm grasp on the complexities of their own applications.  With the continued move to more aggressive DevOps pipelines that include many different components such as source code, open-source packages and APIs, it is extremely rare that one person or team understands the threat landscape of the entire application, system, or appliance.  Organizations need to better understand how their systems work and what type of threats the architecture may be prone to. Threat modeling is the primary route to delivering a secure design. It is far more challenging and resource intensive to re-engineer security after the fact than it is to weave it into design and build from the start.”