By Carlos Bezerra

The challenge of developing a secure software, in agile time, can be overcome with the proper use of security processes and tools, which, associated with agile methodologies, will result in secure development practices for agile teams. In this article, we will show some of these practices, which are based on others already existing in the market but directly related to agile development.

Security in software development is becoming an increasingly evident demand in the market. For this purpose, several practices are still being created. To name just a few, we have, for example, Microsoft’s set of practices (MSDL), the Seven Touchpoints for Software Security and the Common Criteria standards. Another process of secure development, and also with great success in the market, is the OWASP SAMM , a more mature model for the development of secure software, which today is in version 2.0., being the replacement of CLASP, also the OWASP project.

With increasingly tight deadlines for software projects, agile methodologies have been widely used in the area. However, which are the security practices that best suit such methodologies? Defining these practices is essential because, in addition to choosing the agile method, the client needs to request, and prioritize, security; so that it can be included as a requirement in the project, since this does not always happen.

Trainings on the importance of safety should prepare, educate and train project stakeholders. The plan for security training should address topics such as: privacy policies, basic concepts, major attacks, defense strategies and threat modeling. Obviously, training directed to the daily work of the team should be prioritized; as, for example, its consonance with the technologies used in the solution to be developed (Web, Mobile, Cloud). In addition, it is important that all participants involved in the process carry out training aimed at their specific needs.

It is also recommended that new team members carry out the trainings, even the most basic ones, if possible, before entering a project already underway, so that such trainings can be part of their onboarding. And even for the older members, it is recommended that the trainings be made available periodically, so that everyone can go through them, as well as for technical recycling or learning reinforcement. It is also possible to include this practice during the iterations of the project, when it is necessary to address specific themes or even to update team members. However, this is a more costly approach, which may affect the development of the project.

Hiring specialists to promote the training within the project environment may be the best way to carry it out, given their experience and practice, both in terms of safety and didactics, if they are familiar with the training offer. The experience of professionals who specialize in the area allows them to have knowledge about the most important themes for certain teams. In addition, they can bring more current content on the subjects addressed in the project. Of course, as we stressed above, this approach is more expensive and demanding, not only financially, but also in relation to ‘time’. Conducting these trainings for a team, or part of it, requires planning and spending financial resources; in addition to consuming considerable ‘time’: an essential but often scarce element in agile development teams.

Alternatively, training platforms can be used that address the security issue from different points of view; or external training can be encouraged, which can be done by team members, both individually and jointly. Online training can be financially less costly and easier to adapt to the time available, due to its flexibility regarding schedules and the fact that it is available on an individual basis. However, it is extremely important to pay attention to the quality of the material chosen, thus avoiding expenses that bring unsatisfactory results.

Naturally, providing training will always add to the development cost; so, keeping the staff trained implies in value passed on to the customer, in the final price of the product. However, this helps to prepare everyone involved to deal effectively with security requirements. In addition, the effectiveness of the following practices will depend substantially on the level of staff training.

It is necessary to ensure that security requirements are discussed by the development team with the cliente so that, together, they can mitigate problems related to failures caused by their lack of elucidation. Thus, defining the security requirements has as its main objective the identification of functionalities related to security, so that they are clearly described within a secure software development project. It is worth pointing out that, besides the security requirements, one must not forget the solution requirements, which must expose security characteristics, as part of their definition; both being important and, therefore, requiring the due attention.

Photo by Matteo Vistocco on Unsplash

Just as the team helps the client understand and define the project requirements, so should the security requirements. If there is the role of Security Master or Security Champion in the team, they will have the responsibility to provide support to the team during the survey of these requirements. However, it is not always possible to have this role in the development team; in these cases, another member of the team must assume this role. As a rule, of course, the person in charge must be a professional with experience in security; and, if this is not possible, he or she must at least have the support and guidance of someone with experience in security, even if the latter is not part of the team.

These requirements should be updated and reviewed at each cycle, so that they can reflect the changes that occur, naturally, along the stages of agile projects, thus allowing to consider changes in threat scenarios. A practice that can also help in the definition of security requirements are the Evil User Stories, where possible scenarios of security threats to the system are described, demonstrating how the system can be affected by attackers. However, this practice is only effective if there are professionals with a security profile available to describe the scenarios, as well as their possible mitigations.

Since the implementation of security requirements adds time and cost to the project, it must be agreed with the client; so that, if the client, although aware of the importance of secure development, chooses to restrict these requirements, they can still consider, within their deadlines, objectives and costs, the risks assumed by not performing this task properly.

Several development teams apply implementation practices as a way to maintain the quality of the code, being Clean Code one of the most widespread. Similarly, these rules can be defined for security. In order to avoid the most common mistakes during implementation, development teams should establish the set of development rules, focusing on good practices related to software security. These rules should specify some important points, such as the treatment of user input or the improper use of obsolete functions. It is important to keep in mind that, in order to comply with the purpose of being secure, a resilient and maintainable code should be written in relation to security; in other words, a code that can be maintained, and that is flexible, and therefore easily adaptable, thus resisting the insecurities of the scenario of vulnerabilities and increasingly intense and recurring attacks. For this, the optimization of security implementation rules, for secure and agile development, must be considered.

To start this step, you must define which rules the programmers must follow to write a secure code. Many of these rules can be listed through training and research. In addition, many of these rules can be extracted from the official programming language guides, which aim to guide the safe development of these languages. Other practices can also help to define these standards, such as, for example, the definition and use of encryption standards as pointed out in the MSDL, cited at the beginning of this article.

Using code review practices, already used by other development teams, in order to validate the use of the defined safe implementation rules, is also a positive strategy. Thus, reviewers should observe whether the defined rules are being followed and, if possible, pay attention to other security problems that may exist in the code. This will contribute to the inclusion, over time, of new rules to the process; as well as to the gain of experience by the developers.

Another method that can be used to validate the safe implementation are the automated tests, a practice already widely implemented in several software projects. The purpose of this practice is to implement verification functions that prove the correctness of the implemented requirements. Taking advantage of the implementation of these tests and including validation of security related functionalities can increase the software reliability. From this point of view, if there are security checks, one can be more certain that the developed code will not be distorted in future changes. And, if this occurs, the tests, if well implemented, should fail; making it clear to the developer that unwanted changes have occurred.

Ensuring that the project’s source code is analyzed for security flaws is essential to validate the security of the implemented software. This practice consists, basically, in two verification methodologies: Static Code Analysis (SAST) and Dynamic Code Analysis (DAST). The first one analyzes the pure code, based on predefined verification rules, in search of code snippets that present security problems pointed out by the adopted rules. The second one analyzes the solution, at runtime, along with all the code from the language libraries, and from third parties, incorporated during the implementation. From the results presented by these approaches, it is possible to measure the code’s compliance with the security standards defined in the project’s requirements.

Photo by Andy Beales on Unsplash

For all the approaches reported above, there are verification tools, which are reliable as long as they are configured. The development team should use these tools, according to their needs, depending on the language and processes used. The results should be analyzed and, if necessary, tasks should be added to the backlog to correct the problems found.

This type of analysis, by means of using tools, will prevent already known errors of languages, bad safety practices and other common scenarios. The use of this practice does not necessarily imply that the code is free of vulnerabilities. These tools only search for already known patterns. The great advantage of these tools is, still in the implementation stage, to raise and correct the most common errors, allowing specialized tests to be focused on more complex problems, that is, the errors that would not be captured by these tools.

The configuration of the code verification tool(s) must be done in the first iterations of the project, remembering to validate and update it whenever necessary. Once configured, the team must find the best time to execute it. Tests performed by tools can be executed in all development iterations. Moreover, teams that work with CI/CD can add the execution of these tools within their respective pipelines. This way, at each software integration to the main code base, a verification round will be performed. These tools can also be executed on time, to validate the correction of certain bugs or to evaluate more critical pieces of code.

Of course, no matter how much developers try to implement the software with the best security practices, vulnerabilities will continue to be incorporated into the software involuntarily. To solve this problem, it is essential to submit the software to tests performed by security experts, in order to ensure the security of the software. The experience of the specialists, added to the attacker’s mindset, allows them to find flaws that have been ignored, or later inserted, in the development process. Moreover, as it is a specialized analysis, these professionals can point out the most suitable methods for correction, the associated risks, the ease of exploitation, the impact on the business, among other aspects that would not be possible to be extracted by tools or by the development team.

Specialized tests include, but are not limited to: Penetration Testing, Red Team Testing, Risk Based Testing and Vulnerabilities Assessments. The application of specialized testing typically requires the presence of one or more security experts. Therefore, to apply this method, it is necessary to hire a specialized company, or specialized independent professionals. In more critical scenarios, the project itself can count on a team of these professionals to perform this function. In any case, the most appropriate method to test the software must be agreed with the specialists, so that the task is carried out in the most efficient way, following the specific characteristics of each project.

The ideal time to apply this type of test would be coincident with the release of each version of the application. However, this ideal configuration is not always possible, due to numerous adversities and restrictions. One possible approach is to perform these tests before each Major Release, that is, deliveries that change many aspects of the software and include several new features. It is the responsibility of all people involved the definition of a schedule to perform these tests, so that the software is tested in the most appropriate way possible. It is also important to be alert to the risks taken in case it is not possible to perform tests on all versions of the software.

Of course, these are not all the existing practices that there are, nor do they guarantee the resolution of all problems related to the security of a software project, since there are numerous other aspects to be taken into consideration. Besides, none of these practices are mandatory. In addition, the project will not necessarily be unsafe if all, or some of them, are not followed. However, considering and adapting these practices in the development process certainly contributes to an improvement in the security of the software developed. After all, if it is necessary to be agile, and, as we know, haste is the enemy of security, it is crucial to pay attention to the mitigation of vulnerabilities in secure development practices for agile teams.


The content of this text was produced based on a Course Conclusion Paper [1] and an article in QUATIC 2020 [2], both by the same author:

[1] BEZERRA, C. M. M.. Políticas para desenvolvimento de software seguro em time ágeis. 2019. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) — Universidade Federal Rural de Pernambuco. Disponível em []

[2] Bezerra C.M.M., Sampaio S.C.B., Marinho M.L.M. (2020) Secure Agile Software Development: Policies and Practices for Agile Teams. In: Shepperd M., Brito e Abreu F., Rodrigues da Silva A., Pérez-Castillo R. (eds) Quality of Information and Communications Technology. QUATIC 2020. Communications in Computer and Information Science, vol 1266. Springer, Cham.