A Brief History Observed
I have been in Static Analysis Security Testing (SAST) for 15+ years.
I have worked with some of the largest organizations in the world on scanning their code for security vulnerabilities. From Waterfall to DevOps to Cloud-Native Development, I have seen many changes in how application code is developed and released.
Still, one of the consistent themes has always been finding the expert or experts on the application code for SAST scans to be complete and accurate.
This problem was not a huge deal when the application release cycle happened only a few times a year. Now some companies are releasing a few times an HOUR! The current AST scanning tools (SAST, DAST, IAST, etc.) can take hours to scan, so how does an organization keep up? One small code or configuration change can make a secure application insecure.
This considerable problem, combined with the fact that in today’s world, every company relies on technology to exist, means the time is now for a new approach to security visibility.
Shall We Play a Game?
No, not a game with this guy!
With this guy!
Every company is a technology company, and the foundation of being a technology company is code. Just ask yourself, is there something you do on a day-to-day basis, whether professional or personal, that is not tied back to code somehow?
To prove this hypothesis, let’s play the code version of Six Degrees of Kevin Bacon. If you are not familiar with the Six Degrees of Kevin Bacon, you should go Google it.
Unscientific, Scientific Research
I performed some very flawed and unscientific research. I asked many friends and family to give me an example of something they feel has nothing to do with technology and code.
As a side note, most of my friends do not understand technology. When I tell them I am in application security, I get asked to help secure their home WIFI or get a virus off their computer, so the responses were, let’s say, interesting.
I had a ton of different reactions but felt the following three answers would fit best in the Six Degrees of Code game.
Example 1 in the Six Degrees of Code Game
The lawn care company I have for my yard has nothing to do with technology or code.
The company that cuts my grass may not seem like a consumer of technology or code, but how do they schedule whose lawn to mow and when? (Scheduling software = code)
How do they order parts when their mower breaks (Online ordering tool for parts/maintenance = code)?
How do they know when to apply the correct fertilizer and when (Lawn Chemistry Analysis Software = code)?
I would argue that this is 1 degree of separation.
Example 2 in the Six Degrees of Code Game
My child’s recreation soccer team has nothing to do with technology or code.
While your child playing soccer does not directly use code, I bet you signed them up for the team/league through a town or organizational website (website = code).
How do they create the team’s practice, game, or tournament schedule (sports scheduling software = code)?
I would again argue this is 1 or 2 degrees of separation.
Example 3 in the Six Degrees of Code Game
My local farm stand has nothing to do with technology or code
Buying locally grown produce from your neighborhood farm stand supports your local farmers and provides people with a good feeling of giving their money to the little guy.
But have you ever thought of how the farm stand can have fruits, vegetables, homemade pies, etc., from so many different vendors? (Marketplace apps = code)?
What about paying for the items (credit card processing = code)?
What happens when they run out of a specific item and need to reorder (ordering software = code)?
Again only 1 or 2 degrees of separation.
Try this game out for yourself
See if you can identify one company that does not rely on technology and code to operate.
I bet you can’t.
I told you that my example was flawed as we didn’t even need to go six degrees of separation to find technology and code in unlikely places.
There are so many more examples where people don’t realize that technology and code are part of pretty much everything they do.
Ok, so What is Code?
Now let’s switch gears to talk about the definition of code.
Under the covers, the applications and software you use on a day-to-day basis are a million-piece jigsaw puzzle (sometimes much more). The combination of source code, open-source packages, APIs, web services, COTS software, configuration files, and many other components complete the application code puzzle.
Now add a proverbial match to gasoline and an aggressive DevOps release cycle. BOOM, you have a perfect storm of large, complex applications that not one person truly understands released hourly.
If that person feels they 100% understand the application at this exact moment, two new application releases happened while reading this blog.
The New Development Landscape Has Created New Concepts
Drift is not just something that happens with cars in the Fast and Furious movies!
A new buzzword associated with application architecture is Drift, but what is it? Drift is a change that happens in your application code or infrastructure and is outside of the approved architecture or configuration. It is unknown and tough to identify because you don’t know exactly what to look for.
Complete application risk visibility is imperative to ensure that your applications are secure and architected correctly.
Known Risk vs. Potential Risk
How do you get to complete application risk visibility?
How do you know if the latest code push introduced new dangerous data flows, unmanaged rogue APIs, or PII data exposed in an unanticipated way?
The only way to do this is to change the way you approach application and code risk. Instead of looking for the known risk, you need to look for the potential risk that changes expose.
Code is complicated, and I would argue impossible for one person to be able to identify all the “what if” scenarios in the previously mentioned million-piece jigsaw puzzle analogy that is today’s application code.
Class: Here is a Homework Assignment
What? Didn’t you know you would be assigned homework when you started reading this blog?
- Do you feel like you know everything about your applications and their underlying code?
- Understand every existing and potential data flow?
- Where customer PII data is coming from, and where is it going?
- Do you have a way to identify how a simple code or configuration change can cause potentially dangerous drift?
- How many people do you need to meet with to understand your applications at the granular level?
Everything is code, but I bet you don’t know everything about your code.