The SUNBURST malware attack on SolarWinds shone a light on how threat actors can "shift left" and attack the software supply chain itself—with catastrophic results. To defend against similar attacks in the future, all organizations that build software for commercial or internal use must shift their defenses left to protect all aspects of the software supply chain, including the entire build pipeline. Although it is clear that something needs to be done, the big question is which part of the organization should take primary responsibility—InfoSec or development teams.
To better understand where organizations are leaning, Venafi commissioned a global study of more than 1,000 development and InfoSec professionals in English-speaking countries. But the results show a troubling lack of consensus on how best to move forward. So, we asked some of the key security contributors to the Venafi ecosystem what they thought about who should own software assurance security going forward. Read on to see their responses.
SolarWinds: Can organizations change the way they secure software build environments fast enough? See survey report.
Development takes the lead, partners with security
—James Penney, CTO, Device Authority
“I think there are cases to be made for a few departments, but my core thought is that development have to take responsibility. The logic behind that is because in any other process, your data signing should take place as close to the source as possible. The further away the data gets from its source, the more at risk it becomes. However, I do think that development should take input and direction from IT Security, to ensure that the correct corporate security policies are adhered to—working as an ‘enforcement’ entity. Development should not be left alone to decide what is best and shouldn’t be ‘marking their own homework’.”
Collaboration and accountability early in the development cycle
John O’Connor, VP Product Management, Crypto4A
“The originating conditions for these attacks lie earlier in the chain and start with security not being considered an equal partner and core component in the design, development, implementation and updates of the software and its supporting infrastructures—that is in a lack of Security by Design in the lifecycle of the product itself. We all have work to do together to provide better security for our stakeholders and these supply chain knock on issues highlight this reality for us—no one link in the chain can do the job, we all must work together and hold each other accountable to do better.
One recognition that would be helpful is to accept that we have adversaries whose capabilities are simply higher than the current security standards we previously set for ourselves as software developers. We need to provide continuous training, APIs to security solutions that integrate into existing development tools and workflows, and automation tools to support developers. Again, the key to raising our security standards is collaboration and accountability early in the development cycle without putting the burden solely on developers.”
CISO should own supply chain security
—Tim Johnson, Senior Product Marketing Manager, CloudBees
“At CloudBees, we believe a secure software supply chain goes well beyond simply securing the code. The process itself must have controls and automation in place to ensure policies, tests, and requirements are met. Further, the process should secure against tampering, drift, and manual errors. In addition, a supply chain must be able to instantly respond to and mitigate post-production vulnerabilities in order to be considered secure. It is our experience that supply chain security ultimately rests with the CISO because they have overall responsibility for the security and incident response of the organization. The software supply chain is too complex and too broad-reaching for its security to be left to any lower-level department.”
Empower dedicated DevSecOps teams
—Adam Cason, VP of Global and Strategic Alliances, Futurex
“Although all IT practitioners should have a working knowledge of information security, making it “everyone’s responsibility” sometimes results in it becoming “nobody’s responsibility”, unfortunately. I’m seeing many forward-looking organizations empowering dedicated DevSecOps teams to make policy, process, and technology enhancements that result in demonstrably more secure software build pipelines.”
Bake security into DevOps automations
—Andrew Lance, Founder and CEO, Sidechain Security
“We believe that Development should be responsible. However, we strongly encourage our customers to make this a shared responsibility across Dev and IT Security. There doesn't need to be a tradeoff between speed and safeguards. Instead, we advocate that Security teams empower Devs to take responsibility and bake it into their automations. Devs should expect Security to provide ongoing governance and support as its internal partner. Each side needs to hold the other accountable—trust but verify.”
Good enough is not enough
—David Madden, Sr. Director Business Development, Thales
“The concept of “good enough security” is predicated on the belief that the threat landscape is static in nature, and that you have been successful in enumerating all known vulnerabilities. As we all know by now, data protection is an ever evolving living entity, plus the risks are infinite in nature. At best, the concept of “good enough” captures a fleeting moment in time. As the cybersecurity world continues to grow, organizations must implement security measures that not only address what is known, but also ensure their practices are capable of addressing threats as they evolve over time, requiring the security, IT, Development & operations teams to work together to stay one step ahead of these threats.”
How does your organization stack up?
Who is responsible for building a resilient environment that effectively defends against these types of attacks in your organization? This is the urgent question that many organizations are struggling to answer right now. “Time is ticking. Boards and executives will be held accountable for failing to build secure software, much like executives at companies (e.g., Equifax) more traditional security breaches occurred were held accountable,” warns Kevin Bocek, vice president, security strategy and threat intelligence at Venafi. Leadership must make decisions to designate accountability and clearly identify how the organization needs to change. If we fail to change quickly enough; we are putting our business and our customers at risk—and the damage could be immeasurable.