<script> $( “Check Yourself” ) .insertBefore ( “You Wreck Yourself” ) </script>
Securing applications is usually a major pain for developers. You’re either stuck working at a snail’s pace or left out of the loop entirely.
Join the DZone community and get the full member experience.
Join For FreeSecuring applications is usually a major pain for developers. You’re either stuck working at a snail’s pace or left out of the loop entirely.
Traditional security tools work against development processes — they’re not agile and jeopardize release plans. This has pushed security out of the development cycle and into the hands of hired guns. While security professionals are fantastic at their jobs, there’s nobody more qualified to secure code than the people who write it.
Owning security means you can fix issues as if they were any other bug in the agile dev/test/fix process. It doesn’t mean compromising your sanity or workflow.
By embracing developer-driven security, you take the same responsibility for the security of your code that you take for the quality. While this might sound like creating work for yourself, this security-conscious approach to development will save you hours of post-dev keyboard-slamming (plus, your impregnable app will stand out from the comparatively unsafe competition).
To get you started, here are 5 ways you and your team can create more secure apps.
- Reviews Matter More In Development Than They Do In Hollywood
Design reviews — peer, communal, or simply DIY — during the development cycle can have a profound effect on your app’s launch-readiness. They allow you to catch and remedy security issues early in the game instead of waiting until after development (or worse yet, after launch). Your team, and the developer community for that matter, are an incredible resource: use it to your advantage. - Hack Yourself!
If thinking like a hacker will strengthen your code, hacking your code will give you a much safer app. Penetration testing can be automated with a number of applications or performed manually. Regardless of how you go about your hacking, we recommend using the OWASP Top 10 as a springboard. Take a look at the most critical web application security flaws (an updated list is due out this year) and see if any of them apply to your source code; if you stumble upon an exploit, fix it. - Investigate Embedded Systems
Treat embedded systems as you would any other facet of your code base. Most assume that they’re “safe” from external attack, but you won’t be protected against hackers who gain access to internal systems. Pentest them. Review them. Have your team do the same. Because they are closed systems, they rarely receive consideration during security evaluations, giving hackers the window they need to make your life miserable. - Prepare To Be Hacked
Even after you think you’ve shored up every potential hacksess point, prepare for an attack. While this may seem like paranoia, having a plan in place for how to quickly recover from a successful attack against any component of your system is integral. Know how to identify and combat threats and be prepared to distribute patches in an efficient, non-intrusive manner. - Be Transparent!
Your customers want your product. They also want to be safe. Share the security issues you uncover and alert your customers to the fact that you’ve addressed them. Communicate early and often. And, in the event and there is an attack, be completely honest. Your customers will appreciate being kept in the loop.
Write More Secure Apps Today
Software security has long been considered a slow, expensive process. The post-dev model relies on expert outsiders who, by definition, identify problems after an app is created. In a dynamic environment, this isn’t very effective.
A developer-driven model, however, is perfectly suited for writing secure code. By integrating security into your workflow you’ll strengthen your final product without driving yourself mad with extraneous processes.
Become a more security-conscious developer: join Jacks today.
Opinions expressed by DZone contributors are their own.
Comments