Following the emergence of SCRUM, we, software designers, have become more and more focused on agile practices and their benefits for end users. Despite the success registered by all IT agile projects, engineering and agility have become rather opposite than complementary ends and agile frameworks don’t bring enough specifications on software development practices. This is also the case of security practices. Generally speaking and regardless of the development methodology, what we could notice during technical audits is that security and performance criteria are often neglected by developer teams.
If the Definition Of Done must be linked to the Product Owner’s needs, then the Product Owner rarely has a software security-oriented background. In this context, what will be the minimum to build a high-quality level product in this field? Our experience tells us security should play an important role in every Agile project element. Project architecture and design are the critical points dictating the IT project security level. Operationally speaking, security tasks have a higher priority in the backlog and should not be disregarded during difficult sprints.
We have identified 13 important elements to follow concerning the implementation of software security during an agile software development project. Even if certain of these elements will be further tackled, we wanted to synthetize them in what follows.
This document is a checklist with project security elements and possible attacks and is declined in the PBI (Product Backlog Item) techniques and in the Definition Of Done. This integration step in the Product Backlog is crucial and avoids dispersion, knowing that for example in Scrum, Developers do not have the right to work on other things than the Backlog. These PBIs will have a higher priority.
Initialisation of automated tests
In this stage, the team has to choose the potential tools for test automation (software security, performance, non-regression, integration, validation, unitary and acceptance). Often, the teams will add the decisions related to the automatic tools during retrospective meetings, depending on the progress and feedback at the end of each sprint.
There are two large categories of tools:
- Code analysis tools: these tools generate reports on the current status of the code. Certain actions of code review can be replaced by these tests.
- Test execution tools: these tools run software security tests on the running application. The Fuzz tests are a good example. This type of tests consists in providing any type of data (valid, unexpected, random) to application input. For IT web projects, there are specialized attack tools (Cross-Site Scripting etc.).
Iteration remains at the core of the Agile project. It is here where the team’s level of knowledge should be guaranteed. The new members and those that exceeded a certain team integration period will follow a course on the project security rules. The role of the knowledge sharing community is also essential as this entity lives in the iteration.
Analysis of the attack surface
The attack surface is represented by all the project technical elements in contact with the users or the exterior. It is actually the entry point of most attacks. The team formalizes the attack surface in categories and priorities to ensure a good level of global security on the IT project.
This article was written by Irinel Matei, former .Net expert at Pentalog