It was a difficult, but necessary, battle to create an environment that aligns the security team’s goals with their developers counterparts.
There is still a lot of work to be done, but we are seeing the signs that the obstacles to achieving the shared responsibility for software security have become more obvious. Smart companies will look to improve their strategy in order to avoid these pitfalls and find a productive path forward to maximize DevSecOps’ people-powered potential.
It was something I didn’t expect, but the debate surrounding secure coding continues. This sentiment was clearly revealed by new research done in collaboration with Evans Data. The State of Developer-Driven Security 2022 survey examines the key insights and experiences of 1200 developers to illuminate their attitudes and challenges within the security world.
One of the most striking findings was that only 14% of developers regard security as a top priority when they code. This shows that there are many areas for improvement. However, it confirms the fact that feature-building reigns supreme in the world of developers. They remain poorly equipped to incorporate security into their lives. It is alarming when this data is combined with data about developer definitions of secure coding to them.
These perceptions are based on developer experience during their work day. It speaks to the fact that many organizations do not consider developers a central point in fighting common vulnerabilities. While their support is crucial, we need to quickly agree on the scope of secure coding and what we can expect from a security-skilled programmer.
- Developers need to understand security
- Cybersecurity can be complex and multifaceted
Survey results revealed that developers often view secure code as a siloed concept. They are limited to one category, rather than a comprehensive view of the basics and beyond. Developers tended to prefer existing code (or pre-approved code) over writing code that is secure. Although security awareness about third-party components is important (especially patching; 30% of cases remain unpatched as of December), and testing existing code are equally important, they do not provide a functional level in secure coding.
Developers who learn poor programming patterns can introduce code-level vulnerabilities. A lack of emphasis on writing secure codes in their KPIs, coupled with a weak security culture, only serves to reinforce this unacceptable standard.
By ensuring that all members of the development team are fully informed about secure coding, security leaders can make a significant contribution to improving their initial awareness and identifying the most pressing knowledge gaps. While scanning and testing preapproved code is one function of security, the reduction in vulnerabilities requires hands-on training and practice in safe, secure coding patterns in the languages and frameworks that have been actively used.
Developer upskilling is dependent on context. They need to be included in the journey to meet the security goals of the company.
Many companies need to improve their security programs.
We are all trying to keep up with the threat actors who work around the clock to find exploits in our valuable systems, as a result of the explosion in software-driven tech.
DevSecOps is based on the notion that everyone has responsibility for security. This principle should be considered from the beginning of the SDLC. Problem is that large companies may not be able to implement DevSecOps. A 2017 study by Project Management Institute found that 51% of organizations still used Waterfall for software development. Although the study is five years old, it is unlikely that large enterprises have made a rapid transition to security-oriented methods. Security professionals can find it difficult to implement a comprehensive strategy that protects against cyber threats. Retrofitting developers and their requirements into this environment is an ongoing challenge.
This is not an excuse. Security professionals in the company can use developers in an improved strategy. They just need to become familiar with their needs, and include them in their defensive play. They require extensive training and all security responsibility must be taken into consideration when it comes to their tech stacks and workflow.
Secure Coding = Too Hard?
Evans Data research revealed that 86% of developers find secure coding difficult. 92% of manager of developers also agreed that their teams need more training in security frameworks. Alarmingly, 48% admitted to knowing that their code contains vulnerabilities.
This is a worrying picture. Developers aren’t getting adequate, frequent training or enough exposure to security practices and hygiene. It is clear that developers don’t prioritize security when developing software. This is because the training they receive doesn’t build their confidence, practical skills, or help them to understand the consequences of shipping vulnerable code.
Ransomware attacks on supply chains were among the most significant in the past year. It caused fear that half the gas supply to the United States East Coast would be cut off. They were able to get back online quickly but there was still a lot of fear in the community. The public was faced with the possibility of a cyber attack affecting an aspect of the world that isn’t considered software-driven. All of this chaos was possible due to two unpatched vulnerabilities. One was SQL injection, which is a very insidious and well-known vulnerability. Developers would be able to see that there are no acceptable business risks if they knew the true consequences of shipping vulnerable code.
Most Popular: https://www.oursnetwork.com/progressive-web-application/
Functional “P-P” is not available to the developer.
Without carefully thought strategy, the famous “golden triangle”, of People, Process, and Tools, is impossible. Developers are not in a position of assimilation into a working security process without considering their needs and challenges.