3 Easy Steps to Help Your Developers Code More Securely


Developer Security

Engineering and security have traditionally been seen to be at odds with one another. One is concerned with pumping out new functionalities to keep pace with ever increasing deployments, while the other is focused on ensuring that everything is safe and secure. However, as I’m sure you’ve experienced, it’s often a fool’s errand to get your product to market first, if there are security issues which will have to be addressed after. Therefore, in order to achieve the highest deployment velocity possible, agile development and security requirements need to be balanced successfully.

Below we are going to look at 3 ways security executives can help their developers code more securely.

  1. It Starts from the Top
  2. In order for your developers to see security as a priority, first management needs to. So, how do you get the decision makers to place more value in security during our times of increased market pressures? Show them the value of course.

    Present them with the potential revenue loss due to security vulnerabilities, and then they will be more open to your proposed security solutions. After all, a Ponemon Institute Study found that the average cost of resolving a security issue in development is $80, compared to $7,600 during production. For your voice to be heard the clearest, it’s a good idea to win someone from Finance to back up your proposals. Ultimately, once management are singing a more secure tune, the rest of your enterprise will be more inclined to dance along.

  3. Getting Developers Engaged + Gamification
  4. Ok. You’ve managed to get management calling for more security, now it’s time to get more developers engaged. The key to achieving this is showing them both the real risks and consequences of security vulnerabilities, together with how developers can contribute to increased security themselves. Without this, they will be more likely to resist adding potential friction factors into their coding environment. The Shellshock bug is a great example of how developers helped fight the secure fight. After its discovery, it only took two days for developers at Red Hat, Ubuntu among others to release a second fix.

    Another trick to help your developers code more securely is to improve their awareness via Gamification. Gamification is all about getting to developers to seek out security practice and experience because they want to, not because they have to. This is achieved via applying game principles (competition, points, levels and rewards) as a way of solving non-game problems – basically making learning/problem solving fun. Microsoft offers a good example of an organization who found success with this method.

    Microsoft had a challenge, how to get developers to engage with the often tedious task of assessing software security diagrams. They found the answer in their card-based Elevation of Privileges game. Players first drew or obtained an architectural diagram of a system they wanted to threat model, they were then dealt out a set of cards with names like Three of Tampering with descriptions such as ‘An attacker can manipulate data because there’s no integrity protection for data on the network wire.’ As each player took their turn, they read the threat on their card aloud and explained how it applied to the system being threat modelled. By playing the game, the team assessed all the potential vulnerabilities which could affect the system. This game became so popular and effective, it has migrated online and it can now be played remotely. As can be seen from Microsoft’s example, gamification is a great way for developers to engage with security, for you don’t realize you’re learning when you’re having fun, right?

  5. Training your Developers to Deal with Security Issues
  6. You might be surprised to hear that 71% of developers believe that security is not adequately addressed during the software development lifecycle. This figure is revealing as it shows engineers view security as a development priority, yet they often feel unequipped to engage. It’s clear increased security training has a part to play here.

    However, before security go gun-ho and start telling developers how to do their job, it is essential for any training to take into account the time and remediation constraints that developers face. An excellent example of what developers can do in regards to remediation is open source and proprietary product vulnerabilities.

    With proprietary vulnerabilities, it is the developers themselves who write the code, therefore it’s a lot easier for them to identify and remediate any potential security issues –this is not the case with open source. As open source components originate from a third party, in-house programmers can only identify a pre-existing vulnerability, and in turn it can only be remediated when the third party source has released a patch/fix/new version.

    Finally, when engaging developers, you should ensure you’re approaching security issues from a developer’s perspective. Consequently, for any training to hold sway, it needs to grab developers’ attention. Share newsworthy updates of high-profile cyber-attacks, data leaks or other security issues that caused real damage to software – just think of the stir Heartbleed caused among developers!

    Secure Together

    And there you have it, 3 easy steps to give your engineers a lending hand to code more securely.

    By getting management on board with security, implementing practical and relevant developer security training and encouraging your developers to actually care more about security, your developers will no longer rush for the exit when security pops their head round the corner.

    About the Author

    Jason Levy is a Community Specialist at WhiteSource, a company offering open source security and management solutions.

    Follow WhiteSource on Social Media: Twitter (@WhiteSourceSoft), LinkedIn, Facebook


Have questions about managed file transfer?

Get answers, not a sales pitch. Our experts have analyzed, discussed and solved difficult file transfer challenges since 2002. We are here to help you.

Scroll to Top