How to introduce security testing to your web app deployments during QA
Fixing these vulnerabilities in production is more expensive than finding and fixing them earlier in the SDLC. One way that organizations can drive down the cost of vulnerability management is by integrating security testing into software quality assurance (QA) testing.
Security testing is often neglected in the software development lifecycle (SDLC). In general, compensation for developers focuses on shipping code, not testing for security issues that, when discovered, may require extensive reworking of an application.
However, this approach to security can have a significant cost for an organization and its users. Approximately 30% of web apps contain an exploitable or high-risk vulnerability. An attacker who finds and takes advantage of these vulnerabilities may be able to perform a data breach or other expensive and damaging cyberattacks. These security incidents can also cause significant reputational damage to organizations and result in loss of revenue or shareholder support.
Approximately 30% of web apps contain an exploitable or high-risk vulnerability
Fixing these vulnerabilities in production is more expensive than finding and fixing them earlier in the SDLC. One way that organizations can drive down the cost of vulnerability management is by integrating security testing into software quality assurance (QA) processes.
Where does web app security testing fit into the SDLC?
Ideally, security should be integrated into every stage of the SDLC. The faster a security issue is found and fixed, the less technical debt and wasted resources it accrues. This is how security testing can be built into an organization’s web app development processes.
Planning and Design
The first two stages of the SDLC focus on defining the requirements for the application and developing a design to meet those requirements. Often, these phases are focused on ensuring that the application includes the required functionality.
While not security testing, it’s important to integrate security into the planning and design phases of the SDLC. This includes defining security requirements in addition to ones focused on the functionality of the application.
Security testing should begin during the development stage of the SDLC. As application code is being written, it should undergo a few types of testing, including:
- Unit Testing: Developers commonly write unit tests against functional requirements alongside the code being tested. After defining security requirements in the previous stages, unit tests should also be created and executed to validate these security requirements as well.
- Static Application Security Testing (SAST): SAST tools look for common vulnerabilities and other coding errors in application source code. SAST tools can be integrated into automated DevOps pipelines to scan code before it is committed to a repository, reducing the risk of introducing errors and vulnerabilities into the codebase.
DevOps pipelines and orchestration tools enable security testing to be performed automatically. This removes friction for the developer, enabling fast releases while also increasing the quality of the final product.
At the testing phase of the development lifecycle, a complete, runnable version of the code should be available. This enables different forms of security testing to be performed, including:
- Fuzzing: Fuzzing involves providing random, malformed, and potentially malicious inputs to an application. A fuzzing tool aims to identify potential errors or vulnerabilities in an application by introducing undesirable behavior. If an application crashes or otherwise performs in an unexpected manner, then it has failed to properly sanitize or manage user-provided input, which is an error that should be corrected before deployment.
- Dynamic Application Security Testing (DAST): DAST is a security testing tool that works on a fully functional application and can identify various vulnerabilities that can’t be identified via SAST. For example, DAST can identify issues with user authentication or configuration problems.
- Software Composition Analysis (SCA): Applications commonly contain third-party code in the form of libraries and copy-pasted code. This code could contain vulnerabilities or malicious functionality inserted by cybercriminals. SCA helps to identify an application’s dependencies so an organization can determine if these third-party components contain known vulnerabilities.
Like the testing performed during the Development stage, these tests can be integrated into automated DevOps pipelines. This enables testers to quickly determine if code contains vulnerabilities that require correction before release.
Deployment and Maintenance
The final two stages of the SDLC occur after an application has been completed and tested. During these stages, the application is deployed to production systems and maintained throughout its lifecycle until its eventual end of life.
Ideally, all vulnerabilities in the application’s code will have been identified and corrected before this stage. In reality, many production applications contain undetected vulnerabilities that leave them vulnerable to exploitation. These could include overlooked vulnerabilities or new vulnerabilities in components or third-party code that were unknown at the time of development.
Throughout the application’s lifecycle, it should undergo regular testing to help identify and fix any production vulnerabilities. These regular tests should include the following:
- Vulnerability Scans: A vulnerability scan is a fully automated security test designed to identify known and common vulnerabilities in an application. These automated tests should be performed regularly to ensure that no vulnerabilities have been newly discovered or introduced in an application’s code.
- Penetration Testing: Penetration testing combines automated testing with human knowledge and expertise. Using humans to guide a test makes it possible to identify vulnerabilities and chains of vulnerabilities that can enable an attacker to achieve a particular objective. Penetration tests should be performed regularly, at least quarterly, but ideally much more frequently.
The Maintenance stage of the SDLC lasts the longest, for the entire lifetime of an application. Vulnerability scans and penetration tests should be performed regularly until an application is retired to protect against exploitation of unknown vulnerabilities.
Securing Web Apps with Sprocket Security
Regular, automated security testing is vital to the security of web applications and the efficiency of the development process. Vulnerabilities in production systems place users at risk and require additional work to develop, test, and distribute patches.
Sprocket Security offers Continuous Penetration Testing, Attack Surface Management, and adversary Simulation services to help organizations identify and correct application vulnerabilities before attackers can. Sprocket Security’s continuous testing combines human-driven testing with automation to provide ongoing security evaluation and vulnerability testing for an organization’s web applications. For more information about our security testing services and how they can enhance your organization’s web application security, check out this free demo.
Continuous Human & Automated Security
The Expert-Driven Offensive
Continuously monitor your attack surface with advanced change detection. Upon change, testers and systems perform security testing. You are alerted and assisted in remediation efforts all contained in a single security application, the Sprocket Platform.
Expert-Driven Offensive Security Platform
- Attack Surface Management
- Continuous Penetration Testing
- Adversary Simulations