Manage Learn to apply best practices and optimize your operations.

McGraw: How to build a team for software security management

Software security expert Gary McGraw points out five ways member organizations in the BSIMM group are structuring their software security groups.

Coauthored by Caroline Wong, security initiatives director at Cigital, Inc.

Call the team what you will -- application security, software security, product security -- if you count on software to succeed in your business, you need a set of people in your organization dedicated to software security management (yes, even if you just buy your software from others). We call this the software security group (SSG), and data from the Building Security In Maturity Model (BSIMM) shows that establishing an SSG is a necessity to execute software security, application security, product security or whatever you call it.

Assuming you agree with this claim, how should your SSG be organized? What kinds of people performing what functions do you need in it? How big should it be? These are all questions we put to the BSIMM Community at the fall 2014 BSIMM Community Conference in Monterey, California. During a cocktail-fueled poster session (with a real mixologist), 23 different firms presented and each discussed its particular SSG structure.

Make software security somebody’s job

First off, a short digression is in order. Any good business manager knows that if you actually want to get something done, you have to make it someone’s job. If you go to your network security people and ask them if they have software security covered, they are likely to grumble and point to the software people whose job is to build code that does not suck. "Ask them," they’ll say. But if you go to the software people and ask them whether they have software security covered, they’re likely to point right back at the network security types and say, "It’s their job." The two groups, generally speaking, don’t get along well. (By the way, there is no magic cross-functional ninja team made up of network security people and developers reporting to two different bosses, either.) So with all of this back and forth finger-pointing, who ends up in charge of software security? Nobody.

Logo source: Gary McGraw

That means nobody is working on software security, nobody gets fired when software security fails, and -- most distressingly -- nobody gets a bonus when software security goes miraculously well (actually the CEO gets a bonus in that case, because the CEO always gets a bonus).

More seriously, someone and some group needs to be directly and explicitly in charge of software security management. That’s what an SSG is for. (For more, read this BSIMM document.) Every firm in the BSIMM Project (93 and counting) has an SSG.

Five ways to structure an SSG

When we looked over the SSG structure data presented by the 23 BSIMM firms in the SSG study, five major groups emerged (with one to grow on). Here is what we observed:

Group 1: Seven firms built an SSG to provide software security services. We’ll call this group Services, for short.

Group 2: Five firms built an SSG around setting policy. We’ll call this group Policy.

Group 3: Two firms built an SSG mirroring business unit organizations. We’ll call this group Business Unit.

Group 4: Four firms built an SSG with a hybrid policy and services approach. We’ll call this group Hybrid.

Group 5: Three firms with very advanced initiatives had SSGs structured around managing a distributed network of others doing software security work. We’ll call this group Management.

Group 6: Two firms were organized in unique ways found only in their firms. We’ll call this group Platypus (and ignore it from here on out).

Let’s spend some time discussing SSG structure inside of each group:


This category of SSG structure is the most common organizational approach in our data set. The SSGs are structured in terms of specific services they provide to the rest of the organization: penetration testing, code review, architectural risk analysis and so on. Among the seven firms in this category, the most commonly provided service was code review with static analysis.

SSG’s structured in this category scale by first figuring out what work to do (often by doing it themselves) and then engaging others in the organization to do some of the work for them. For example, an SSG might help each product development group come up to speed on code review for security and then guide them as they carry this out. The non-SSG people working on software security are referred to as satellite (think of them as orbiting around the SSG doing good software security work). In the Services category, those firms who develop a strong satellite and manage its evolution closely have higher BSIMM maturity scores and scale better that those firms with no satellite.

On average in our data set, this group has a BSIMM maturity score average of 36.4 with 7.3 people in the SSG and a satellite size of 7.1. The average number of developers in this group of firms is 4825.

Just for the sake of numerical context, recall that BSIMM-V maturity scores range from 13 to 93 among the 67 firms in the study. BSIMM-V describes the work of 975 SSG members working with a satellite of 1,953 people to secure the software developed by 272,358 developers. SSG size on average in BSIMM-V is 14.78 people (smallest 1, largest 100, median 7) with a satellite of 29.6 people (smallest 0, largest 400, median 4) including developers, architects and people in the organization directly engaged in and promoting software security. The average number of developers among our targets was 4,190 people (smallest 11, largest 30,000, median 1,600), yielding an average percentage of SSG to development of 1.4%.

software security management, software security group (SSG)
A representative org chart for the Services SSG structure.


This category of SSG structure is also commonly observed in our data set. This approach sets policy that is to be enforced by technologists outside of the SSG. In some cases, a small satellite helps with execution, but more commonly, execution is left to outside groups. For example, the SSG may declare that code review is mandatory and must be completed with no high-risk vulnerabilities resulting, but does little to steer development groups directly in how to get this done. In many cases, the SSG does not wield much power beyond what they can influence, and they take a "set a goal and hope" approach.

On average in our data set, this group has a BSIMM maturity score average of 40.8 with 10.2 people in the SSG and a satellite size of 16. The average number of developers in this group of firms is 8630.

software security group (SSG), software security policy
A representative org chart for the Policy SSG structure.

Business Unit

This category of SSG structure turns out to be a difficult way to get started. The idea is to provide the same kind of help to each of the business units in an organization, tailored to their way of working. In this approach, the only way to scale is to build a strong satellite, but the diversity among business units leads to extra work.

On average in our data set, this group has a BSIMM maturity score average of 30.5, with 4.5 people in the SSG and a satellite size of 27. The average number of developers in this group of firms is 1650.

software security group (SSG), software security business unit
A representative org chart for the Business Unit SSG structure. Each business unit in a firm has one of these structures and coordinating between them becomes a 'headless chicken.'


This category of SSG structure combines the Services approach with the Policy approach. As in the Policy organizational structure, development of a strong satellite makes this approach work at scale. In some cases, the SSG finds itself conflicted in a sense that it sets policy that is mandatory, but does not have enough service bandwidth to execute the work for all of the teams that want it. This leads to questions like: "Who pays for what?" and "Who gets the blame when delays occur because of a lack of software security service bandwidth?" This can lead to bad feelings in some cases. A satellite tends to address this challenge head-on as an approach like this matures.

On average in our data set, this group has a BSIMM maturity score average of 46 with 16.3 people in the SSG and a satellite size of 15.5. The average number of developers in this group of firms is 2300.

Software security group (SSG), software security hybrid
A representative org chart for the Hybrid SSG structure.


This category of SSG structure is found in high maturity organizations that in general have practiced software security for years. This kind of SSG scales directly through care, feeding and management of its satellite.

On average in our data set, this group has a BSIMM maturity score average of 64.3 (the highest) with 18.7 people in the SSG and a satellite size of 174.7. The average number of developers in this group of firms is 10,833.

software security management, software security group (SSG)
A representative org chart for the Hybrid SSG structure.

SSG evolution over time

In general, firms' SSGs normally start with either a Services, Policy or Business Unit organization structure, then evolve into a Hybrid, and eventually mature into a Management organization. As the structure of the SSG evolves over time, a satellite is formed. The importance of a strong satellite cannot be overstated. There is a strong correlation among the 93 firms in the BSIMM between the existence of a satellite and high maturity score.

In final analysis, no matter what approach your firm ends up taking to SSG organization, creating an SSG and an associated satellite is essential.

Next Steps

Explore the many Gary McGraw resources available at SearchSecurity.

This was last published in March 2015

Dig Deeper on Secure software development

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Does your organization have a software security team in place?
I’d like to think that system administrators are security gurus, but I know this isn’t the case. Our security team has a good understanding of vulnerabilities. They also know where to find up to date info on new vulnerabilities that occur.
System administrators (usually) know nothing at all about software security.  This is about building security in, not protecting the broken stuff from the bad people with networking gear and patches.
Um, just me. But I leverage the connections I've made in years as a technology writer to keep me up-to-date on what I should be doing to keep my systems and data secure. 
What we're talking about is for enterprises.  If we want future systems to be secure (even if we're only consumers), we need to make sure that the people who build those systems know what they are doing.  All major ISV's have software security groups as do most major financial services organizations.  Healthcare is next.  

Would you prefer that the developers of those systems ignore security?