As a developer, have you ever been told your baby is ugly?
You sweated blood and tears building that groundbreaking application or creating the competition-breaking feature only to be told you can't release it?
The traditional (and still prevalent) approach to Application Security (AppSec) is to create a team of security specialists and to sanction them with gatekeeping. In these situations, security testing is commonly implemented as a prerelease gating function or regular formal code review and analysis.
In either circumstance, security teams simply doing their job have the “pleasure” of telling development teams that their code has security flaws.
’Developers, your baby is ugly!’
Regardless of how well- and sensitively delivered, this process builds up significant resistance and even resentment among development teams.
Needless to say, this is reminiscent of traditional testing practices where quality assurance (QA) had that power to kill the flow of product with similar messaging.
Agile, and later DevOps, made huge strides in the area of testing by integrating testing into the development life cycle and making it a collaborative and inclusive practice.
Unfortunately, moves to “shift left” AppSec testing have, largely, been unsuccessful. In part, this is because of the challenges of more traditional tooling, but there is also a problem with the ongoing AppSec team.
Static Application Security Testing (SAST) tools implementation becomes a blocker to development teams, with high levels of false positives adding unnecessary and unplanned workload. It is usually a slow process detracting from Continuous Integration/Continuous Deployment (CI/CD) development speeds. Dynamic Application Security Testing (DAST) and penetration testing carry forward the problems of traditional approaches to AppSec, as they are “after the fact” implementations even if they are automated.
In these scenarios, development teams are, in fact, looking at the practices and commonly telling security teams that their baby is ugly. This is how the problem is perpetuated.
Additionally, security teams are still disconnected from development teams and have an “oversight” and “authoritarian” role in organizations. They are often seen as a problem and not as part of the solution.
The Agile and DevOps “manifestos” never excluded AppSec. In DevOps, there is certainly more than a nod in that direction. Neither, however, have been particularly forthcoming on the matter.
So, how do we get rid of the “Ugly Baby Syndrome” and grow up?
For me, there are two solutions — one technical, one people-related.
On the people-related side, while AppSec remains a highly complex realm requiring some specialist expertise, organizations should opt to enable development teams through contextual learning. This concept takes the opportunity of a found vulnerability to deliver situational context-based training to individuals on said vulnerability type. Individuals learn most effectively when it is delivered as part of daily work and, by fixing the vulnerability before peer review, they get social kudos for clean code. Working within the team, knowledge sharing by empowered individuals adds a distributed and impactful element not found in traditional security courses. This helps to embed security as part of the development life cycle and raises everyone's awareness and engagement.
On the technical side, tooling must be appropriate for today's fast-moving world of application development. Tools such as Interactive Application Security Testing (IAST) that can embed themselves easily into the development life cycle while adding value with minimal impact are becoming essential.
As opposed to SAST (which has to guess from the source code) or DAST and pen testing — which have to guess from the outside — IAST works within the application. As such, it has intimate and detailed knowledge of the application and can make educated and informed decisions about vulnerabilities.
Multipoint implementation of IAST is a must, in my opinion. It is essential in automated testing processing and QA where the application is exercised. But it is also essential in developer environments, where it can assess recently written code as part of the pull request and review process.
As usual, we come back to people, process, product ...
- People — educate, enable and enthuse developer teams to drive engagement with the problem,
- Process — implement tooling and engage teams so that security becomes part of the solution, and
- Product — find tooling (such as Contrast Assess) that maximizes gains and minimizes pain.
Click here to learn more about Contrast Assess.
