Software security myth #6: Security should be solved by developers
Q: Should I leave security up to my software developers? A: You should train them, for sure. But you need a software security group to coordinate security.
Who should “do” software security?
- Security people
- Compliance people
- Software developers
- All of the above
- None of the above
Sadly, solving software security is not as easy as picking only one population (i.e., software developers) to assign the security problem to. In fact, software security does (eventually) take “all of the above,” but ultimately must be coordinated by a central software security group (SSG).
We know from the Building Security In Maturity Model (BSIMM) that a software security initiative (SSI) should be led by a SSG. In fact, a SSG is a necessity to execute software security, application security, product security, or whatever you’d like to call it. The point is, creating a SSG is the first step when your firm is ready to tackle software security.
Strategizing your SSG
The notion that software developers—and only developers—should collectively and magically be responsible for software security sounds great in theory, but it never actually works in practice. So if a SSG is not just a bunch of developers, what does it look like?
Here are a few key things to consider when forming your SSG:
- What kinds of people should join to conduct necessary security functions?
- How big should the SSG be?
- How do we even organize it in the first place?
We asked real firms how they went about organizing their SSG. At the fall 2014 BSIMM Community Conference in Monterrey, California, we posed these questions to the BSIMM Community. During a break-out session, complete with plenty of cocktails to get the conversation going, 23 firms presented and discussed their SSG structure. Once we heard from all presenting BSIMM firms, five major groups emerged:
Services
Seven of the presenting firms built a SSG to provide software security services. This is the most common organizational approach in our data set. These SSGs are structured in terms of specific services they provide to the rest of the organization (i.e., penetration testing, code review, architectural risk analysis). Among the seven firms in this category, the most commonly provided service was code review with static analysis.
Policy
Five firms built a SSG around setting policy. This approach sets policy that is to be enforced by technologists outside of the SSG. 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 doesn’t hold much power beyond what they can influence, and they take a “set a goal and hope” approach.
Business unit
Two firms built a SSG mirroring business unit organizations. This approach is a more difficult way to get things up and running. 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.
Hybrid
Four groups built a SSG with a hybrid policy and services approach. In some cases, the SSG finds itself conflicted in a sense that it sets policy that is mandatory, but doesn’t have the service bandwidth to execute the work for all the teams that want it. This leads to questions like “Who pays for what?” and “Who gets the blame when delays occur because of lack of software security service bandwidth?”
Management
Three firms with very mature initiatives had SSGs structured around managing a distributed network of others doing software security work.
And just for the record, the two remaining firms (among our 23 total presenting firms) were organized in unique ways found only in their firms. In some sense, replicating this approach is not really possible.
A SSG for the long term
Now that you know the first step is to form a SSG, the next step to take into consideration is to make sure the SSG includes both software people with deep development know-how, security people with strong architectural knowledge, and people who can interact with the business.
It should be obvious from what we’ve said here that the idea of simply training all the software developers is another one of those “yes, do that, but not only that” software security best practices. Should you train your developers and arm them with software security know-how? Yes! But you also need to check code for bugs, check design for flaws and check systems for security holes. Why? Well, aside from the obvious reasons, your developers don’t write all the code you deploy. Even if your code is perfect, all that vendor code and other stuff created in groups without a SSI will trip you up every time.
