Introducing Checkmarx Software Composition Analysis (CxSCA)

Six Steps to Secure Software Development in the Agile Era

Written in 2001, the Agile Manifesto launched an evolution in software development that has unfolded over the past decade and a half. Moving from waterfall development to rapid development and into the Agile methodology, software companies around the world have adopted at least some of the Agile processes and practices. And for many organizations, the evolution has paid off – at least in some parts of the business.



In the world of Agile development, new versions and small updates are released daily for many companies, where small teams work side-by-side to improve products on a daily basis. Agile offers benefits including higher confidence by customers, ability to make changes and fix issues immediately and in small increments, better, faster testing, and improved planning. Tech companies like Netflix, Etsy, and Amazon have become household names to watch, thanks largely to how they innovated (and continue to innovate) using the Agile methodology.


The premise of Agile is to give the customers what they want, quickly and efficiently, while also saving time and resources on the business side. And, as research shows, Agile does that and more. Yet, what many Agile organizations have conveniently forgotten is the whole security part of software development. The Agile Manifesto itself, while it may allude to it with principles including the “delivery of valuable software,” neglects to mention any security practices explicitly. So while Agile is a huge step forward for software and tech companies around the world, many Agile organizations are missing a vital piece of the puzzle.



The Problem with Secure Software Development in the Agile Era


Our current situation is that most organizations have or are planning on adopting Agile principles in the next several years – yet few of them have figured out how security is going to work within the new methodology. The changes that Agile brings – frequent product releases and dynamic feature changes, among others – create a wholly different threat landscape from those posed by waterfall development methodologies.


There are plenty of reasons why security is left behind in many Agile organizations, but for the sake of brevity, we’ll break it down into two main issues.



  • Security is seen as a ‘Non-Functional Requirement’ (NFR), a requirement related to the state of the system, rather than, as the name suggests, functional areas of the system.



The problem with NFRs in Agile organizations is that they are hard to pin down in user stories, a main feature of the Agile methodology.


User stories follow a structure of “As a (type of user), I want/need (some goal/desire) so that (reason for goal/desire)”. Each requirement is crafted into a story with a reasoning for the requirement, so that developers can plan for the experiences real people will have with the project. These stories closely guide team planning and development. Security requirements can be hard to turn into tangible stories. Especially given the fact that security controls often arise through risk aversion processes that include looking at the full threat landscape, security can be hard to pin down to one story in one application. It’s not impossible, but a lack of strong security user stories can easily prevent security from being planned or implemented correctly.



  • The second reason why security and Agile have historically been at odds is a lack of Agile-ready security practices and tools.



In waterfall methodologies, security planning is done at the beginning, while security testing is accomplished at the end. Security is missing from the whole middle part – the development process. While this may have worked to some degree in waterfall development organizations, it simply can’t in Agile. When it comes to Agile, security requirements and processes need to be synced up to business requirements. Security can’t (and won’t) be done in a vacuum – Agile organizations, and the security teams within them, need to make sure security fits in with the rest of the crew.


Agile needs security to work. Because of the speed and number of small teams working on different projects, security testing can’t wait until the end of the lifecycle – it needs to be well-integrated and continuous, and at least partially managed by the development team.


Secure Agile Development is not a mythological creature: it can be reality. What it takes is a real understanding of the essential nature of building security into their products – and making sure that proper resources are allocated to fix this.


The fear for many Agile teams is the sheer nature of security testing – it seems too big and bulky to be brought into an Agile environment. Yet this is where Agile gets it wrong – security testing no longer has to be accomplished through nightly scans that find hundreds of high-vulnerability issues requiring a fix ASAP.



Creating a Secure Development Lifecycle in an Agile Organization


So, in the face of a movement that’s not likely to lose steam in the future, it’s up to organizations to ensure they’re implementing security correctly – and in ways that make the most sense in an Agile environment. What steps can you take to make sure security works in Agile organizations? Here are the top five ways to ensure secure software development in the Agile era.  



  • Build Security In Through User Stories


To help put the first aversion to security to rest, security teams need to help development create real, functional stories for security requirements. These stories, as discussed earlier, define the business requirements of a certain application, which are then broken down into distinct tasks to be accomplished during and after development.


By creating stories surrounding security activities and risks to add to the backlog of stories Agiles teams use to plan software, you can ensure security is planned for. If you need some help getting started with secure user stories, SafeCode, a non-profit dedicated to helping organizations secure their code, offers 36 security stories to help you start your own backlog (pages 6-28).


On the other hand, you’ll also want to create ‘evil’ user stories, where the ‘users’ are hackers trying to get into the system. OWASP, for example, offers these ‘evil’ user stories:


  • “As a hacker, I can send bad data in URLs, so I can access data and functions for which I’m not authorized.”
  • “As a hacker, I can send bad data in the content of requests, so I can access data and functions for which I’m not authorized.”


For more on ‘evil’ user stories, this OWASP article offers some more ideas.



  • Put Developers in Charge of Secure Development


If security is going to work in Agile environments, one of the most important changes to make is making developers responsible for secure development.

Why is this so important? Because as we currently stand, there are an average of 100 developers for every member of the security team, severely cutting down the ability for the security team to take responsibility for all aspects of security. So to offset this imbalance and also ensure security is implemented and taken seriously, it’s crucial to give developers security responsibilities.


The security team should still have input and involvement in the planning and later testing phases, but during core development, programmers should be put in charge of security scans and fixing the issues they find. This is a great way to help push security into earlier stages of the software development lifecycle (SDLC), where security issues are best dealt with.



  • Integrate Continuous Integration Security Practices in the SDLC


Unlike the past, there are now application security tools on the market that are primed for use in Agile organizations. Modern application security solutions can integrate with current development tools, from bug trackers to code repositories to build management programs for easy-to-learn and easy-to-use security scanning and secure code fixing. By arming the developers with security tools like static code analysis that are built for use within the development environment, they’re much more primed for security success.


Read about the 4 Steps to Security Testing in the SDLC.



  • Adapt, Iterate and Grow to Keep Security Agile


Embedded within the Agile methodology is the requirement to continually measure, adapt, and attempt to improve current tools and processes. This is part of the fluid nature of Agile’s need to continuously change to better fit the needs of the teams and the business as a whole. To keep security relevant within the confines of an Agile organization, it’s important to do the same for security.


For example, security user stories, as all Agile user stories, will need to be changed over time to better adapt to current needs. The security industry is changing rapidly just as development is – and it’ll be up to the security team to ensure all changes are appropriately covered. As new tools and processes are introduced or changed, so too will security need to be adjusted.



  • Build a Security Culture through the Above Practices and Beyond


The biggest changes in software development have to do with organizational culture shifts. Agile not only changed the way software is created – it changed whole organizations from within. Likewise, security culture will be changed over time, as the above steps are followed, day-in and day-out. Habits were formed, new processes developed to better fit the group or need, tools and practices that no longer served the Agile methodology were thrown out. In this way, security can also become a part of the culture. Through the above steps and through fitting security into the Agile methodology the best way for each organization, security will become a habit, that over time will become part of the culture.

Jump to Category