If you’re attempting to create or acquire, deploy and maintain secure software, and you’re operating without a clear governance structure, you may want to reconsider.
Security governance is simply a framework of policies, standards and processes that form a structure for making decisions and defining expectations. With respect to software security, the most important combination of policies, standards and processes is the ‘Secure SDLC’ that defines how a firm will ‘build security in” for both its various SDLCs and for software acquisition.
The vast majority of firms have no software security governance. That means they have no secure SDLC and, despite many claims to the contrary, no systematic control over the security posture of their application portfolio. That’s bad. Customers don’t like it, insurance companies don’t like it, regulatory bodies don’t like it, and—coming very soon to firms everywhere—executives and Boards of Directors don’t like it. In today’s world, control over the application portfolio security posture is simply a required cost of business.
Some firms establish their framework through a centralized corporate group that issues formal policies, mandatory standards and rigid processes. When done in a vacuum without appropriate stakeholder input, engineering teams often see this as bureaucracy simply for the sake of bureaucracy.
Some firms establish their framework through an engineering group that defines, for example, required technology stacks, mandatory coding standards and defects that are always unacceptable.
In the end, it may not matter what group establishes—and enforces—the mandatory expectations as long as it actually gets done. Without these efforts, there’s no ‘secure SDLC’ regardless of anyone’s good intentions.
While helping organizations design software security programs, we’ve seen governance frameworks of all shapes and sizes. And we know that what may fit a global organization employing thousands of developers and building large, dynamic application portfolios in a highly-regulated environment may be very inappropriate for a smaller engineering-driven company with a handful of applications, a distributed management culture, and no compliance requirements.
However, regardless of your organization’s size, clear, enforceable and enforced software security policies and standards—especially when executed in the form of a Secure SDLC—will improve communication and increase your ability to create and maintain secure software. This is true even if your group hates the word “policy” and doesn’t put much stock in “standards.” Regardless of the names used in your culture, every process works better when it’s clearly defined and enforces expectations you can monitor and measure.
Interested in learning more about how better security governance can help your organization improve its ability to create, acquire and field software that is more secure? If you already have a software security initiative and it needs improvement, we have many services that will help you, including a BSIMM assessment that measures your program. If you don’t have an initiative today, you may want to consider Synopsys’ Software Security in-a-Box service to jumpstart your governance program.