Posted by Robert Voitle on Thursday, August 31st, 2017
In software development shops across the world there is a strong emphasis on quality over security. But, these two key practices in the development process are not mutually exclusive. They are, in fact, two sides of the same coin joined together by their similar processes, artifacts, and goals. These include testing the software for defects, generating reports digestible by both management and developers (regarding which defects require remediation), and improving the operation of the application. Despite these similarities, the two practices remain sheltered from one another and there are three main reasons why:
Examining each reason in greater detail reveals why it’s essential that the current division between security and quality be broken down. The two practices should embrace the ideology that they are two elements within the same conversation.
Historically, security hasn’t been a software concern. Rather, it was a network concern. This distinction caused the creation of two unique practices: quality and security. Quality concerned itself with software defects. When the application would crash due to too many database connections open, it was quality’s job to detect that defect before release and send the software back to development for remediation. Meanwhile, security established firewalls and intrusion detection systems to protect the juicy innards of networks.
Then the internet came about. For a while nothing really changed. We were more connected. We could do more with our software.
Quality and security kept going about their business. That is, until someone noticed that new web applications were like little portals past the firewalls protecting our networks. Thus, software security was born and began looking for a place in the software development life cycle (SDLC) it could call its own.
Software security wasn’t discovered by quality control personnel. It was tested and verified by white hat hackers who, until recently, didn’t have a place in the corporate world. They weren’t part of the security team, nor were they part of the quality team. This separation of responsibilities is the primary reason why today software security still often stands apart from quality. Which leads us directly into the second reason quality and security aren’t often thought of in coordination.
Software security experts have spent years telling the world security issues need to be fixed early in the SDLC. They profess that catching a vulnerability during coding is significantly less costly than catching it after release or even during quality control checks. While this claim is factual, it isn’t always practical. Several problems can arise when trying to push security all the way back to the coding phase of the SDLC.
First, the emphasis for developers has always been to innovate and include as many features in new software as possible while adhering to a strict timetable. When you suddenly introduce security testing into their process it is often perceived as coming at the sacrifice of either features or deadlines. For every minute developers spend performing security tests, they lose a minute toward meeting their deadlines.
Second, developers can be proud individuals. And they should be! They’re proud of the work they produce and the beautiful complexity of the code they’ve written. Due to this, it can be a challenge for them to admit that their code—their baby—has any significant flaws. This inherent bias toward favoring their own code and affirming their own assumptions about the use and function of that code can create a conflict of interest that should not be ignored.
The solution to these problems has traditionally been seen as an independent security team whose function is very similar to that of quality control:
But if their function and purpose is so similar to quality control, why aren’t the two teams simply paired together as a single unit? Aside from those already given, there’s a third reason quality and security are often kept separate.
Since there is often a separation between quality and security, and because of the way security experts talk about the integration of security into the SDLC, quality personnel are rarely asked to identify or respond to security-related issues. The fact that they aren’t asked to consider security in their quality checks reinforces the idea that security and quality are two separate practices. This problem extends upward from quality into management and executive thinking. Decision makers see this knowledge gap. Rather than fill it they accept it, allowing the two practices to remain separate.
This does a great disservice to both groups. It reinforces the idea that security and quality are distinct practices with no common goals or practices. This simply isn’t true. It also encourages quality personnel to remain in the dark regarding security issues. The mentality becomes, “We don’t need to know about security. There’s a whole other team that handles that.” The same can also be said about security personnel and their attitudes toward quality.
It is at this point that the argument for combining security with quality becomes even more practical. Why establish an entirely new team to perform security testing when it’s possible to augment and train an existing quality team? This argument makes even more sense after examining the direction software development is going.
The software development life cycle has changed significantly in the past 10 years. Development teams have predominately abandoned classic life cycles such as waterfall. Instead, they’re embracing more rapid development life cycles. These new agile life cycles force both quality and security teams to reconsider their methods. This offers an opportunity to unite these two sympathetic practices into a single, unified team with the overall goal of making the software more stable and secure.
By combining efforts, security and quality can reduce the overall cost of performing assurance testing. This coordination can also improve the knowledge base of its practitioners. And, reshape the conversation about security in the development environment. When this union is combined with tenants of agile development, such as continuous integration and development, dynamic analysis, and improved quality management software, it creates a force for change and improvement to the overall software development process that benefits everyone involved.
To achieve this goal, quality team members must embrace security best practices and become more willing to include security related issues as part of their test plans. Likewise, security must be willing to abandon its dream that one day all software vulnerabilities will be caught and remediated before the code is ever compiled for the first time. And finally, the two practices must be seen as equally necessary with complimentary organizational capabilities within the development process from the top of the corporate ladder to each newly hired developer or QA engineer.
Quality and security are two sides of the same coin. They should no longer be viewed as separate practices, but as a single unified practice with the overall goal of improving the performance and security of software. There are several issues pushing the two practices apart from knowledge gaps to historic separation. The rapid adoption of new agile development methods has created an excellent opportunity for QA and application security teams to improve their alignment and collaboration. It’s also helping to steer software development toward a new, more stable and secure future.
Get the latest AppSec news and trends sent directly to you.