In the same post where Bruce Schneier famously said that he personally believes “that training users in security is generally a waste of time, and that the money can be better spent elsewhere,” he added an important caveat about training developers. Developers, he wrote, “are people who can be taught expertise in a fast-changing environment, and this is a situation where raising the average behavior increases the security of the overall system.”
While the discussion around information security awareness programs for non-technical employees and customers may be up for debate, when it comes to your development team, it’s not. The benefits of shifting security to the left has been well-documented by now, and unless we want to continue on the same beaten path towards data breach or compliance violation, we need a change in how security is done in our organizations. And that starts with education and awareness for our developers.
It would be quite the understatement to say that developers have not traditionally focused on securing the code they write – and that’s because they were never taught or urged to do so. Jay Schulman wrote a nice post going through the average developer’s career timeline to show how so many developers avoid ever learning how to code securely.
With developer performance historically linked to how quick and feature-packed their code is, with not so much as a hint of security requirements, a change in your company culture is needed in getting developers to understand their role in ingraining security within their code.
If the systems and applications we’re creating need to be designed securely, then education needs to start with the people creating them – the developers. You could have the most robust suite of security solutions and a huge security team – but if the developers working on your applications don’t understand the importance of security or know what they need to do to help the organization release secure applications, you’ll have a constant push back at release time.
The only true way to go about changing the way security is integrated throughout your SDLC is to raise awareness and spend the time and resources now teaching developers about secure coding practices and how to use security tools – before it costs you much more.
As your organization grows, it’s going to be increasingly challenging to scale your security practices without getting the development team involved. The more lines of codes being produced in your organization, the harder and more time-consuming it is for the security team to review the code.
One of the biggest risks to an organization is a lack of knowledge of secure coding and secure practices in the workplace. This is a risk that, if exploited, can bring down major corporations and cost thousands – if not more – to clean up the mess, including lost customers, lawsuits, etc.
The average cost of a data breach is $3.79 million, according to Ponemon’s latest report. That number has risen 23% since 2013, with the cost of EACH record now averaging in at $154.
But by teaching developers secure coding practices and integrating practices and tools that allow them to do so without much more effort needed on their part, you’ll be greatly reducing your security risks while saving money.
More than reducing risk, you’ll also be saving money during development by teaching your development team to find and fix issues ASAP. Detecting security issues as early as possible within your Software Development Lifecycle (SDLC) saves between 15 and 90 times the cost to fix than if a vulnerability is found in production.
By helping developers become secure programmers, you’ll be showing your security program’s ROI and proving its value.
Finally, information security awareness is important because it’s mandated by various compliance standards, including the PCI-Data Security Standard. Continued information security awareness training for developers is required because it serves to offer your customers and employees secure and user-friendly experiences with your applications, and because, most of all, it just makes solid business sense.
Learn more about achieving PCI DSS compliance here.
We looked at two recent surveys measuring developers knowledge in application security and found the results were depressingly similar, with between 56% and 60% of developers answering the questions correctly. That’s an improvement from five or ten years ago, when application security wasn’t on the radar for the vast majority of organizations, but it’s still not a passing grade. We still have a while to go.
The Denim Group’s AppSec Survey 2.0, which used 15 multiple choice questions and was taken by developers with a range of experience levels and amount of previous training, found that only 56% of the 600 developers surveyed answered questions about application security correctly.
While the respondents did OK on questions asked about basic application security awareness questions, such as a fill-in-the-blank question about where malicious scripts are executed in an XSS attack that received 83% correct responses, only 11% answered the question about the techniques required to prevent a cross-site scripting vulnerability correctly. So while developers are aware of the AppSec basics, they don’t know how to apply it to their own work. While the fact that they know the basics is a great advancement over just a few years ago, there’s still much work to be done in the education department and moving from theory to practice.
A second survey, done by Aspect Security, asked 1,425 developers what they know about secure coding standards and practices. The survey had interesting results, especially on these topics:
The fact that only 20% of developers understand the basics of protecting sensitive data is incredibly telling, and something that you need to address with your own developers. (Note: At the end of Aspect’s survey, in fact, you’ll find an additional survey that you can give to your own developers to see how they score and where you can best start helping them.)
There is no doubt a major lack of collaboration between developers and security, but we need to stop pointing fingers and work on mending the gap through a change of culture – of which a major part is security awareness and education programs.
1. Get developers involved in your threat modeling process
We’ve discussed the quintessential practice of threat modeling before, but getting developers involved is another important aspect. Since most security teams don’t have development experience and vice versa, having both teams involved in determining which areas of the application to be built will pose security problems, along with their risk levels, is a starting point to reducing the friction caused by last-minute security tests coming back with tons of issues.
Threat modeling will help you make your application secure by design, and by getting at least part of the development team in on that process, you’ll be able to show them what risks are posed, why, and what needs to be done about it from your point of view. Just be sure to listen to their concerns and answer their questions throughout the process.
Not sure how or where to start with threat modeling? Microsoft offers a great, free threat modeling tool that promotes collaboration between all the teams involved in SDLC and is recommended by OWASP. Lots of guidance included.
2. Use incentives to motivate developers
As Denim Group discovered while doing their annual survey, incentives go a long way in getting developers interested in coding more securely.
Rewarding developers who are actively applying security lessons to their work is one of the best ways to encourage the continued collaboration between your groups. Other activities like company-wide bug hunts with nice prizes and CTF’s will help teach new concepts while offering a good way for security and developers to learn from each other.
Etsy’s head of security, Rich Smith, for example, has started a habit of keeping a bowl of candy throughout the security department to lure developers into the office, which many times will turn their candy pit-stop into a discussion about security. He’ll also pick up the beer tab at the development team’s happy hour every once in a while, just to get them to feel less tension towards the security team. It works very well, he says.
3. Make security relevant with real stories of security successes and failures
No matter what vertical your organization is in, there are always going to be news stories about a cyber attack, data leak, or similar security issue that has caused major damage for an organization similar to yours. In our industry, that’s just our luck!
Sharing these stories about breaches and fall-out and discussing how and why these incidents happened is another great way of getting developers to be genuinely interested in writing secure code.
On the other hand, it’s also imperative to invite developers to share in your security successes. Like anyone, developers need feedback throughout any security awareness program, whether that’s by using your reports to show how vulnerabilities are reduced or are being detected and remediated earlier in the SDLC. Make giving feedback consistent, constructive, and make sure to ask for feedback from them as well on your program.
4. Integrate security tools and rules into their existing IDE and build repositories
Developers are already constantly under pressure to release, especially in agile environments. One major way to both move security towards the left is to use security tools and automatically code security rules within their existing environments – their IDEs, build repositories and bug tracking systems. Getting developers to treat security bugs as any other software bug is much more simple when programmers are using the same tools to find and fix both.
5. Use Your Own Security Tests In Lessons
Lastly, you can kill two bones with one stone by finding patterns of security issues you discover and sharing the info with the programmers. Not only will you be able to determine which areas in awareness you still need to work on, but you’ll be giving developers real-life practice in areas they need help in any way.
While tracking and analyzing the most common found vulnerabilities discovered in source code analysis tests, incorporate ways to prevent the mistakes that allow for the vulnerabilities into their security awareness classes and teach them ways to mitigate the issues for when they come across the issues in incremental scans throughout your SDLC. By giving them the tools and information they need to not only be able to reduce their security bugs, but also to fix the issues when they themselves find it, they’ll be empowered to incorporate security throughout their work.
It’s time organizations stop taking reactive actions when they’re breached, and begin concentrating on shifting security to the left. With a culture of shared responsibility for security in play, your organization will begin to proactively act on security and quit blaming the developers for not understanding what they were never expected to know in the first place.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.