Security Compass 2022 Year In Review


 
 

Static Version

Developer-centric Cybersecurity

Relying on technical prowess to outwit cybersecurity threats is not enough; proactive approaches need to be taken by employees across the organization. These include not only the employees responsible for security but also system administrators, end users, and most critically, developers who build and maintain software.

To succeed, developers need to approach cybersecurity with proactive design, system thinking, technical alignment, a mature mindset that involves them in secure design, and automation to make cybersecurity manageable

Automated threat modeling, integration with other tools, and matching the speed of new threats as they emerge are all highly important to developers from companies of all sizes.

A chart showing a detailed breakdown of the average percentage of requirements related to security and compliance, segmented by different revenue bands of organizations.

Tools and Information Needs

In terms of the tools used to validate security requirements, the top 3 are application security testing tools (SAST, DAST, IAST) followed by API security analysis and security training courses. ****

The most helpful information provided is typically sample code snippets followed by data flow diagrams.

A dual bar chart showing the percentage of various tools used to validate security requirements on the left, with the most used being Application Security Testing (65%) and API Security Analysis (64%). On the right, it shows the most helpful information types, with sample code snippets (68%) and diagrams or visualizations (65%) being the top two.

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.

A single bar graph showing that 36% of requirements are related to security and compliance.

A bar chart titled “Stage of the SDLC Where Security Engages” showing that 40% of security engagement happens during the development stage, followed by 26% during the design stage, and 15% during testing.

DevSecOps Perspectives on AppSec Training

Virtually all companies offered their development, ops, and security teams some form of application security training, Of these, the most common forms of training are those from a catalogue provider and interactive training.

A bar chart titled “AppSec Training Offered at Your Company” with various training options listed on the y-axis. The top training options are eLearning courses (42%), interactive training (40%), and vendor specializing in cybersecurity (38%).

Training Timing

The best times for providing training for AppSec Security are during active design (requirements) and development / DevOps activity.

A bar chart showing the best time to do secure development training. The highest percentages are during coding and implementation (16%), during cloud configuration (14%), and when starting new requirements (12%).

AppSec Training Challenges

While frustrations vary widely, both the depth and breadth of content are most frequently cited.

Implementing new code to satisfy security requirements is the most time consuming both for individual contributors and for development managers.

A bar chart showing frustrations with developer training. Top frustrations include depth of content (15%), breadth of content (15%), and not integrated into app dev environment (11%).

 

A bar chart showing the most time-consuming aspects. Top aspects are implementing new code for security (37%), sourcing answers for security questions (28%), and assigning the right individual (21%).

The Value of Accreditations

Security accreditation is broadly viewed as very helpful, for individual contributors, managers of development teams, and organizations. It helps individuals contribute and to guide others. Frustrations vary widely; both the depth and breadth of content are most frequently cited.

A bar chart showing how accreditation helped career development. Top responses include making the job easier (45%), building credibility (40%), and aiding in promotion (39%).

 

A bar chart showing how accreditation could help career development. Top responses include helping guide others (56%), making the job easier (44%), and aiding in promotion (37%).

 

 

Application Security In the Mid-Market

For over two-thirds of mid-market companies that develop custom software, security sits within the IT department. Creating software that is secure by design and shifting security left are top priorities, especially for larger mid-sized companies.

A bar chart showing where security sits within an organization. Most respondents indicate IT (69%), followed by development (24%).

A bar chart showing the priority of secure by design. Top priorities are shown with 41% as a top priority, 41% as one of the top 3 priorities, and 17% as one of the top 10 priorities.

A bar chart showing the priority of shifting security left. Top priorities are shown with 31% as a top priority, 48% as one of the top 3 priorities, and 20% as one of the top 10 priorities.

Defining Security Requirements

Very few companies are able to define security for new software nor are they able to track implemented controls in less than a day. The time spent is undoubtedly tied to manual processes in developing new software. Most (86% overall) believe that tracking inherited security from third parties would make the speed of delivering software faster or a great deal faster.

Bar chart showing the “Time to Define Security for New Software” with a breakdown of overall and by revenue ranges ($100M to $499M, $500M to less than $1B). Overall: 5% less than 1 day, 59% 1 to 6 days, 27% 7 to 13 days, 9% 14 days or more.

 

Three graphs titled “Time Spent Tracking Implemented Controls,” “Need for Tracking Inherited Security from Third Parties,” and “How Would Tracking Implemented Controls Speed the SDLC.” The bar chart shows various percentages, a pie chart indicates 91% use spreadsheets, and a segmented bar chart shows different speed improvement levels.