Agile and Secure SDLC – Best Practices

Agile development processes help businesses release software much quicker than it would be possible if using classic design and development cycles such as those based on the waterfall model. Most web applications require an agile methodology because they need to be updated very often and very quickly to meet customer needs.

However, many businesses struggle with including security in their software development life cycle. Because of that, application security testing may become a major bottleneck and completely undermine the efforts invested in agile practices.

Let’s have a look at some secure SLDC best practices that will help your development teams become truly agile.

Close the Team Gap

Most businesses that develop their own web applications have separate software development teams and security teams. These teams cooperate through submitted issues and, possibly, with the help of project managers. However, there is rarely direct contact or cooperation.

If security tests are performed outside of the agile cycle, in final deployment phases (e.g. staging), this also leads to tensions. Security teams may find blocker issues just before a planned release, which may cause unexpected delays and put a lot of pressure on developers to fix those issues quickly. Sometimes, this can even lead to hostility between the teams and jeopardize the entire project.

The most important best practice for agile development methodologies is therefore to close the team gap between development teams and security teams. While the business needs a dedicated security team to develop security policies and handle security issues outside the SDLC, agile teams should also (ideally) include security experts.

For example, in many businesses that follow Scrum methodologies, an agile team includes not only developers and business stakeholders but also technical writers and user experience analysts. Therefore, there is no reason why such teams should not include a security expert as well.

Make Security Part of Code Quality

Software developers are expected to know how to ensure source code quality. It is usual practice that every piece of code that is written or modified goes through code review by another developer.

However, such code review usually does not include finding and eliminating security vulnerabilities. This is because neither the code creators nor the reviewers are properly trained to recognize such vulnerabilities and they don’t have automated tools to recognize them.

Security awareness must begin here, with the initial process of code creation. An SQL injection vulnerability in code should be perceived as a fundamental error, no different to using a bubble sort algorithm when quick sort is available.

Therefore, best practice is to have every developer in the company tested for their knowledge of security vulnerabilities that may be introduced into code. If they are found to be lacking in this respect, they should receive specialist training to teach them how to recognize and avoid potential vulnerabilities as well as fix them in other people’s code. Recruitment processes that involve a test of the developer’s abilities to write quality software should also test knowledge of security vulnerabilities.

No Application Left Behind

Large organizations often handle thousands of different development projects at the same time. These large projects are carried out by different organizational units, frequently in different countries. In such environments, it is common that DevOps teams work independently and there is little room for a unified SDLC model. This leads to some teams adopting secure practices for the entire software development life cycle while others release their applications with no security testing at all, leaving some applications severely vulnerable.

Even if an organization wants to globally unify the entire process of application development, testing, and deployment, it is often hindered by the differences in approaches taken by particular teams. For example, applications may be written using completely different languages, frameworks, and IDEs, and managed using different CI/CD and issue tracking tools. One team in one country may be developing applications in Java using Jira and Jenkins while another might be programming in PHP and using GitHub for both issue tracking and CI/CD.

In such conditions, introducing common, automated security testing into the testing phase of the SDLC may be very difficult. Not only does this require several different approaches, but if the organization wants to use SAST and SCA, it may simply be impossible to use the same tools for every team. This, in turn, requires separate management workflows, introducing even more potential problems.

The only viable solution in such cases is to use dynamic application security testing (DAST), which is language-independent and easy to integrate into CI/CD pipelines. This is why we would recommend that you start your secure SDLC efforts from DAST, not SAST or SCA. And when choosing your DAST solution, be sure to pick one that is designed to be included in the SDLC – like Acunetix.