Security is Everybody's Job - Part 2 - What is application security?
Tags: devops, beginners, devsecops, appsec
Published: 2020-04-17 02:13:46

---
title: Security is Everybody's Job - Part 2 - What is application security?
published: true
description: This is the second in a many-part blog series on the topic of DevSecOps.
series: Security is Everybody's Job
tags: devops, beginners, devsecops, appsec
---


###Definition: Application Security is every action you take towards ensuring the software that you (or someone else) create is secure.

This can mean a formal secure code review, hiring someone to come in and perform a penetration test, or updating your framework because you heard it has a serious security flaw. It doesn’t need to be extremely formal, it just needs to have the goal of ensuring your systems are more secure.

Now that we know AppSec is, why is it *important*?

For starters, insecure software is (unfortunately), the #1 cause of data breaches (according to the [Verizon Breach Reports](https://enterprise.verizon.com/resources/reports/dbir/), 2016, 2017, 2018 and 2019). This is not a list that anyone wants to be #1 on. According to the reports, insecure software causes 30–40% of breaches, year after year, yet 30–40% of the security budget is certainly not being spent on AppSec. This is one part of the problem.

![The graph above is from the Verizon Breach Report 2017. Hats off to Verizon for creating and freely sharing such a helpful report, year after year.](https://dev-to-uploads.s3.amazonaws.com/i/68ik6oygl2c46j4in43b.png)
#####The graph above is from the [Verizon Breach Report](https://enterprise.verizon.com/resources/reports/dbir/) 2017. Hats off to Verizon for creating and freely sharing such a helpful report, year after year.

If the problem is that insecure software causes breaches, and one of the causes is that security budgets don’t appear to prioritize software, what are some of the other root causes of this issue?

For starters, universities, colleges and programming bootcamps are not teaching the students how to ensuring that they are creating secure software. Imagine electricians when to trade school, but they didn’t teach them safety? They twist two cables together and then just push them into the wall, unaware that they need two more layers of safety (electrical tape, and then a marrett). This is what we are doing with our software developers, we teach them from their very first lesson how to make insecure code.

###Hello (insecure) World

`Lesson #1 for every bootcamp or programming course: Hello World.
Step 1) Output “Hello World” to screen
Step 2) Output “What is your name?” to screen
Step 3) Read the user’s input into a variable **(note: we skip teaching input validation)**
Step 4) Output the user’s input to the screen with a hello message **(note: we skip output encoding)**`

The above lesson teaches new programmers the best possible recipe for including reflected Cross Site Scripting (XSS) in their application. As far as I know there is not a follow up lesson usually on how ensure the code is secure.

“Hello World” is the most-taught lesson for starting a new programming language, I’m sure you’ve seen it everywhere. More like “Hello Insecure World”.

Although there has been some headway in universities and colleges recently, most of them barely scratch the surface in regards to application security.

Another issue that contributes to this problem is that security training for developers is costly. While this is true for all types of professional training, security training is significantly more expensive then other forms of technical training. A single course at the SANS institute (a well-respected training establishment that specializes in all things cyber), could cost an attendee as much as $5000-$6000, for one week of training. There are other less-pricy options, such as taking a course when attending a conference, which usually range from $2000-$5000, however, those are of varying quality, and there is no standardized curriculum, making them a bit of a gamble. I’ve taken several trainings when attending various conferences over the years, and I’d say about 1/2 were good.

There are much cheaper alternatives to the options above, and they are of very varying quality levels. I’ve seen both good free courses and some where I wish I could have my time back they were so bad. Most of them do not provide a curriculum to follow either, meaning it is often unclear to the student which other courses they should take in order to get the specific job they want. It is very easy to waste quite a bit of time; I know, that is how I started my AppSec career… Although I was quite lucky to have a professional mentor guiding me, which made it a lot easier. But I digress.

![See how lonely she looks? She’s the ENTIRE security team! #WOCTechChat](https://dev-to-uploads.s3.amazonaws.com/i/9ziwlk82o23li1f14y0n.png)
#####See how lonely she looks? She’s the ENTIRE security team! #WOCTechChat

Another cause of insecure software is that the security team is usually grossly outnumbered. According to several sources there is usually 100 software developers for every 10 operations employees for every single (1) security professional.

Let me repeat that. There are 100/10/1, Dev/Ops/Sec. With numbers like that you can’t work harder, you have to work smarter. Which is where we are going with this series.

Now we know the problem and several of the causes, what can we do about it? The short answer is DevSecOps, and the long answer is ‘read the rest of the blog series’.

For now though, let’s define DevSecOps, before we dive into what DevOps is, The Three Ways, and so much more, in the next article.

###DevSecOps: performing AppSec, adjusted for a DevOps Environment. The same goals, but with different tactics and strategies to get us there. Changing the way we do things, so that we weave ourselves into the DevOps culture and processes.

—
**For this and more, check out my book, [Alice and Bob Learn Application Security](https://aliceandboblearn.com/) and my online training academy, [We Hack Purple](https://academy.wehackpurple.com)!**