SBN

AppSec Training – Necessary, but not sufficient

It’s no secret that the earlier you discover security bugs in the software development life cycle (SDLC), the more time, money, and resources you will save. While making use of “reactive” security testing tools such as SAST and IAST is necessary to prevent vulnerabilities from entering production, a proactive approach that eliminates the introduction of vulnerabilities in the first place must also be put into practice.

Normally to achieve this, organizations put their developers through secure code training once a year, or at best, once a quarter. The hope is that from then-onwards, developers will be able to get on the same page as application security (AppSec) teams. While this approach “checks the training box”, it doesn’t truly achieve the secure software you are after. Most developers will forget what was in the training before they’ll ever actually need it in their day-to-day work.

To really get developers to think and act with a secure mindset all year-round, and not just during sporadic training periods, organizations need to cultivate a software security culture that puts AppSec awareness in the face of the developers, at the front-and-center, constantly tapping on their shoulder. So how is that achieved?

Creating and sustaining this type of culture calls for the deployment of a comprehensive AppSec awareness program. While training is of course a key ingredient in such programs, it isn’t sufficient on its own. The four pillars we see as vital to successfully cultivating a culture of software security are communication, engagement, training and assessment.

Application security teams must first and foremost connect with the people they are trying to influence—the development team. A centralized security-centric channel of communication should be put in place. This empowers security teams to keep developers up to date on all-things-security, including general AppSec news, organization-wide security announcements, and specific training activities.

For example, a weekly security best practice tip, a monthly training reminder, a quarterly security challenge, and an annual company secure development guideline can be communicated. The communication itself should “speak” in the developers’ language, should be targeted at specific developers and specific challenges, and at times, should be disruptive.  Why disruptive? Think about it – to make an omelet, you need to crack some eggs, and to set a software security culture, you need to crack some existing ideas and the “we have always done it this way” mindset.

Getting developers excited about security should be one of the main goals of your AppSec awareness program. In order to achieve that, you need to build their interest in security and get them regularly exposed to AppSec knowledge. You are probably thinking, “Right… so that’s why we perform training.” Training of course is a vital element in keeping developers engaged.

However, I am talking about running competitive and engaging events that get the whole developer’ community involved. These types of activities are needed to get your developers talking about security in the corridors, breakrooms, etc. and actually get developers to enjoy feeling like they’re part of the solution as a security savior.

This pillar is probably the most obvious one of all. Today, many organization are heavily investing in secure code training. In fact, in a recent study, 36 percent of developers reported that they felt their company provides them with security training that helps them write more secure code. The real question here is, “What type of training is most effective?”

Traditional methods of training don’t really mesh well with modern software development environments. For example, in DevOps environments, stopping everything so developers can go to training for a week or two is seen as very disruptive. New features and functionality still need to be built and delivered on time, while developers continue to learn. Accordingly, the most effective training is delivered just-in-time and in bite-sized chunks.

Gamification, of course, always helps to keep training fun. Additionally, you want to make sure you’re covering all the bases by providing developers not just with theoretical guidance, but more hands-on, practical guidance that really lets them wear the “hacker’s hat”. After all, learning-by-doing is one of the most effective ways to absorb knowledge.

Your “AppSec Awareness” graph should always be on the rise. After all, what’s the point of investing in communication, engagement, and training, if all these efforts don’t pay off by reducing your software security exposure overall. To make sure this is the case, you need to keep a close eye on the progress of your development teams.

The best recommendation is to segment your assessment into relevant business units. For example, is team “A” lagging behind? Does team “B” need more training on a specific vulnerability type? Ultimately, you should be tying your security metrics back to your code quality and making developers accountable. Continuous improvement is the name of the game, and to achieve that, you need to constantly assess the current state of your developers’ security mindset.

Want to learn more about how your organization can run an effective AppSec Awareness program? Check out CxCodebashing, the next-generation AppSec Awareness solution that gives security teams all the tools they need to effectively execute and manage continuous AppSec Awareness programs.

 

 

 

 


*** This is a Security Bloggers Network syndicated blog from Blog – Checkmarx authored by Dana Raveh. Read the original post at: https://www.checkmarx.com/2019/09/11/appsec-training-necessary-but-not-sufficient/