How to implement security measures without negatively affecting software quality

Over the past decade, most organizations have established a well-oiled process for software development and maintenance. We refer to this as the software development life cycle (SDLC). However, advancing security threats relating to insecure software have brought the focus to security implementation within the SDLC without hampering quality.

Let’s examine a few strategies to implement security measures without negatively affecting software quality.

An introduction to the SDLC

A process for software development, the SDLC describes the planning, design, implementation, deployment, and maintenance journey that a software product moves through. Software development teams follow the organization’s SDLC process to produce high-quality, robust software.

While each organization may have different nuances in place, the overall SDLC process is comprised of the following phases:

1. Planning
2. Design
3. Implementation
4. Verification
5. Release
6. Response

It is common for organizations to only perform security testing during the Verification phase (also commonly called the Testing phase) of the SDLC. A late introduction of security may result in security issues that are recognized late in the product’s life cycle, if at all. Resolving issues later in the development process takes more time and effort than remediating them earlier. For this reason, it’s essential to implement security measures during each and every phase of the development process.

But how? Let’s start from the beginning to show you.

Software security in the planning phase

The Planning phase is a critical phase of the SDLC—the foundation. During this phase, system analysts collect product requirements from customers and users. The analysts interview the customers to understand how they aim to use the system.

Creating the complete set of requirements during this phase helps improve product planning. It also helps to eliminate late changes to the product. Requirements are documented and approved by the customer and business analyst before moving into the Design phase.

The system analyst should then shift their attention to working with a security expert to gather security requirements. In other words, requirements that focus on requirements that may not be necessary to the software’s operation—but they’re essential to make the software secure. The primary purpose of security requirements varies from providing access control to maintaining system confidentiality and data integrity.

Software security in the design phase

System architects use the requirements documentation to design the system architecture. Design demonstrates different components of the product along with internal and external communication. It also accounts for the data flow between different system components. During design, a system architect must consider attributes of secure architecture to produce a secure design.

A system’s architecture is one comprehensive model indicating where defects can be introduced into software. When compared to implementation bugs, remediating architectural flaws often involve a much higher cost to resolve. Thus, it’s critical to eliminate flaws before the software product moves into the Implementation phase.

Conduct architecture risk analysis (ARA) to identify defects and resolve them before moving forward. ARA assesses risks emerging from architectural flaws in the system. It provides specific remediation advice for individual defects. Prioritize risks based on their business impact. Once remediation recommendations are made by the security team, re-assess the software to this point to determine the efficiency of those recommendations.

Software security in the implementation phase

This is where actual product development begins. A team of developers use their programming knowledge to implement the design into modules of code. Developers should be aware of secure coding guidelines to ensure that both security and quality are considered during development. Where architecture design introduces approximately 50% of a system’s security defects, the Implementation phase introduces the other 50%—implementation bugs—into the system. This fact emphasizes the importance of security testing during this phase.

What do all software products have in common? If your answer was something along the lines of ‘the presence of code’ then you’ll understand the value of secure code review (SCR) as a security testing mechanism. SCR is the strategic review of a piece of code to identify potential security vulnerabilities. Code review can be as simple as having a development colleague review your work. Or, you can go a step further and have a security expert review it in coordination with advanced static analysis tools. Always follow up tool-driven testing with a manual analysis of the result to ensure that the defect findings are in fact true positives. The goal of SCR isn’t only to identify bugs in code, but also to recommend corrections for remediating those bugs.

Static application security testing (SAST) is a testing process ideal for Implementation phase as it puts the emphasis on the application code. SAST analyzes the source code to determine the presence of security vulnerabilities.

In addition to SCR and SAST, organizations must train developers to ensure they’re up to date on current security trends and common coding mistakes that can result in bugs. Consistent training helps to improve the coding standards across the organization in addition to curtailing the number of bugs in your firm’s code.

Another important note to remember is that developers usually don’t consider code review until the end of the development cycle. However, you need to perform code review as soon as the Implementation phase gets underway. This reduces cost overhead and remediation time for bugs.

Software security in the verification phase

Now we arrive at the software testing phase of the SDLC. The product is thoroughly tested for performance and robustness as developed code is put through trial by fire. The application is deployed within a test environment where dedicated testers examine quality and security measures of an application from a business and end-user perspective.

It’s extensively tested to ensure that the software performs as it is intended. Penetration testing and dynamic application security testing (DAST) ensure that it can withstand a wide variety of security attacks.

Penetration testing takes place when a security expert impersonates an attacker to exploit security weaknesses and/or bypass current security controls. It could be as simple as identifying weaknesses in underlying servers, or as advanced as bypassing authentication mechanisms to obtain unauthorized access to an authorized user’s account.

DAST hunts for security weaknesses and vulnerabilities within a running application. DAST tools employ injection techniques, feeding malicious data to the target system to identify vulnerabilities such as cross-site scripting (XSS) and SQL injection, among others. These tools also helps identify infrastructure issues such as the use of vulnerable server versions, hidden directory detection, and more.

The Verification phase continues until identified security issues are resolved and the product reaches the desired level of quality. At this point, we’re one step closer to release.