Webinar: Why Cloud-Native Applications and APIs Are at Risk

Who Really Owns Application Security?

This is a follow-up blog to my blog from last week about Application Security Superheros. Yes, I know the blog was a bit cheesy, but that was the goal. I wanted to get people thinking about what modern-day application security professionals need to be with a bit of humor. Now let’s add some real-world examples to the concept.

The results are in from the latest poll

 I ran this poll on LinkedIn last week, and it further supports the statement that application security professionals need to expand their job responsibilities.  If you stay in your comfort zone, you are going to miss things

Digging into the poll results

As you can see, over 50% of respondents feel that the security of your organization’s applications has no single owner.

Why is this?

Is it because application security professionals don’t have transparency into what other groups such as enterprise architecture, DevOps, or development are doing? Or is it the perception that that’s not my responsibility? 

The old ways of running application security teams just to find vulnerabilities need to change.

What does a  complete application security professional look like?

To be a complete application security professional, you still need to understand vulnerabilities and find them with AST scanning technologies, but that is just the tip of the iceberg IMO.

Understanding what you are pointing those scanning technologies at is VERY important.  A clear understanding of your application architecture will go a long way to find high-fidelity results from your AST scanner and limit false-positive findings.

What you need to know

 To be a complete Application Security Professional, you also need to understand the following:

  1. The architecture of the applications including all dependencies and attack vectors
  2. Application SBOM (code, libraries, frameworks, open-source, etc.)
  3. How the application is released through DevOps pipelines
  4. Frequency of release through the DevOps pipeline
  5. SLA for bug fixes in the applications in question (security & quality)

More real-world examples 

Another source of evidence to further support these statements is my podcast Tattoos, Code, and Dataflows.  My guest Alan Shimel, Head of Tech Strong Group, made similar statements when asked what he would like to see change associated with application security.  Alan speaks with industry experts daily. Based on these conversations, he feels that the time is now for Application Security Professionals to be part of the entire application ecosystem and not just a vulnerability hunter.

You can hear the whole podcast conversation here Tattoos, Code, and Data Flows – Episode 1

Some really scary stories out there 

I have heard some scary stories lately about how application security teams know that there are significant architectural flaws in their applications that they pretend are not there. Still, they don’t have the time, budget, or resources to investigate them correctly, so they ignore them and leave them up to the architects to deal with.  They are already overwhelmed, and if they find more security issues, they have to fix them. So plausible deniability is the status quo.

Here is an example of a scary story I heard

An example of a scary story that comes to mind is working with an enterprise architecture team recently. The EA team was concerned about application architecture drift.  They wanted to understand how their organization’s CI/CD process could potentially release unapproved application architecture and decided to include the app sec team in the discussion.

When digging into the use case the application security team said that the issue of application architecture drift was the EA’s responsibility and chose to dig their heels in and not want to see anymore.  The reason given was they did not have time to investigate these issues as they were already overworked.

Introducing the Cyber Reliability Engineer

We can do better as application security professionals. It is time to be more than just a vulnerability hunter and become a full-stack application security engineer. 

Full Stack is a common term used for developers, so why can’t we use it for application security professionals? But in order to prevent confusion with a Full Stack Developer, we need a cooler title.

I vote for Cyber Reliability Engineer as the new updated version of an application security professional.

Did you find this blog helpful or interesting?

Click the social media button of your choice to share the blog with you friends and colleagues.

Share on linkedin
Share on twitter
Share on email
Share on facebook

See a Live Demo of the Bionic Platform