Building Secure Software: It Takes a Champion

This is the second post in SAFECode’s Month of Champions series on building and sustaining a successful Security Champions program. See here for Part One.

By: Vishal Asthana, Security Compass (former); Manuel Ifland, Siemens; John Martin, Boeing; Altaz Valani, Security Compass; Tania Ward, Dell; Nick Ozmore, Veracode; Kristian Beckers, Siemens; Izar Tarandach, Autodesk

Familiar pain?

Organizations and their development teams often struggle with scaling their Secure Development Lifecycle (SDL) efforts. This is typically due to one or more reasons below:

• Staffing limitations: Centralized security teams (especially in large- or medium-sized organizations) often have to operate with only a handful of product security staff. This means the security team usually does not have the resources to support every single product or application team across the enterprise.
• Skill Shortage: Development teams willing to support security activities have to depend on security teams for security guidance because organizations hiring developers/engineers typically do not differentiate candidates based on security skills or background. Software security is unfortunately not yet commonly part of software engineering university education or training, so developers may lack a deep understanding of both internal and customer-related security (and regulatory) needs.
• Diversity of development processes: Organizations with diverse development processes and product lines may face the challenge of translating the SDL requirements into each product team’s specific development process and terminology. Applying the corporate requirements to the local teams’ processes requires knowledge at the local level.
• “Bad Cop” perception: Security teams are commonly viewed as bad cops, waiting to handout security violation tickets. This sometimes adversarial relationship leads to frequent resistance from development teams to give AppSec a seat on the roadmap discussion table and encourages a culture of AppSec risk exception to push releases through.
• Prioritization Challenges: Security development activities are frequently prioritized lower than functional development activities owing to the customer value-driven perspective. As there is a lack of established risk-to-value calculation for security development activities, prioritization is cumbersome or missing, and often the most technical person is chosen to handle that calculation even though they are not equipped to do so.

To build security into an organization’s DNA, a company must create a security culture from top to bottom. SAFECode Chairman Eric Baize talked about this in his recent keynote at OWASP AppSec California 2018. To paraphrase Eric, ‘Successful implementation of software security at scale has led to an emerging need of bringing a cultural change across development organizations, software developers, and technology users. Development organizations play a pivotal part in serving this need and should plan on creating an ecosystem that makes security pervasive for developers. They could do so through a multi-year program aimed at driving multi-tiered expertise and empowerment across all engineering functions.’

Development organizations receptive to the idea of building a security culture generally employ an ad-hoc mix of activities to accomplish the same, such as:

• CTFs (Capture-the-flag) Exercises: Time-boxed gamification exercises geared at helping development team members learn security concepts in a “lets-hack-dummy-application” way. Often, the belief is that attendees will automatically start applying the knowledge gained during such exercises in their day-to-day roles, but this hope is often misplaced when these exercises are conducted in a vacuum.
• Finding Firefighters: Development team members (often senior developers) who have been “voluntold” to help out with one or more security activities due to a pressing need such as audit finding, client ask, etc. For example, they are told to help triage the security scanner report shared by the client and teach others informally.
• Informal and/or half-baked programs: Security teams often create an informal understanding with some development team members around the discussion and execution of one or more security activities. While creating these relationships is helpful, such ad-hoc arrangements do not have management-level visibility or support, are not formal, and lack well-defined incentives.

Unfortunately, in the absence of program-level thinking and support, these type of ad-hoc efforts are usually met with struggle, adoption resistance or complete failure.

What is missing from these ad-hoc approaches to software security culture development is the “glue layer” at the program-level to cohesively drive individual project-type security activities. This layer relies on resident Security Champions (SCs) — members of the development team that have been identified and empowered to stay constantly involved in helping to guide and execute security activities on a day-to-day basis. Unlike security team experts with limited or restricted availability, SCs are consistently available to support SDL execution and security activities at the development team level.

An SC Program can drive significant value for any organization looking to improve software security. As such, SAFECode is kicking off 2019 with a Month of Champions. Throughout January, SAFECode members will be sharing our experiences with creating and sustaining a successful SC program. We’ll cover questions such as:

• What does it mean to be a SC?
• Do (and can) SCs replace Security Teams?
• How does one identify potential SC candidates?
• Is SC a new career path?
• How does a SC Program Strategy tie with a development organization’s existing security efforts?
• How should an organization go about building a SC Program Strategy?
• What about SC Program rollout guidelines?
• How can a SC Program be sustained?

Our authors will be available to answer any questions and discuss thoughts our readers may have on this topic. Be sure to follow along, ask us questions and start 2019 off strong. Next up, we’ll be putting a face to Software SCs, describing the qualifications and duties of a typical SC.