The quick delivery of quality, working software is one of the key principles of agile development and this ethos is clearly outlined throughout the agile manifesto:
1 – Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
3 – Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
7 – Working software is the primary measure of progress.
Security isn’t specifically mentioned within the agile manifesto and historically, not many clients asked questions about it. This meant security was low down the priority list, if prioritised at all, and it’s easy to see a situation where an application met all the customer requirements but also contained major security vulnerabilities.
When security was considered, it was most likely positioned towards the end of the development process and penetration testing utilised to provide final security assurances before the software got signed off by the client or before it went live. This end of development security assurance testing still happens today, and the approach certainly has its place (as you will see). Any testing is better than none, but when testing is used in isolation, at the end of development, it can have potential problems.
Any vulnerabilities found at this stage will need to be fixed before release and depending on the severity of the findings, it could easily result in increased development time (and therefore costs) and could potentially push back any agreed completion dates. It’s certainly not a great situation for either party and it completely ruins the ethos of agile development, but it’s a situation we’ve seen happen time and time again.
Security is now rightly starting to move up the priority list and testing throughout the development process is considered highly beneficial, after all, the earlier you can implement security practices in the development lifecycle, the greater the return on investment typically is.
But how do you effectively test during fast paced development? You could make it the job of your development team, but they aren’t likely to have the specific security knowledge to provide the assurances needed, and they are already busy trying to deliver quality software. What about conducting penetration testing throughout development lifecycle? Well, there are several issues with this.
Firstly, there’s the issue of cost. Penetration testing isn’t cheap, so to utilise it during development would require some serious budget, a budget many simply do not have. Secondly, there’s the issue of scope. Agile development is all about fast incremental development, these increments can be small in scope and therefore would not warrant a full-scale test. Finally, there’s the issue of time. A full penetration test takes time to conduct, and then additional time to deliver the full report. As agile development is all about speed, this is time you just don’t have.
Agile development testing therefore needs a very different approach to work effectively.
1. Consider security from the outset & understand the key risks
Security needs to be considered at the very start of the development process and the security risks associated will be completely different for every project undertaken. Some development projects may need frequent testing during development due to the highly sensitive nature of software, or the data it holds. Others may only need one or two security testing checkpoints during the development process.
By considering the security risks at the start, and by engaging with your testing provider early, you get an understanding of the types of testing needed, how often testing will be required and at what stage these security checks need to be put in place. These can then be scheduled in by the scrum master, product owners and development leads to fit perfectly within the development timetable.
2. Use a mix of automated scanning and manual checks
Vulnerability scanning, automated source code analysis and manual testing each have their pros and cons, but why not combine the them to get the best coverage? Ok, you’ll need to get the balance right, and that balance will depend very much on the project being delivered, but if you do, you’ll be maximising your security return on investment.
But how do you get the balance right? Well, step 1 should have highlighted the key areas of development that need testing based on the risks associated. For areas with a lower risk, vulnerability scanning may be good enough on its own. But for those high-risk areas, you may want to run a vulnerability scan then manually validate the remediation efforts to ensure they are as robust as possible.
3. Immediate reporting of issues and support for dev teams
The speed of reporting vulnerabilities needs to match that of development and instead of receiving a lengthy report, development project leaders will want security testing providers to report vulnerabilities quickly via tickets, or even via development Slack channels.
This pace is essential and depending on the severity of the finding, fixes can be immediately put into the workflow or stored in the backlog for future attention.
Finding and reporting the issue quickly is only half the battle. Now a developer needs to fix the issue. But what happens if they are unsure of the correct steps to take or are unsure whether the fix is truly effective? That’s where you need the full support of your security testing provider. Providers need to be working in close collaboration with your team, helping to support them with any issues they may have following the report of a vulnerability.
4. Providing final security assurance
Ongoing security testing during development will help uncover vulnerabilities in targeted areas as you go, but it’s always advisable to conduct a final, full test of any software before release. Due to the ongoing testing, this penetration testing can usually be conducted in a quicker timeframe than if no testing had been undertaken. This is because testing can be mainly focused on the areas which have not been tested previously, whilst still ensuring that overall security of the software is robust.
This stage also provides you with the evidence you need to satisfy any customer security assurance requirements/questions.
5. Turn security into a USP of your development approach
Clients looking for software development services are becoming increasingly aware of security issues, security is quickly moving up the priority list and more and more security assurances are being sought before clients even consider starting any development work, this is especially true since the introduction GDPR.
By developing a robust approach to security during the agile development process, and by working with a testing company experienced in agile testing; you instantly stand out from the crowd. Demonstrating your commitment to secure products and dealing with any client security questions head on.
