2022 Developer Perspectives on Application Security – Research Report

Overview

Cybersecurity does not just rely on technical prowess to outwit threat actors but more critically, on the proactive approaches taken by humans in the digital loop. These include not only system personnel responsible for security but also system administrators, end users, and perhaps most critically, software developers who build and maintain software.

For developers, the phrase “it may not be your fault but it is your problem” comes to mind. Mindful of this, developers must consider several aspects beyond their code: (1) System thinking. Building and deploying software in cloud-based systems in particular requires moving beyond traditional “perimeter-based” cybersecurity defenses to “perimeter-less” cybersecurity frameworks, including zero trust architecture. (2) Proactive design.

Secure software development requires shifting security left to early design work and continuing through every stage of the SDLC. (3) Technical alignment. Agile methods allow security professionals to seamlessly integrate security activities into agile DevSecOps approaches. (4) Mature mindset and approach. Telling developers what checklists and processes to use along with errors to avoid, has some efficacy. However, engaging developers on security topics with a range of stakeholders elevates their thinking and approach. (5) Automation. The obvious should not be overlooked. Automated cybersecurity guidelines, training and guidance integrated into development streams are clearly beneficial.

The current research provide a comprehensive view into current developer views, including the challenges and opportunities they face in their secure development efforts. Specifically, it provides “deep dives” into issues of security maturity, threats, release states, gatekeeping, requirements, tools, resources, and training.

Demo/Firmographics

Developers were surveyed from companies that produce their own custom software. Respondents were part of the software development or Dev Ops teams, and in this capacity they must have been assigned requirements related to security and compliance and/or penetration testing. They came from a variety of industries and a range of company sizes.

A bar chart displaying the expertise areas of survey respondents: 62% are in Software Development/DevOps, 22% are in IT Infrastructure and Back Office Corporate Functions, and 14% are in Cyber/Information Security.

 

A bar chart showing the sectors respondents work in: 30% in Technology, 17% in Software as a Service (SaaS), 14% in Manufacturing, 10% in Retail, 8% in Financial Services, 6% each in Banking and Healthcare, 5% in Insurance, 4% in Professional Services, and 1% each in Telecom and Government.

 

A bar chart illustrating the annual revenue of respondents’ companies: 4% under $50M, 8% from $50M to $100M, 6% from $100M to $250M, 19% from $250M to $500M, 21% from $500M to $1B, 28% from $1B to $5B, 10% from $5B to $10B, and 4% over $10B.

 

Software Security Posture: Dev

 

A chart depicting security maturity among software developers: 4% very immature, 5% immature, 6% somewhat mature, 42% mature, and 43% very mature. It includes a text explaining the challenges developers face in staying up-to-date with security and compliance activities.

 

Security Threats

Automated modeling, integration with other tools, and matching the speed of new threats that emerge are all highly important to developers.

A bar chart showing the importance of various measures in preventing security threats: Relevant and up-to-date threats (40% mission-critical), relevant and up-to-date threat mitigations and training (43% mission-critical), integration with other tools (44% mission-critical), and automated modeling (46% mission-critical).

 

Software Release States

Most developers are working to release schedules of a month or less. Larger enterprises are less likely to do rapid, weekly releases versus smaller companies. Large companies also rely more on SBOM or container orchestration versus small companies relying on their cloud platform to identify the list of components used to build products.

 

A chart showing software release frequency: 0% annual release, 2% semi-annual, 10% quarterly, 39% monthly, 34% bi-weekly, and 14% weekly. It also shows where to get a complete list of tech components: 70% from cloud platforms, 60% from source code repositories, 59% from infrastructure as code, and others.

Software Release Gatekeeping

The majority of software developers report that their applications would not be released until threats of specified authority are mitigated. This finding held across all company sizes. By contrast, the smallest companies surveyed were more than twice as likely as the largest companies (31% vs. 14%) to use ad hoc or reactive means to gatekeep releases from a security perspective. Automated validation is key to most devs along with security team approval and documentation.

 

A chart showing factors that block software release due to security concerns: 76% block until threats are mitigated, 68% perform annual analysis and prioritization, 60% release first and fix later, and 23% use ad-hoc or reactive measures. It also shows how companies prove code compliance: 72% through automated verification, 65% with security team approval, and 64% with documentation.

 

 

SDLC and Security Requirements

Developers surveyed reported a wide variation in the percent of their software requirements, user stories, and tickets in a typical release that were related to security and compliance. Surprisingly, on average a third of requirements were related to security and compliance. Only a quarter or so of companies have shifted security left into the Design Stage of software development, a finding that held true irrespective of company size. Overall, the Development stage dominates as to when security requirement are most likely to occur.

The image consists of two charts. The left chart shows the average percent of requirements related to security and compliance, which is 36%. The right chart illustrates the stages of the SDLC (Software Development Life Cycle) where security engages: Design Stage (26%), Development (40%), Testing (15%), Deployment (12%), Post Deployment (5%), and 1% for those who do not work with the security team. The data is segmented by various revenue ranges from $10M to less than $100M.

 

Tools and Helpful Information

Application security testing tools are #1, with the most helpful information provided typically being sample code snippets and data flow diagrams.

A chart showing tools used to validate security requirements: 65% use application security testing, 64% use API security analysis, 60% use security training courses or labs, 58% use software composition analysis, 58% use mobile application security testing, and others. The most helpful information includes sample code snippets (68%), diagrams or visualizations (65%), and acceptance criteria (63%).

 

Resources

Resource preferences favor internal standards, of which almost two thirds involve custom tracking systems. Whether these in turn involve commercial systems or custom tracking systems, most are lacking actionable information and samples.

The image depicts resource preferences for security, indicating that 67% of respondents prefer internal standards, followed by NIST 800-53 controls at 56%. It shows how security for internal components is tracked, with 62% using a custom tracking system and 34% using a commercial system. Additionally, it highlights the state of internal security standards, noting that 36% include actionable information and samples, 29% cover most cases, 21% lack actionable information, 8% find them irrelevant, and 7% consider them out of date.

 

Training

 

A chart depicting responses to secure development training taken, with 63% mandatory by organizations, 32% self-imposed, and 2% opting out. The best suited training type is shown in a pie chart, favoring step-by-step walkthroughs. Another chart indicates the best time to do training, with 32% during new tasks, 28% during coding problems, and 21% when vulnerabilities are found.

Training (con’t)

Further to desired training needs, having training embedded in tools was overall top ranked but of almost equal importance to developers is that they want hands-on examples, online lessons, and podcasts. Not surprisingly, software developers favor software in its various forms for their training versus in-person lessons. The majority want it for compliance regulation but it is also desired for vendor/technology specific applications.

A bar chart showing preferences for secure development training methods, including embedded in tools (27%), hands-on exercises (26%), and online lessons (21%). Another bar chart lists the types of training taken, highlighting compliance regulation (74%) and vendor-specific (72%) as the most common.

Conclusion

Laying security issues at the feet of developers does little to abate the deluge of cybersecurity threats hitting enterprises across all sectors and of all sizes. Checklists, reminders and moral suasion to build carefully is not nearly adequate. Most developers involved in product builds believe their companies to have a mature security posture but nonetheless struggle to keep up to date with growing regulations and compliance requirements. On the cybersecurity front, developers view automated modeling, integration with other tools, and matching the speed of new threats that emerge as all highly important. Security must start with design and remain a critical element at each stage of the SDLC.

While working to release schedules of a month or less, developers rely first and foremost on Cloud platforms for lists of tech components although in larger enterprises also on SBOM or container orchestration. With most apps not released until threats of specified authority are mitigated, automated validation is key along with security team approval and documentation. Developers rely #1 on application security testing tools with the most helpful information typically being sample code snippets and data flow diagrams.

Resource preferences favor internal standards, of which almost two thirds involve custom tracking systems. Nonetheless, most lack actionable information and samples. Developers embrace training, whether mandatory or voluntary. Step by step walk throughs are favored generally by an approximate 2:1 margin. Generally, the best timing for this training is when a developer is about to start a new task although it also is needed when problems are encountered with code and when vulnerabilities are exposed. 

Importantly, developers want training embedded in tools along with hands-on examples, online lessons, and podcasts. Not surprisingly, software developers favor software in its various forms for their training versus in-person lessons. Companies that want to attract and support developers in their efforts to build cyber-resilient software need to look to integrated cybersecurity software that provides just-in-time training (JITT) and guidelines for their software developers and automated cybersecurity software for accomplishing these goals.