Rarely Discussed Real Life Application Security Decisions

The cyber security industry often frames application security as a singular entity with a similar model, approach, and employee requirements across the full range of organizations. 

If only that were correct.

A key difference among application security models and approaches isn't the toolsets involved or the level of automation of those tools in the build pipeline, it's where the analysis of defects found by those tools takes place. The differences in each approach or model drive requirements for skillsets, resources, and scope with potential impacts outside of the cyber security team.  

Your organization will have some fundamental decisions to make. 

In some models, the development team performs the analysis of app security defects. The app security engineers tend to be tool focused. The output is simply passed to the development team. Application security engineers only need to have some familiarity with OWASP and other app security vulnerabilities as the analysis, prioritization, and severity of the defects is performed by the dev team.  The downside of this model is that (1) the dev team will need to be resourced to handle this analysis and (2) in many organizations, it’s the devs that have to process through the inevitable false positives and duplicates. 

In other models, an outsourced vendor performs the analysis of app security defects. They may also run the tools. From interviews, I’ve learned that some with the title, “application security engineer” actually represent the organization to manage the app security vendors. The downside here is (1) the potential cost of buy vs. build and (2) the organization may not be building longer term expertise, knowledge, and historical data around application security. 

In still other models, the application engineers perform the analysis of the defects. The upside of this model is that the app security team provides tangible value identifying false positives, removing duplicates, and often validating the automated classifications provided by the scanning tools. The downside is the depth of specific application development knowledge and experience required of the app security engineers.  In my team’s case, we focus on hiring previous developers and automated test engineers as we’ve rarely interviewed security engineers that have the ability to perform such tasks at a high level. 

So, when you are doing comparison between programs or listening to other senior cyber describe their application security program, there may be variances that don’t necessarily fit your organization’s goals, budget, or ability to resource. Some organizations can do great with a high percentage of app security interns because the work and the costs of detailed defect review are likely being borne elsewhere.  

You’ll also need to dig in during interviews to determine the fit of candidates. The title of “Application Security Engineer” can mean many things from “I throw the switch on tools” to “I manage a vendor” to “I look at defects and analyze them”. 

One size does not fit all in application security. As they say, “all models are wrong but some are useful.”

Hopefully, you find these useful. 

Follow me on Twitter for discussion and the latest blog updates: @Opinionatedsec1. Or, start your own discussion using #crazygoodcyberteams on twitter or Linkedin and I'll read it.

SEE ALSO

Conference Capture The Flag (CTF) for CISOs? 

Cattle Versus Pets In Securing DevOps Pipelines 

An Application Security Program Is More Than Scanning