Software vendors will increasingly be on the hook to provide evidence that their code is secure. With mounting pressure from customers, regulations and even competitors, vendors are finding they need to make application security a priority.

But as software vendors start their application security journey, the first roadblock they often hit is the development organization. And that can be a showstopper. Without buy-in from the development team, your AppSec program is going nowhere fast. We’ve pulled together some common developer objections we hear regarding application security, and some tips on responding to the objections, or avoiding them altogether.

Objection 1: You don’t understand how we work/what we’re up against

 “Speak my language and integrate your security program into my existing workflow. If I’m going to take on the responsibility of making my application “secure” to help you, you’re going to have to bring something to the table that helps me. Don’t be a drag against my schedule and backload all the risk until the end. Raise problems early and help me do my job, and I’ll help you do yours.” – Veracode Director of Engineering Jeff Cratty

Get past this objection by taking some time, early in the AppSec planning phase, to walk in your developers’ shoes. Start by sitting with leaders on the development team and mapping out your company’s development frameworks. You’ll increase the chances of both getting buy-in, and of the program’s success, if you understand your developers’ processes, priorities and challenges. Once you understand the process, work with it. A plan that developers had a hand in crafting, and that works with, rather than against, their existing processes has a much higher chance of buy-in and success.

Finally, one of the best ways to truly understand where developers are coming from is to find a developer interested in security and make him/her your application security champion. This role will build a bridge between security and development – helping developers understand the importance of security, and helping security understand how their priorities line up with dev’s.

Objection 2: Security testing won’t fit into/is too slow for my agile process/sprint or, increasingly, won’t fit/too slow for DevOps

 “The Agile methodology will enable those leading development teams to have first-hand insight into security of the code being built, and be able to reconcile these assessments with timelines around product testing and release dates. This ability begins to reduce the gap between the goals of the security side of an organization and those of the development teams. Neither innovation nor security is sacrificed.” – Veracode Director of Platform Engineering Pete Chestna

Speed rules in development these days. And, traditionally, speed and security did not go hand in hand. The word “security” became synonymous with “stop,” “slow,” “roadblock,” or “lack of progress” for many development teams. However, this objection is not in line with how many AppSec solutions work today. Here are a few tips for responding to this objection:

Pick your words wisely:

A speaker at the most recent RSA conference suggested that, to get DevOps to consider security a priority, you should talk about it as a quality issue, rather than a vulnerability issue. In this way, security shifts from an annoying extra task to simply part of the definition of done, and, ideally, this framing will make developers less likely to balk at security protocols in the SDLC.

Further, security teams should make sure that developers understand that embedding security into the coding phase will actually speed the process of creating quality, flaw-free code. When you catch security flaws in the coding stage, they are cheaper and easier to fix. In addition, developers can see where the flaws are occurring and avoid the same mistakes in future code – allowing them to move even faster.

Pick your technology wisely:

Technology choice will play a big role in avoiding developer pushback, especially with Agile processes. For instance, AppSec solutions built for paradigms such as Agile and DevOps have to be able to scan code quickly, without significant configuration. Automated, cloud-based services are ideal in this environment.

In addition, a solution that integrates with developers’ existing processes and tools is key to coding securely with Agile. By adding APIs to the development tools already being used by the programming teams (Jira, Jenkins), security can become so integrated into the development processes that it is seamless.

Objection 3. Don’t know how to/have training on secure coding … and, don’t have time for training

Training on secure coding is definitely a critical component of application security. In fact, lack of developer knowledge of security is often cited as a barrier to producing more secure code. Our research found that organizations using remediation coaching services improve code security by a factor of 2.5x compared to those that choose to do it on their own (State of Software Security, Volume 6). And not only does training make your code better, but it also makes your developers better. Security concerns aren’t going away anytime soon, and developers with security know-how are only going to become more valuable.

To overcome the “no time for training” objective, consider eLearning. With eLearning, the training can be more flexible and accommodate time differences, deadlines and even differing roles and priorities. It can even get as granular as specific flaws – allowing developers to get the particular information they need when they need it. Just as you need to work to integrate security assessments into the SDLC as seamlessly as possible in order to gain developer buy-in, so too with training. In the end, everyone learns differently, so your best bet is a combination of in-house explanations or demonstrations, third-party experts to help with application threat modeling, eLearning or various commercial courses.

Finally, consider that you might need to become a part of the development process: When developers are new to security, you may need to jump in and help define security tasks and processes. This could involve writing security “stories,” and helping develop task cards to describe the security work to be done.

Find out more about working with developers to secure the software you sell in our new guide Striking a Balance: How Software Producers Can Boost Security Without Comprising Development Speed.

About Suzanne Ciccone

Suzanne is a marketing writer at Veracode. In this role, she’s part of a team working to shed light on AppSec through compelling and clear content. Suzanne has been a professional editor and writer for many years, for companies including Forrester Research, Cengage Learning and EBSCO Information Services.

Comments (1)

Mark Hausammann | May 9, 2016 1:42 pm

The SDLC could also be modified to include mandatory Security Testing before production. Somehow, the individual development groups need an understanding that another developer could code improperly opening the exposures in other developers’ applications. This is another way of selling security to the individual developers by ensuring that all new code will be subject to a security review to limit exposure to all production code since a security weakness within the production portfolio can be exploited in other applications.

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.