Agile software development is an approach to software development that seeks to help teams deliver value to their customers faster and with fewer issues than other software development approaches. As the name suggests agile allows teams the flexibility to respond to changes in the marketplace or respond to feedback given to the dev team by stakeholders/customers. However, when this speed and flexibility is adopted without adequate consideration it can come with potential security issues. Due to insufficiencies for security in regular development operations (devops), devsecops has become increasingly popular as a way to ensure that security is integrated in the software development lifecycle. DevSecOps is the practice of integrating security testing at each stage of software development. Integration of security into one’s development process is an important goal when it comes to cybersecurity. In this article we are going to discuss 7 security habits you should adopt as part of your agile process to make your development process more secure.
Agile development is all about being fast and flexible in your software development lifecycle. To facilitate this there are five main steps to the typically agile process:
Meet & Plan: In this phase the team gets together to understand what the requirements are for the software they are making, the features they want to create and do the overall planning for the work they are about to do.
Design: This is where the team works on the actual design of the software they are going to build. They take the high level ideas that they discussed in phase one and figure out the technical implementation for it. This typically involves the creation of architectural diagrams, database designs, and other technical documentation required to create the software.
Code & Test: In this phase the team builds the software and tests it to ensure that it works correctly. In this phase the software should not just be tested to ensure functionality but also for security issues.
Release: In this phase the software is released to its customers for use. This could be a release of a brand new software product or just a new version of an existing product.
Feedback: In this phase the development team receives feedback from the stakeholders using the application and use that information to plan for future software development activities.
While agile development allows for quick and flexible delivery of software products, it can lead to security issues because of the original way it’s designed. Firstly, fast turnarounds usually lead to dev teams neglecting or rushing their security reviews of code. Without quality security reviews there is a higher chance of security issues making their way into production.
Secondly, the agile process is a continuous loop, but often those loops focus on adding new features rather than the maintenance of old features. The development team can integrate sprints dedicated to fixing old bugs and (more rarely) code review, but unless that dedicated sprint is there most teams will never look into it, rather they will decide to focus on creating new features to meet customer demand. As a result, old security bugs can go a long time without ever being found or addressed.
Third, in most agile processes, there isn’t a dedicated spot for security. Developers are taught to release code after peer review and testing, but it’s important to have the testing done by a qualified professional. Agile can produce great results for dev teams by providing a quick, flexible process, but they have to make sure they can properly integrate security into their development lifecycle.
One of the main features of agile development is its rapid release cycle. While this is good for meeting customer demands, this quick process can lead to overlooking potential security issues.
One of the biggest challenges of implementing good security processes is the human element. When it comes to security, the quality of the code will be heavily affected by the knowledge of the developers. Many developers simply lack good security awareness and training around writing secure code and as a result they unintentionally introduce security vulnerabilities into the code.
Some development environments don’t have proper access control for their code repos and this can lead to unauthorized changes in the code. These changes will not be subject to the same level of scrutiny or testing as code changes that go through the proper change management process and this can result in the introduction of security vulnerabilities.
In some instances the software development environment doesn’t have security integrations in place to help control access to the dev environment. This can include things like MFA and SSO. This is important for ensuring that only authorized people can access and contribute to the company code repos.
A sensitive data management system is a system that facilitates the protection of sensitive data on a device, such as passwords. One example that is important in software development is a SAST or DAST solution. These are tools that can automatically test production code for vulnerabilities and leaked sensitive data. This is important for ensuring that sensitive data is not accidentally leaked into production code.
Another common issue is the lack of “Security champions” within the development team. Typically most developers are focused on writing good, effective code to solve a business problem or customer need. However, each dev team needs a member of the team that has a strong understanding of security best practices that can lead the security initiatives in the development lifecycle. In many cases it’s good to have dedicated security engineers on the team to fulfill this role.
The final element on this list is a lack of third-party and open source management. Whenever you are using outside code, it’s important to have a process for evaluating this and ensuring that it is free of any potential security vulnerabilities. One way to do this is to use dependency auditing tools that can evaluate the code being used in the application. An additional layer of protection can be to use subresource integrity validation, this allows you to check that the open source components that you are using haven’t been tampered with before being introduced to your code repository.
Secure code training is a great way to limit the vulnerabilities that will be introduced due to developers' lack of security knowledge. By teaching your developers secure coding practices they will better be able to self assess their code and avoid making mistakes that could introduce new vulnerabilities.
As part of your testing phase in Agile you should have a dedicated secure code review. This is simply a review of the application’s source code with the intention of looking for potential security issues. Ideally this should be done by a security expert rather than one of the devs that wrote the code themselves.
Another good practice for identifying security issues is to perform regular penetration tests. This is when you have a security professional perform controlled cyber attacks against your application to see what vulnerabilities exist and how they can be exploited. By having penetration tests done on a regular basis you will get reports that show exactly how your application can be exploited and what steps you need to take to resolve those issues.
If your application uses any third party components such as open source code libraries, third party hosting services etc then you should be doing a third party risk assessment for each of those components. There is a chance that these third party elements introduce new vulnerabilities or other forms of risk into your software, which is why third party risk assessment and management is so important.
While there are many benefits to agile software development, there are also some security concerns that need to be considered. This article listed seven of the most common agile practices that can produce security concerns.