Building a Secure Coding Culture

Relationships are the cornerstone of culture. But even the best relationships have gaps — places where the motivations and objectives of both parties seem to be at odds.

The relationship between Developers and AppSec practitioners is no different. Difficulties in that relationship can lead to problems in the Software Development Lifecycle.

Here’s the good news: Gaps can be closed. Differences were made to be resolved. Culture can be built. And in the end, everyone – indeed, the whole organization — is better for it.

First, let’s take a look at the differences between the two parties.

A Tale of Two Drives

Developers are driven by both external and internal forces. They work fast to respond to the business’s ever-changing needs and beat competitors to market. They also – understandably – want to work with the best tools while achieving this end.

Application Security professionals are driven to cover their own wide swath of ground. They want to protect the movement of data within and between mobile devices, web applications, endpoints – pretty much all aspects of software. AppSec also has privacy laws to contend with and must also make sure that the code is free of any vulnerabilities that might expose the user or the organization to harm. Here’s the thing, though. They must do this proactively throughout the development process rather than a follow-up or add-on at the end. It’s the job of AppSec and the testers to be the bearers of bad news if something just doesn’t work.

You can see where this is going, can’t you? Developers see this as detrimental to the process of delivering software in a timely fashion. They have the pressure of management behind them, too. And after working very hard to get something to work, they don’t want anyone coming to them afterward telling them that it doesn’t.

The way to reconcile this situation is to integrate the two cultures – development and security – and make them both part of the application lifecycle.

Enter Secure Coding, a cultural shift where developers are supported in their efforts to write secure code from the start.

Establishing a New Culture

It starts with getting buy-in from all stakeholders: QA analysts, architects, influencers, project managers, and decision-makers. All of these parties should be part of the conversation and part of the team that drives this cultural change. That’s the first step in communicating the idea that AppSec is everyone’s concern throughout the organization. Then the organization can create siloed subgroups to divide and conquer the AppSec issue, as it were.

And check this out. SAMM—the OWASP Software Assurance Maturity Model—is an open framework that can help your organization devise a strategy for software security that covers the specific risks that confront your organization. As of 2020, SAMM v2.0 now offers more content on how developers can code securely.

Flexibility, Holism, and Understanding the Human Element

Developers come in many sizes, shapes, and styles. Some use or continue to maintain legacy software and traditional architecture stacks, whereas others work with the newest architectures where the line between the app and infrastructure as code is not as clear. Any successful AppSec program has to work well with any and all development methodology and style.

A successful AppSec program must also be holistic, covering a company’s entire application portfolio. That means anything outsourced, in-house, or built from open-sourced components; anything that is deemed mission-critical, and everything that’s not.

Understanding on a human level is another key to success, understanding not just the diversity of developers’ styles, but their day-to-day tasks and activities. That way, AppSec can identify small individual steps that can be taken to introduce secure coding to each team, adding in aspects of SAMM that are specific to the organization while slowly acclimating developers. It’s one way to increase AppSec without interrupting the current SDLC. This application of SAMM enables the AppSec team to track software security practices by the developers and produces measurable results.

Build on Strength

Nothing succeeds like success, so it’s ideal to build on habits that developers already have in writing code. Subtly introducing new secure coding habits beats having your developers in a constantly reactive stance, coding and recoding to address vulnerabilities. And fortunately SAMM has a feature called Implementation Review 2 for gauging developer success on this front.

It’s understandable that developers see more automation as a way to streamline their workflows. And it’s a fact that new automation tools can help. But they must be chosen with AppSec oversight and assistance with implementation. That way, security milestones can be reached without adversely affecting the SDLC. AppSec can also work with developers’ timelines for prioritizing and fixing vulnerabilities, and making sure those deadlines are reasonable.

Implementation While in Motion

OK, so this is all well and good. But while we’re sitting here reading this, there’s still code to be written, software to ship, times-to-market to be beaten. We can’t bring everything to a stop until some sort of secure software nirvana has been reached, even if new secure coding practices are being introduced incrementally.

The good news is that you don’t have to. You can use SAMM’s Implementation Review to assess your organization’s source code. This will aid in discovering vulnerabilities and identifying mitigation activities and establish a baseline for secure coding. And your organization will be able to see results as soon as AppSec introduces those baseline coding steps and requirements into the SDLC.

Centralize and Simplify

Now the challenge is to get new secure coding information to developers who are already getting inundated with emails and new information.

The answer is to put all that information and all those resources in one self-service location, then publish a link to it in every email that goes out to the dev group and associated stakeholders. Include things like updates on policies and standards, as well as links to outside info and announcements. Standardize secure coding checklists from across the various teams. If AppSec finds common bugs across software, collect resources on coding against them there. If the organization hosts guest speakers, publish notices there. And you can publish the results of these presentations and recordings of the event. It can even include OWASP articles on how to fix common vulnerabilities. And it can be easily created on a wiki, SharePoint site, or Confluence page.

Balancing the Field

There’s no denying that there’s a global AppSec skills shortage, and that many organizations believe that it’s having a direct impact on their business. At the same time, the number of developers in the field continues to climb. So with limited AppSec talent, how do you make those resources available across the organization?

Create an advisory board that includes developers from each siloed team. Developers will like this because it gives them a voice in how the organization approaches AppSec and some leverage in how it affects their workflow. It’s key to make sure that board meetings conclude with actionable directives and include SAMM initiatives that both AppSec and developers can take back to their groups.

Community Creates Culture, Too

It all comes back to relationships. Creating external relationships is also key to creating a successful secure coding culture. Get to know the members of your local OWASP (Open Web Application Security Project), ISSA (Information Systems Security Association), or ISACA (Information Systems Audit and Control Association) chapters where you’ll be able to meet and talk with your peers about their AppSec programs. Peer support is a great way for security teams to increase their knowledge base through sharing real world experience and expand their resources as they build an AppSec program.