Security Bugs Are Fundamentally Different Than Quality Bugs

This topic has come up a few times this year in question period: arguments that quality bugs and security bugs "have equal value," that security testing and QA are "the same thing," that security testing should "just be performed by QA" and that "there’s no specific skillset" required to do security testing versus QA. This article will explain why I fundamentally disagree with all of those statements.

First, some definitions.

7 Places to Do Automated Security Tests

When working in a DevOps environment, security professionals are sometimes overwhelmed with just how fast the Dev and Ops teams are moving. We’re used to having more control, more time, and more… time!

Personally, I LOVE DevSecOps (the security team weaving security throughout the processes that Dev and Ops are doing). Due to my enthusiasm, I am often asked by clients when, how, and where to inject various types of tests and other security activities. Below is my list of options that I offer to clients for automated testing (there’s lots more security to do in DevOps — this is only automated tests). They analyze the list together and decide which places make the most sense based on their current status, and choose tools based on their current concerns.

Jobs in Information Security (InfoSec)

Almost all of the people who respond to my #CyberMentoringMonday tweets each week say that they want to “get into InfoSec” or “become a Penetration Tester;” they rarely choose any other jobs or are more specific than that. I believe the reason for this is that they are not aware of all the different areas within the field of Information Security (InfoSec for short, and “Cyber” for those outside of our industry). I can sympathize; I was in the same position when I joined. I knew three Penetration Testers and lots of Risk Analysts and I had no clue that there were several other areas that may have interested me, or that they even existed. I knew I didn’t want to be a Risk Analyst, so I thought the only other option was pentester. Now I know that is not true at all. This article will detail several other areas within the field of Information Security in hopes that newcomers to our field can find their niche more easily. It will not be exhaustive, but I’ll do my best.

Image by Henry Jiang of Oppenheimer & Co.

The above image shows 8 different potential areas within the field of Information Security according to the author Henry Jiang: Governance, Risk, Career Development, User Education, Standards, Threat Intelligence, Security Architecture, and Security Operations.

Building Security Champions

Most of us that work in cyber security are well aware that there are not enough people to fill all of the positions that we have opened. There is a severe shortage of trained and experienced people who are capable of securing the systems that we are entrusted to protect. Application security engineers, DevSecOps professionals, security architects, you name it, there's a shortage.

We will never have the staff, budget or time to do all the security work we want to do.

DevSecOps: Securing Software in a DevOps World

This article is featured in the new DZone Guide to DevOps: Implementing Cultural Change. Get your free copy for insightful articles, industry stats, and more!

The practice of improving and ensuring the security of software is generally referred to as (the field of) application security, or "AppSec" for short. In a traditional waterfall system development lifecycle (SDLC), AppSec was often an afterthought, with someone (a penetration tester) being hired to come in just before release to perform last-minute security testing, or not at all. Slowly, many development shops started adding more AppSec activities such as secure code reviews, providing secure coding guidance or standards, giving developers security tools, and introducing many other great ideas that improved the overall security of the end product. Some companies even went so far as to create their own team dedicated to application security. However, there is currently no agreed-upon standardization on what defines a complete AppSec program, nor a definition of when someone can say that "the job is done" or that they have done "enough" in regard to the security of software. The line seems to vary greatly from team to team, business to government, and country to country, which makes it a difficult thing to measure.