Skip to main content
December 22, 2014

5 Flaws a Secure Agile Development Process Can Help You Avoid

5 Flaws a Secure Agile Development Process Can Help You AvoidYou know what they say: "Measure twice, cut once." But no matter how often code is considered, measured or tested, there will be problems developers simply forget to account for. It's easy to assume that pulling an API from a trusted site like Facebook means you'll be safe, but, well, you know what happens when you assume.

Before you start developing your next product, identify those unknown unknowns. Here are five common software security issues and how secure agile development can help you work around them:

1. Lack of Awareness

Part of safe development is knowing where problems occur, but because of the rapid and dynamic nature of threat evolution, just staying on top of hacking trends can become a full-time job. And though daily stand-up meetings are integral to agile development, you can't track fixes or note problems if you don't know they exist. The best approach to protecting your software from the newest threats is running a constantly updating security program. Then you'll have an inventory of fixes — and you won't have to put in extra hours.

2. Assumed Trust

In the secure agile development process, a comprehensive security solution includes running background checks on every crowdsourced piece of code. Whether you're inserting an API or building an application from scratch, you should never assume that a trusted name's code (or even your own) is safe. When agile team members huddle, they should ask themselves if all the necessary pieces of a project are in place. It seems obvious, but many teams are so excited to build that they forget to stretch — that is, vet external code — before sprinting. And while jumping into an agile sprint without testing all your code sounds silly, a lot of people do it. It's tempting to just trust components from big names, but the ruthless objectivity of comprehensive security software ensures time is saved in the long run. Besides, trust must be earned.

3. Missing the Big Picture

Developers don't always know exactly how their products will be used, or which external components might be combined with their software. Once a final product is delivered, an external component that has been erroneously trusted might create an XSS vulnerability that opens an entire network to hacking. Developers need great product specs to have well-organized and thorough sprints — and secure agile development vets all components as they're integrated into the process, ensuring that even preexisting pieces are penetration-tested before they're used.

Remember: It doesn't hurt to ask product owners (or potential consumers) a few questions before sprinting ahead with a product. Secure agile development involves cooperation between design and development teams, and feedback that provides more of a holistic understanding of an application's intended use can be incorporated into the security testing portion of the software development lifecycle.

4. Not Separating Data and Control

You don't have to be Thomas Jefferson to know that some things should be kept apart. During coding sprints, developers should be mindful of any data-input areas to ensure their software cannot be manipulated once it goes live. The best way to do that? Accounting for data and control in every product iteration. After all, just because a piece of software works doesn't mean it won't contain vulnerabilities. From XSS to SQL injections, major attacks can happen if data and control elements overlap. Software that's built to prevent the two from mixing creates a safer product for everyone.

5. Thinking Passwords Are Safe

It's quickly becoming clear that "password protected" is something of an oxymoron. We may not all be implementing two-step verification (yet), but that doesn't mean our products should be one-and-done deals. After authenticating a user's credentials via password-protected access, it's important to authorize any actions s/he takes. That's because not all users need the same level of access. Think about it: You may have a debit card and a PIN, but you can't withdraw $20,000 from an ATM, right? So, why should a username and password alone grant you access to sensitive data? Whether through two-step or independent-IP verification, some data deserves more than just one security layer. Building these rules into appropriate products prevents excessive authorization.

Nothing beats building an application right the first time. When you know what not to do, it's easier to develop safe software from the start. Secure agile development has processes in place that prevent these problems, but it takes a lot of hard work and a few mistakes to be a consistently secure enterprise. Knowing these five common mistakes and avoiding them in conjunction with a great security solution keeps your software secure.

Photo Source: Flickr

John is a B2B and SaaS expert who likes to explain complex concepts using cute animals and cocktail napkins. He believes that content marketing is the future and sometimes ghost writes, but he can never prove it.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.