since 1999

 

4 minutes estimated reading time.

Snowfroc 2020 - Application Security and Development

Chris Davis

I recently attended the Snowfroc conference that took place in Denver early this month. There were a number of talks about creating secure software in the context of a security team working with a development team from the outside, including one by our founder, Frank Rietta. I’ll be doing my best to condense the ideas from many of these talks into a single source. My sources are the following talks: Patch Production Now by Frank Rietta, Why Appsec is Hard for Devs by Scott Gerlach, and Climbing AppSec Mountains by Adam Schaal.

There are a few assumptions about the way an organization looks that these talks made, and as such, this post will also be assuming separate security and development teams. For smaller companies and agencies like Rietta, some of these issues such as siloed teams and inflexible developers are a little easier to mitigate. However, even if you are a solo developer, or on a smaller team, it’s critical to be aware of security issues. When it comes to security, being ignorant of the challenges is a major vulnerability in and of itself.

As a newer developer, my primary focus when learning new technology has been through implementation and practical experience, with a lot of focus on how to build things and how to build them quickly. As Scott mentioned in his talk, it is very easy for developers to think in terms of efficiency, performance and ease of use. These are all metrics that are easy to grasp, benchmark and improve upon, where security can be more nebulous and harder to define as an acceptance requirement. The result of this is that it’s easy to get into the mindset security being something that’s nice to have, but it’s a hurdle to overcome rather then being valuable on it’s own. This is especially true in cases with separated security and development teams, where there can be us versus them mentalities that are built into being different entities.

Many talks were focused on how to successfully endear a security team to the rest of the company, and use that goodwill to avoid getting security issues put on a backlog and taken seriously. It is absolutely critical for both developers and security professionals in an organization to see each other as a resource. Frank’s talk was centered around the idea that security vulnerabilities are not patched until code is actually changed on production. In a situation where there are separate QA, development, operations and security teams, getting priorities aligned is crucial due to the time-sensitive nature of security vulnerabilities. The ultimate takeaway of Frank’s talk is that companies should strive to reduce bottlenecks in the deployment process, and get vulnerabilities patched more quickly, which he explains in more detail here.

One of the ways this can be done is by shifting security needs to be done earlier during the development cycle, or “shifting left”. Traditionally, security testing exists after code is written, and on some teams, after it is already deployed. By shifting security to be included as a functional requirement, and including abuser as well as user stories, there can be a change in the way security is perceived by developers. The push to shift security left allows for software to be developed more quickly and securely, since there can be greater cohesion and inclusion of the security team as part the planning stages of the development process.

In an ideal team, developers will also be security-conscious and inherently understand the issues that come with having an insecure application, because ultimately no developer wants to ship vulnerable or bad code. However, security and development are very different education tracks for most people in the tech world. However, since we live in a world where not everyone can specialize in everything, the practical steps we can take are to more tightly integrate security and development, get security teams involved as early in the development cycle as possible, train developers enough to be able to make informed risk decisions when it comes to security, and reduce any bottlenecks stopping deployment of patches and vulnerability fixes.