Security governance is 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, which 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 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 this is done in a vacuum without appropriate stakeholder input, engineering teams often see it 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 which group establishes or 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.