Aneesh Bhargav
April 17, 2020

Why Development and Security Teams need Holistic Learning

One of the primary causes  that hinder effective application security in organisations, is the rift between development (engineering) and security teams.

The lack of a common understanding of Application Security

The problem reminds us of the old parable of the Blind Men and the Elephant. Those touching the mid-section of an elephant might have an idea of the size of the elephant. Those touching the front of the elephant understand how the trunk functions. But neither group can see the actual elephant, and both groups have their own idea of what the elephant looks like as a whole

Effective application security programs in organisations is the result of both these teams working together, and communicating, based on their subjective understanding of the problem. But getting to this stage isn’t easy. Product engineering teams (especially those with more than 50 in number) often squabble over WHAT a real issue is, and HOW to remediate it. Similarly, development and security engineers have a very vague understanding of the others’ area of work. For example, a developer “generally” understands security vulnerabilities, but completely excels in the nook and corners of the platform’s workflow. Similarly, while a security engineer understands granularity of security threats, there are usually gaps in the relevance and applicability in context to the platform in scope.

When security teams help remedy situations, developers shrug and say they didn’t cause the issues. Security teams point out that there wouldn't be security flaws or entry points if developers had built the system well. This blame-game as you might imagine, doesn’t make anything easier. Some of the other common rifts between these teams include:

  1. Prioritisation: A constant back and forth on severity of a said vulnerability due to a fundamental difference in impact assertions. For example, a vulnerability that a security engineer considers to be “Critical” might not be considered so by development.
  2. Coverage: Falling short in test coverage; usually gaps in edge cases emerging from a lack of understanding deeper product workflows. This is typical in cases where the application in scope has many security-oriented-functional flaws.
  3. Remediation: Suggestions from development that are effective in isolation, but contextually not feasible to implement by the development teams.

Herein lies the problem: BOTH teams need a holistic starting point. Having a comprehensive idea of application development with baseline security in mind, and in designing security controls  that are feasible to implement.. Teams will also be able to differentiate between what looks like a problem but isn't and vice-versa .

This is where we thought we could lend some assistance.

A normalised approach to the essentials of Application Security

With our application security training , both development and security teams have a normalised understanding of what and how the elephant in the room (earlier pun, intended) looks like, and the workings of a vulnerability through a practical hands-on approach. Not only does this allow teams to gain skills that help each other, they also provide them access to state-of-the-art cloud labs where they can test their theories at their own pace, and in whatever way they'd like to. The courses have been designed and modularised to ensure that there is an optimum level of technology-agnostic fundamentals of attacking and defending web applications and APIs.

These hands-on labs don't need heavy duty machines (in fact they are browser-compatible) and are loaded up with exercises that directly complement the course topics and provide the much needed practical experience of understanding the intricacies of (in) secure code. What’s more? The labs are accessible for a period even beyond the duration of the program.

So, are you ready to get your teams together? Our live, remote training calendar for our flagship Application Security Essentials program is available here