<img height="1" width="1" style="border-style: none;" alt="" src="//googleads.g.doubleclick.net/pagead/viewthroughconversion/1064346053/?value=0&amp;guid=ON&amp;script=0">

Agile Security Testing Approach for Scrum Based Development Projects

artistic image showing lock

As healthcare applications become more complex, their ability to manage sensitive information like patient data significantly improves. Many of these applications work over the internet, increasing the risk of data theft or exposure. It becomes important to perform security testing of the components implemented and identify the security vulnerabilities during the software development lifecycle.

Testing in the Scrum based model involves understanding of scope, architecture design, planning, coding, and functional testing. Security testing is performed before the release phase of the Software Development Lifecycle (SDLC), which increases testing costs and causes delays in product release. To manage this effectively, Agile Security Testing and ‘Shift-Left’ is gaining wider acceptance. The Agile Security Testing strategy should complement the agile development approach to achieve a stable qualitative build and have the right set of functionalities with a fair degree of security. Integrating security testing with the mainstream software development process has multiple benefits.

figure showing agile security testing

The key elements of Agile Security Testing in a Scrum-based software development model are:

1. In-Sprint Planning

During this phase, a security consultant understands the scope and security features required from the selected user stories. The consultant then creates test scenarios and identifies the testing toolset.

2. Secure Architecture Review

Working closely with the solution architect, the security tester initiates the architecture review of the product to provide security related features and implementation guidelines. The security tester also observes the existing features selected for security implementation, and focuses on basic principles like authentication, authorization, security of data in transit and at rest, audit logging, etc.

3. Static Code Review

Static Application Security Testing (SAST) is a white-box testing method where the application source code is reviewed for conditions which indicate presence of security vulnerabilities. SAST is performed using automated scanners (e.g., HP Micro Focus Fortify, IBM AppScan Source, CA Veracode, Checkmarx, etc.) and should support the programming languages and development frameworks in which the application is built.

SAST scanners have wide vulnerability coverage since they have access to source code and application inputs, including hidden inputs. Because of this, SAST may be prone to reporting false positives.

The static code review is the only available option during the initial stages of the sprint / release when there are no dynamic application modules available for testing. A complete scan of the source code is recommended when the code base is ready for testing before the release.

4. Dynamic Application Review

Dynamic Application Security Testing (DAST) is a black-box security testing method where application is tested from the UI in running state (from a hacker’s perspective). Security testers usually use DAST automated scanners (e.g., Acunetix, HP WebInspect, IBM AppScan, PortSwiger Burp, etc.) to access the application from outside and are mostly technology independent. Although easy to reproduce or identify vulnerabilities, DAST tools can test only vulnerabilities which send a response back to the scanner. DAST tools are prone to false negatives on missing vulnerabilities that don’t send any response back to the scanner.

Security testers then share the identified vulnerabilities along with proof of concept and mitigation options with developers.

5. End of Release Testing

The entire integrated application is available for testing and most vulnerabilities have already been identified and mitigated in previous sprints. Security testers can now perform penetration testing and automated tool-based scans to identify any remaining vulnerabilities. At the end of release testing, the team can focus on more sensitive features to verify that the product is secure. This phase includes several types of testing such as:

    • Automated Scans: Automated scans (e.g., Burp Suite, Acunetix, etc.) are performed to identify potential vulnerabilities (architecture / component-level weaknesses) in the application.
    • Penetration Testing: Manual penetration testing is performed to demonstrate exploitation of security vulnerabilities and weaknesses present in the application or environment. This is typically carried out post automated scan, since the probability of false positive defects is higher in automated scans.
    • Network VAPT: Network VAPT (e.g., Nessus, NMAP, QualysGuard, etc.) ensures that all resources like servers, network devices (routers, switches, and firewalls) have updated patches. It also helps identify and fix network security related flaws.
    • HIPAA Compliance Testing: At the end of the release, security testers can also test conformance to HIPAA based on security identity access management, access control, encryption, and audit controls.

Implementing security testing in an agile fashion has several advantages in terms of cost and time saved by minimizing rework. The collaborative nature of agile models increases the development team’s awareness of security vulnerabilities and associated remediation plans, to ensure lesser vulnerabilities in the future.

Security testing at the time of release reveals fewer security vulnerabilities as compared to a continuous approach. The continuous approach necessitates the team to fix the issues and benefits from having the mitigation effort spread over the entire release, instead of a large and often expensive push at the end.


Related to topics:

Explore other blogs

CMS 21st Century Cures IPA Rule & its Impact on State Health Agencies
CMS 21st Century Cures IPA Rule & its Impact on State Health Agencies
Analytics Opportunities for Payers from CMS Regulations
Analytics Opportunities for Payers from CMS Regulations
Payviders: Enhancing the member experience by creating more personalized digital touchpoints I Part 2 of 2
Payviders: Enhancing the member experience by creating more personalized digital touchpoints I Part 2 of 2


No items currently match your filtering criteria.