The roles and responsibilities that lead to better software security initiatives

If a project or initiative is going to be successful, it needs a plan spelling out what to do and how to do it. But that’s not enough. Somebody, or a group of somebodies, has to be in charge of getting it done. They have to own it. 

That’s the case with software security initiatives (SSIs), which are the focus of the Building Security In Maturity Model (BSIMM), the annual report by Synopsys. 

The goal of an SSI is to improve the security of every element of the software journey—designing it, building it, and maintaining it. That takes a combination of standards, policies, and metrics structured to fit the individual needs of an organization and scaled around its staff, processes, and software portfolio.

And it takes people with the right skills and the appropriate authority to create, maintain, and improve an SSI.

It does this through in-depth observations of the SSIs of participating companies—130 for this year’s report—primarily in nine verticals and spanning multiple geographies. 

The BSIMM never prescribes a set way to create and improve an SSI. Instead it observes and reports on software security activities or controls (121 this year) that organizations are actually spending time and money to do.

The BSIMM has been described as both a measuring stick and a roadmap, not an instruction manual. Its observations yield useful information on how SSIs mature and are structured, including which individuals or groups are usually in charge of the major components of an SSI. The roles and responsibilities of those individuals and teams is the focus of this post.

Who is responsible for driving effective software security initiatives?

Indeed, if an organization hopes to develop an effective SSI, it’s crucial to set priorities and make clear who is responsible for making those priorities a reality. This will empower and motivate those involved—any confusion over either or both will undermine the initiative and damage morale. 

Through more than a decade of research, the BSIMM has found the following to be key players in a successful and effective SSI.

Software security group

A software security group (SSG) leader and the SSG itself are only slightly less critical to an SSI than the executive in charge. All of the 130 organizations surveyed for BSIMM11 have an active SSG in place. Its importance lies in its consistency and focus on security. Without an SSG, it’s unlikely that an organization will be able to carry out all necessary BSIMM activities across a software portfolio. The BSIMM has found that more-mature SSGs include individuals with both coding and architectural skillsets.

The evolving role of SSGs

But SSGs are changing. Last year’s BSIMM10 was the first to document SSIs driven by engineering-led efforts—those originating bottom-up in the development and operations teams rather than top-down from a centralized SSG.

That means as software security initiatives evolve, the SSG might be entirely a corporate team, entirely an engineering team, or an appropriate hybrid. 

For that reason, BSIMM11 has expanded the definition of the SSG. Rather than implying that it’s always centralized in corporate, the report now specifically acknowledges that SSGs may be a collection of people from corporate, engineering, and perhaps elsewhere.

Although members of the software security team are ideal SSG members, they can be hard to find, so the best alternative is to start with developers and teach them about security. 

The responsibilities of SSG members include comparing and selecting security tools, defining secure design guidelines and acceptable remediation actions, and so on. In the spirit of agility, these individuals could also contribute significant amounts of code to delivery, including code that operates continuous build and integration, and code that goes beyond simply adding defect discovery steps to the pipeline. They could even implement security features or broader security architecture as part of the delivery team, as well as author orchestration or other infrastructure-as-code solutions for secure packaging, delivery, and operations.

Satellite

Many software security initiatives have contributors—often developers, testers, or architects—who are interested in improving the organization’s overall security. These individuals, known as satellites, security sponsors, or security champions, aren’t directly members of the SSG but they play a key role in increasing stakeholder and executive awareness, understanding, and support of current SSI activities and future needs and goals. 

Satellite team members are sometimes chosen for software portfolio coverage, with one or two members in each product group, but they are sometimes chosen for other reasons such as technology stack coverage or geographical reach. Sometimes they’re more focused on specific issues such as cloud migration and IoT architecture. 

For example, the satellite role is evolving rapidly in firms embracing DevOps and DevSecOps. These firms recruit members from cloud and related security-oriented roles and increasingly have them apply their expertise for everyone’s benefit. 

And it’s clear that a strong satellite is a sign of a mature SSI. BSIMM11 found that 13 of the 15 firms with the highest BSIMM scores have a satellite group, with an average size of 269 people. 

The report also noted that “the more-successful satellite groups get together regularly to compare notes, learn new technologies, and expand stakeholder understanding of the organizations’ software security state.”