VP Solutions at Synopsys Software Integrity Group.
getty
Over the past several months, I’ve written about how software security testing has evolved to keep up with the speed of software development. That evolution is critical. Software security is important now more than ever, and its importance will only continue to grow for several reasons:
• There will be more of it — hundreds of billions of lines of new code are written every year.
• Software controls everything. Vehicles, home security, appliances, traffic control systems, utilities — the sky’s the limit.
• The speed of development has increased by orders of magnitude in the last decade, and the software attack surface is expanding exponentially.
But security teams can keep up — if they do it right. In my previous post, I focused on one of the crucial ways to do that: by ensuring that just enough security testing is done — at exactly the right place and time — throughout the software development life cycle (SDLC) and with a focus on automation.
In this post, I’ll describe another enabler of security testing at the speed of development: the evolution of the software security initiative (SSI).
As my company’s most recent Building Security In Maturity Model (BSIMM) report documented, SSIs are shifting from a top-down, centralized, governance-based practice to a federated operation. “Security champions” are embedded in product teams, and security is included as part of the DevOps process.
None of this happened overnight. The evolution of the SSI has moved through three phases and is now entering a fourth. That evolution involved changes in culture, processes and technology. So let’s look at that evolution.
In the first phase, the focus was on security as a cost center. The idea was to spend only as much as was required to convince ourselves that we were doing enough to ensure security. That tended to be done by a centralized team — a low-level team without much bite, but it did introduce some of the tools we still see today.
That led to some very ad hoc practices. A team that depended on open source software might adopt an open-source testing tool because the legal team was worried about licensing requirements. A team writing a lot of custom code might use a static analysis tool. Typically, point tools were purchased to address specific problems.
The second phase focused on security as compliance — but not open-source license compliance. A central team would define policy and the security team would ensure enforcement. You’d see the CISO’s office in a leadership role bringing a little more “teeth” to the security team. They would come in and overrule the development team, saying, “We need to do this as policy, and we’re here to ensure you comply.”
But it would quite often get done late in the SDLC, consistent with classic waterfall development and often disruptive to timelines.
The third phase is what more companies are now adopting — the idea of software security as tooling in the SDLC. This phase reflects maturity in the CISO’s office, a build-up of AppSec expertise and recognition of the impact on development.
And the range of available tools has increased from just a handful — a source code repository, a compiler, build tools and some custom scripting — to hundreds of commercial and open-source tools.
In any given environment, there will be dozens of tools in a single pipeline. A utility company that performs network monitoring of service usage may use over 100 tools in the SDLC to support project initiation, definition and user story, as well as to write code, build code, test code, store binaries, deploy binaries and monitor binaries.
When you’re using over 20 tools, you need to start worrying about orchestrating activities, because hard-coding integrations make them very brittle and fragile.
And that’s what “security as tooling” is about: policy defined as code and the CISO team starting to devolve the organizational structure. We’ve been seeing a federated model in the BSIMM, with product security champions deployed into product teams.
Security champions help product teams understand and adopt the guidance from the central security teams. This also creates trust between the teams. This fundamental shift in organizational structure addresses issues with the enforcement approach that didn’t work when applied top-down.
Finally, the fourth phase — which is just starting but will grow — is security as a business enabler. So far, only a handful of companies we see are following this model.
Positioning security as a business enabler means thinking of security first when you think about anything you do as a company: what data you collect and how you store it, use it and share it. If your teams think and talk openly about what it means to protect all data so that it’s not at risk of being attributable, then you can claim that your company is beyond reproach.
It must be championed from the top, from the C-level executive on down. And it has to apply to all areas that might come into contact with sensitive data. That goes far beyond the basics of keeping credit card data safe. Once you store data about customer activities and analyze it, there are real risks to be considered.
Security as a business enabler means thinking deeply about the policies applied to privileged information and developing and nurturing customer trust. That’s where security and privacy have to come together — you simply cannot develop trust without protecting privacy.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
