African American programmer coding on computer showing vulnerable code and secure applications

“Secure Applications” Are Full Of Vulnerable Code, and Resource-Strapped Developers Know It

A new report from cybersecurity firm Immersive Labs finds that the vast majority of app developers are knowingly pushing vulnerable code, and that truly secure applications capable of repelling a determined attacker are few and far between.

The eye-opening report surveyed 260 development and security teams at large organizations. 81% of the development teams surveyed responded that they had knowingly pushed vulnerable code; 20% of senior management said that they “often” signed off on these unsafe practices.

Developers claim that they are failing to secure applications due to an overwhelming workload and a lack of resources, with only 39% responding that they felt they had adequate resources to move security considerations up in the development process. But there is also a major disconnect between front-line developers and management; 80% of managers say that they expect security to be handled during the development process, but only 27% of the developers surveyed agreed with that statement.

Survey finds vulnerable code should be expected in 3/4 of apps; Most comes from open source libraries

Studies of data breaches tend to focus on human error on the user end of software. While that certainly remains a significant factor, the Immersive Labs study indicates that insecure applications may be setting organizations up for failure. An epidemic of vulnerable code may be an underlooked contributing factor to the general rise in cyber crime that has been observed in recent years (and exacerbated by the pandemic).

Of the 81% of survey respondents that said that vulnerable code was knowingly being pushed, a little over half said that this happens “sometimes” or “often.” And the problem is not a case of irresponsibility among junior developers; senior development engineers (Heads of DevOps and Development Managers) were twice as likely to say that they push insecure applications “often.” Only 19% of all respondents said that they “never” advanced vulnerable code.

Unsurprisingly, very few of the security professionals surveyed feel that their application build environment could survive a serious attack, something on par with the recent state-backed SolarWinds breach. Both development and security teams also report that training and information sharing is happening too infrequently to keep up with the rapidly evolving threat landscape. Only 44% were confident in the organization’s ability to repel a dedicated attacker; CISOs (50%) were more confident than security professionals (31%). And only 56% of security professionals expressed confidence in the security of the development process.

Respondents strongly express the desire to “shift security left” in the development process, but fewer than 40% felt they presently had the time and resources available to do so. Only about half felt they had time and resources to properly address existing vulnerabilities. Security teams feel more pressed for resources than development teams; less than half agreed that they were able to develop secure applications or address current vulnerable code issues under the present circumstances, compared to about 60% of developers.

Senior leadership also appears to strongly believe in security and a shift left in the development process, but the message does not appear to be getting through to the front lines. 80 to 85% of senior leadership generally agree with this sentiment, but only 27% of developers feel they should be tasked with security and only 55% agreed security considerations belonged in the development process. 36% of developers felt that they had access to timely and adequate information on the latest security risks.

Developing secure applications while under pressure

While the study does not offer comprehensive answers to these problems, it does identify one significant factor hampering the development of secure applications: outdated information sharing and training practices that are no longer adequate to the task.

Only 40% of the responding security professionals believe they have a comprehensive understanding of application security in the development life cycle, and 44% say that they do not think developers understand the latest threats (very close to the number of developers that self-report not having access to adequate up-to-date information).

Part of this is due to infrequent communication between security and development teams. Only 27% of organizations have daily threat updates; 49% pass updates once per week and 19% do it once per month. Training formats are also not keeping up with modern needs, with about 50% of organizations still doing classroom training even after a year of pandemic-driven shift to remote work as a primary model. Training on the development of secure applications also tends to be infrequent at most organizations, with half only conducting it once per quarter at most.

There are also initial training issues. 50% of security practitioners say that new employees do not receive adequate security training during onboarding, and only 45% of front-line software development employees feel that they have had adequate training to build secure applications and fix vulnerabilities.

81% of #softwaredevelopment teams responded that they had knowingly pushed vulnerable code; 20% of senior management said that they ‘often’ signed off on these unsafe practices. #cybersecurity #respectdataClick to Tweet

Robert Haynes, Open Source & SCA Evangelist for Checkmarx, believes that the problem of vulnerable code is cultural in nature and will not change until organizations focus on security as a core feature of their brands: “Some of the more alarming results – such as the statistics regarding the known release of insecure software – in this survey symbolizes how far we as an industry must go to make security a foundational component of software quality … If these results seem surprising, ask yourself: How many development teams would be celebrated for halting an urgent build or release in the name of security? If we believe that security is essential to software quality (as we should), we need to learn the lessons of quality-focused manufacturing systems where behaviors that improve long term quality and integrity are rewarded – even if this means prioritizing security over speed of production in certain instances. Can tools and training help mitigate the most concerning findings in this report? Yes, better training and tools that help highlight security issues in an automated and friction-free way are essential. However, they must also be coupled with company-wide buy-in and an authentic change in the way development teams and organizations approach software quality.”