Rushing Labs

My Time in AppSec So Far

What is AppSec?§

Application Security

Ok, but what is it? What does that mean exactly?

Answer here...

Isn't that DevOps? ...or DevSecOps?§

DevOps with security. That's Dev_Sec_Ops!

Well, wait...isn't it the software engineers doing the securing? What's this DevOps talk?

Answer here...

So, what's left?§

Once the security defenses are put in place, we aren't done. We still have quite a bit of securing to do. This is where team structure, organization, reporting, audits, communication, proactive vs. reactive strategies, and all kinds of things are left to gel together.

In perfect harmony, right? No.

What's this extra stuff?§

Let's backup...we need to know "where does AppSec fit into the business?" In essence, why are we here? To help secure the business' operations, right? Alright, let's take a look at that.

In an ideal world, a business would know on Day 1:

  • (a) do they need developers? How many?
  • (b) scope of the project—or was it projects?
  • (c) monolithic or service-orientied architectures?
  • (d) a clearly defined deployment strategy, and DevOps team needs
  • (e) well-integrated SSO and identity management
  • (f) ...of course a standardized logging solution simply plugs-in where needed
  • (g) well-reasoned cloud vs. on-premise decisions have been made
  • (h) dynamic resource inventories are deployed and accessible for necessary personnel
  • (i) Oh yeah...and we definitely take security seriously, and AppSec was involved from Day 1

But they don't. AppSec often isn't even hired until well into a software team/organization's (much less the company's) operational lifespan. Not only is the above list a simplification of items for AppSec to be aware of, but there is almost always a history to know and relationships to build around each one.

Teams & Responsibilities§

The list above is admittedly a mix of responsibilities. I wrote it that way on purpose, though. In the middle of all that, it's safe to assume we have a few teams: (1) Software Development, (2) Infosec/Security, (3) Operations/DevOps/SREs. Then depending on core business functions (what industry does the business function in?) we may need to interact with other teams as necessary: Legal, Finance, various Project Managers, IT Advisory Boards, etc.


This is where we start uncovering how securing an application can quickly become a complex and time-intensive endeavour.

Discuss how securing these pieces gets complex. How relationships, history affect architecture decisions, etc. For instance: who does an "app security report" go to? Who verifies vulnerabilities actually exist? Does the software & security organization possess the tools and means to behave proactively towards threats?

Would I do it again?§

I don't know.

I started playing with technology because I liked to build things. I became interested in infosec because there are interesting problems to solve. So, I started as a developer because it was my avenue into the broader tech industry. However, I quickly became bored with the corporate software engineering I was doing—everything seemed to be one more way to abstract a web application on top of a database. I saw AppSec as having vastly more dimensions and areas for improvement than the development I was doing.

Unfortunately, AppSec has begun to feel similar. Yes, the organizational complexities exist. But we never seem to have time for solving those interesting infosec problems. The challenge now is reading reports and enabling others with the data. It's deciding how to coerce a Lead Developer, with positive reinforcement, to make changes for their team that impact the larger organizational security posture. Why does that Lead need to be coerced?

Also...emails, meetings. Documentation, deciding which scan tool arrives nearest 80% feature satisfaction for the company's needs. Reports. Meeting with vendors. Then more email.

Where did my code go? Where did providing that secure web framework go? Developing that drop-in JWT plugin, so authorization and authentication can become a little more checkbox and a little less open-ended question. Or designing that standardized microservice architecture with templated services, standardized structured logging, and dynamic developers can start being ahead on housekeeping items? Wouldn't a data-driven SDLC and CI/CD pipeline be a benefit?

I want to build stuff. Cool stuff. Stuff that solves problems. Stuff that I can walk away from and say, "Yeah, I'm proud of that." I'm happy the business is a little more secure. But I'm not sure I care.

Not sure how the ending should read:

  • I'm happy the business is a little more secure...but I'm not sure I care.
  • I'm happy the business is a little more secure...but that's not why I'm here.
  • I'm happy the business is a little more secure...but I'm not happy.
  • I'm happy the business is a little more secure...but I was hoping for more.