Who owns the responsibility of the software development lifecycle (SDLC) in your business? It’s easy to assume, through a traditional lens, that the CEO and/or Board of Directors might ultimately be responsible for what takes place throughout the SDLC. Whether it’s a federal or state regulation, contractual requirement, or as we’ve seen more recently with the SEC’s crackdown on the reporting of security incidents that is now pulling enterprise CISOs into the mix as in the case of SolarWinds, times are changing, to say the least.

We are seeing a potential shift in who’s ultimately responsible for security events – away from executive leadership who are often disconnected from IT, especially as it relates to the resilience of internally developed software – and more towards executives who oversee the technical aspects of the business on a daily basis.

Questions Arise

The precedent that has been set by the SEC and CISOs being held responsible, combined with the reality of the SDLC being a vital part of the organization’s overall security posture, including incident response, begs the following questions:

1. What is the overall accountability to a business for not fully fleshing out and providing adequate oversight for their SDLC?
2. How does this impact engineering leadership such as the CTO or VP of Engineering at any given company? Does it mean these roles now own legal and business accountability for the SDLC?

It wasn’t that long ago when these questions would have seemed preposterous. Unfortunately, today’s business climate is different. Now, in the new reality of upstream accountability, these aspects of the SDLC need to be discussed – not just for understanding what needs to be tweaked in the process but also understanding who all could be held liable when an incident or breach occurs. 

Expecting the Expected – When Worst-case Scenarios Arise

It’s one thing to expect the “unexpected”. You know, those things that no one has ever witnessed or even thought of. It’s, no doubt, near impossible to protect against threats that have never existed. The reality is, it’s quite simple when it comes to software security and the SDLC. There are plenty of things we do know about that can wreak havoc:

• External hackers and rogue employees
• Developers and QA professionals that have never received formal security training
• Applications that go untested
• Common vulnerabilities involving areas such as unvalidated input and user session management 
• Confirmed exploits that warrant the execution of incident response procedures

The best way to look at security in the SDLC is to expect the “expected”. We all know these problems exist. It’s not like they come out of nowhere. And they’ve been around for decades. The problem is many businesses and those in charge of security oversight (including the SDLC) are simply unprepared for them. 

Whether the issues are “unexpected” or “expected”, security incidents and data breaches can and will occur. It’s not just an IT thing or a security thing or even a software development thing. It’s ultimately a business problem – one that impacts all employees involved including those in charge of the creation and oversight of software. That’s why this is such an important topic to consider.

What Should You Do Now?

Of course, every business has a different level of risk tolerance. Every situation is different. There are different regulations, different interpretations of the regulations and so on. There’s no definitive course of action. However, there are some things that could (and likely should) be discussed internally to ensure the enterprise and all parties involved are protected. This includes:

1. How does engineering see this potential accountability for the SDLC?

2. Is engineering set up to own security events arising from weak SDLC practices? How do they know where they’re doing well and where they’re not? What are they measuring? Do the measurements paint the entire picture?

3. Is engineering working closely enough with information security to fully understand what the risks are and where the opportunities lie?

4. Is Directors and Officers liability insurance warranted for engineering executives?

5. Which parts of the SDLC need to be improved to enhance resilience and overall security? This might include:

   • Better standards that are documented and everyone is fully on board with
   • Improved threat modeling using tools and quantitative analysis rather than mere assumptions
   • Shifting security testing the left
   • Doing more – or less – source code analysis depending on the value it’s providing

6. What is being done to review/audit the SDLC on a periodic and consistent basis to seek out gaps that can lead to security risks?

These are conversations that need to be taking place among both security and engineering teams and likely including compliance and legal. A strong focus needs to be placed on the SDLC given how many security flaws begin (and can end) in the process. The precedent has already been set for CISO security accountability. Are CTOs and VPs of engineering next? Quite possibly so. Time will tell. One thing’s for sure, it’s better to be prepared to meet such demands in advance than scramble to figure it all out once an incident has already occurred.