As the number of cyber-threats continues to grow, organizations are making daily trade-offs between security, practicality, and speed – exposing themselves to risks in the process. New approaches to secure coding are needed, so Secure Code Warrior engaged with Evans Data Corp. to conduct primary research into developers’ attitudes towards secure coding, secure code practices, and security operations (download the whitepaper here).

What this report revealed is that while ‘old-school’ reactive thinking still dominates, there is a growing awareness of the need for more proactive solutions, which turn developers themselves into the first line of defense.  

Any exploration of the adoption of secure coding practices needs to begin with an understanding of the humans involved in its implementation, their perceptions of it, and their capacity to implement it. This then leads to the most important piece of the puzzle – how can they be empowered to code more securely right from the start and ship quality code faster, with confidence? 

Secure coding – where are we now, and what has to change? Download the infographic 'The Human Element' now.

Current perspectives – reactive vs. proactive

When developers and development managers were asked about the activities they associate with secure coding, the top three responses were:

• Using scanning tools on deployed applications.
• Manually reviewing code for vulnerabilities.
• The active and ongoing practice of writing software that is protected from vulnerabilities.

As we can see, two of the top three responses still focused on reactive approaches – the first dependent on tooling (scanners), and the second on the developer (i.e. human) performing manual checks.

At the same time, two of the three activities nominated rely on the human element. This points to growing perceptions of security as a human issue. But of all the activities nominated, the most telling is No. 3, which identifies the human factor in writing software that is protected from vulnerabilities in the first place. This highlights a shift to starting left – a proactive and preventive approach that bakes security into software right from the start of the SDLC. 

Where does security fit in the SDLC? 

When developers and development managers are asked where they see secure code practices integrating into the SDLC, opinions differ. 55% of managers believe that secure coding is integrated across the entire development process, compared with only 43% of developers. The difference might reflect these two groups’ differing roles within the SDLC. Management is typically less involved with the actual work of coding and tends to have a higher-level view – whereas developers might be more concerned with the nuts and bolts.

But from an overall security and code quality point of view, what’s alarming is that only 13% of developers and 10% of managers saying that secure code practices should be integrated within the design stages – right at the start of the SDLC. This is a huge and unrealized opportunity. According to an IBM study, it is thirty times more expensive to fix vulnerabilities in post-release code than if they were found and remediated at the beginning.1 That’s a powerful incentive for a new proactive and human-led defense of software security, that equips developers to code more securely, right from the start. Software security can’t be resolved by reliance on tooling alone – it has to take account of the human element. 

Is the human element prepared?

97% of developers surveyed believe they have had sufficient training in secure coding, and 95% agreed that training in secure coding had been valuable to their career. But before accepting these claims at face value, we need to ask: Why are code vulnerabilities still so prevalent? Are developer’s claims of secure code expertise just a case of human ego? The evidence certainly points in this direction. In a more modest admission, more than 88% of surveyed developers admit that secure coding is difficult to learn, and 91% of development managers acknowledge that secure coding practices are challenging to implement. When asked to identify their major personal concerns around secure code implementation, 28% of developers find the learning process challenging, while 24% find the learning process boring. This points to the fact that developer training needs to improve. 

What does the human element need? 

To overcome the ‘challenging’ factor, worthwhile secure training requires a ‘scaffolding’ process that supports the developer to build secure coding skills step by step. For maximum relevance and immediate applicability, that training should take place in the specific language:framework they use every day.  

To overcome the ‘boredom’ factor, secure code training needs to be delivered in hands-on ways — proven to be far more engaging for developers than outdated classroom or ‘watch this video’ models. These should include live simulations that allow developers to tackle sometimes-risky security challenges in a safe environment. The aim should be to teach developers how to find and fix vulnerabilities in code as they work and make secure coding part of their day-to-day flow. Another key enabling factor is inside-the-IDE linting and coaching, which helps developers constantly learn and up-skill as they code, preventing and eliminating vulnerabilities as they go.

If you’d like to find out how to provide your developers with this new level of developer-centered tools and training, book a demo now.

You can also download your copy of the whitepaper Shifting from reaction to prevention: The changing face of application security.

‍