My Journey into a QA Security Mindset: Introduction

How it all started

I remember that it started with:

“We want to have centralized ownership in our QA group to lead and specialized in the security niche”. After all, software engineers in Dev and test need to be security minded in their profession.

I responded “Sounds very interesting. But you know that I don’t have experience in security testing”

With more than 10 years of experience as a Manual and Automation quality engineer, I felt embarrassed, how come I never performed Security tests?

I left a full area, an important one, uncovered during those years.

I came to learn that testing for security issues is a mindset. You won’t believe how these vulnerabilities have been hiding under your nose all these years!

“We already have a security team”

“But we have a dedicated security team, it’s their job…., they will follow all the principles…” you might have heard or thought this once. Well, folks, it’s a mistake to think this way.

The value that software developers who specialize in quality and testing can bring to security domain is huge. They have a deep knowledge of the system, they live and breath quality. They are obsessed with their system and see the big picture. Their position in the product life cycle is crucial. They know what has changed, what needs to be tested and they challenge and ask about the pain areas and blind spots.

One of the big challenges of the Security team is to handle many groups in the company and to keep up with fast-paced environments with multiple code changes. This is one of the primary reasons I see it as an opportunity to involve security tests within the quality and testing phase. The involvement of quality engineers with security domains can help a lot in terms of security at scale.

My first step was to change the mindset. Share, learn, teach and lead by example. Starting with small testing and quality teams, understand the process they take in their work and how to incorporate security tests into their process.

I want you to join my journey

Part of my journey has been to create a solution as a service that will be able to be consumed easily by different teams on a microservices architecture. I have started with basic security vulnerabilities on our services and APIs that we expose to our customers in our platform. Look out for my next blog post where we’ll dive into how I went about doing this.

By writing this post (and more to come) I want to encourage quality engineers to start thinking about security tests and implementing them as soon as they can.

I also want to create a community for quality engineers to talk about security testing, share ideas, knowledge, and day to day dilemmas.

In my upcoming posts I plan on writing about:

PART II: My Journey into a QA Security Mindset: Engage your solution with multiple R&D teams

PART III: My Journey into a QA Security Mindset: IDOR vulnerability

PART IV: My Journey into a QA Security Mindset: SSRF vulnerability

PART V: My Journey into a QA Security Mindset: Information disclosure vulnerability

.

.

.

PART X: To be decided