Bionic Uncensored Ep #1

The History of Application Security

Welcome to our first episode

Welcome to the first episode of Bionic Uncensored! My name is Matt Rose, Chief Architect at Bionic. The topic today is the history of application security tools.

People have been asking me, how did we get to this point in terms of the tooling associated with application security? What are the best tools that we can use for a certain use case, a certain problem we’re facing? How do I use tooling against a running application, against source code, against APIs, against third-party libraries, so on and so forth?

We will start with a quote from one of my favorite movies: Airplane Two.

  • [Steve McCroskey]: I wanna know absolutely everything that’s happened up till now.
  • [Jacobs]: Well, let’s see, first the Earth cooled, and then the dinosaurs came, but they got too big and fat, so they all died and they turned into oil.

There are a lot of parallels here, but we’re not going to go all the way back to the dinosaurs. We’re gonna start right around 2000 in talking about the history of application security tooling.

We’re going to talk about some core software-based pieces of technology. There’s a ton more from a hardware side, from a network side, but we’re gonna focus on the application security tooling, or the scanning technologies you may be familiar with.

Tools

Here are the tools that we are going to discuss today:

  • SAST (Static Application Security Testing): Scanning of the source code.
  • DAST (Dynamic Application Security Testing): Testing a running application from the outside in.
  • IAST (Interactive Application Security Testing):
  • RASP (Runtime Application Self Protection): Modernization of hardware-based pieces of the application, web application firewall (WAF)
  • Software Composition Analysis (SCA): Scanning open-source packages for vulnerabilities

2000

The year 2000 was around when DAST really came out, Dynamic Application Security Testing. This really centered around the concept of scanning a running application. There were a lot of vendors and it was hot technology. It still exists today, and a lot of people still use DAST, or pen-testing as it’s often called, as part of their application security program.

2002

The year 2002 is where the first SCA vendor came to market. It wasn’t called Software Composition Analysis at that point. Instead, it was called open-source analysis or open-source binary analysis, but really the first commercial product for scanning open-source packages really came to market in 2002.

Also in 2002, the first SAST vendors came to the market. There were a couple of different SAST vendors that came to the market, but the first ones were looking at application security code. At this point in time, I was helping organizations understand that the firewall or the IPS or the IDS wasn’t the end-all-be-all and that you had to look at the source code.

2006

The year 2006 is when the industry analysts really started to focus on the application security space and application security scanning technologies. Gartner and other vendors started to put out their reports (ie: Magic Quadrant). 

At this point, they were segmented into a specific type of technology:

  • There was a magic quadrant for static analysis
  • There was a magic quadrant for dynamic analysis

They were very siloed in terms of their technology. Since then, they have morphed and combined all the technologies into one umbrella, which is Application Security Testing or the AST Magic Quadrant.

As time moved on, we really tried to focus on different aspects, so more technologies came out to perform application security testing in different ways.

2013

In the year 2013, RASP started to gain some momentum. At this point, there was some talk about RASP and WAF at the code level or the binary insertion level for many years, but this is where the commercial vendors that focus on it really came out.

2014

In 2014, IAST came out and became a complementary tool to RASP solutions because it’s based on the insertion into a production environment or testing environment based on the needs of that running application.

2015

In 2015, more SCA tools came to the market and this is where the flood gates opened for Software Composition Analysis as being the most important aspect of application security. I don’t agree with that completely because I think you need to be comprehensive and look at all these technologies as they all find different things. 

  • You find different things at runtime
  • You find different things in uncompleted code
  • You find different things in third-party libraries or APIs

You need to be comprehensive in terms of using these technologies at different phases.

2021

This is where Bionic came to market and offered an application security solution that’s complementary in a lot of ways, it can help with a lot of the technologies that we’re talking about here, but provide a much broader picture of how things interrelate:

  • What does the application architecture map look like? 
  • How is drift handled?
  • How does a change in my application change the approved architecture or the risk kind of landscape for my application security program as a whole?

Check out how Bionic looks at it here:

Why did the evolution of application security happen?

What are the reasons that we had static analysis after dynamic analysis and interactive application security, runtime applications, self-protection, and Software Composition Analysis?

It all complements the way that software is being developed. Software used to be very structured, it used to be very linear. People released every quarter and now people are releasing software hundreds of times a day.

The DevOps process is an infinity loop, it’s a bow tie, it’s continual. I always like to say, where is left? Where’s the beginning? Where’s the end?

Application Security, like the DevOps process, should be continual. It’s something that needs to happen at every one of the DevOps stages.

See for yourself

Visualize every architecture drift, security risk, and compliance violation that each code change introduces, in real-time.