Expert commentary on the 2018 Devsecops community Survey

Helen Beal, DevOpsologist | Ranger4

 

In 2017, 57% of all participants in the DevSecOps Community survey confirmed that, yes, they did have an open source policy. In 2018 this has risen to 64% – but 35% say they ignore it.

Breaking that down further: in 2018, 58% of those with no DevOps practices and 77% of those with mature DevOps practices reported having an open source policy. 46% of the former and 24% of the latter reported ignoring it. Effectively, that’s then just 12% of organisations with no DevOps practices actually using an open source policy, while 53% with mature practices are following internal regulations. Having, and using, an open source policy is then an indicator of mature DevOps practices.

The above begs the question: why are people ignoring the open source policies they have? It’s worth noting here that nearly half of survey respondents reported being in development or DevOps roles and less than 3% reported having AppSec or security specific roles. That number shouldn’t be a surprise alongside the discovery that developers typically outnumber security 100:1 (and, according to the survey, operations 10:1). But, perhaps what we can conclude is that it’s the developers who are ignoring the open source policies that are set by the security professionals in an organisation.

A principle of DevSecOps is that security is everyone’s job, not just one person’s job. Organisations reporting higher levels of maturity also report higher levels of this principle of thinking, phrased in the survey as: “Security is part of everyone’s role” – 91% versus 78%. Note though, that both these levels of acceptance can be considered high.

Is it concerning then, that there are low levels of acceptance of an open source policy? Is an open source policy a critical part of security policy and procedures?

First, let’s reflect on what constitutes an open source policy. There are several examples available on GitHub from Google, Linux Foundation, Rackspace and Zalando. A key focus of these examples is how these organisations create open source software themselves, rather than how they consume it, although Rackspace’s says:

“An open source policy exists to maximize the impact and benefit of using open source, and to ensure that any technical, legal or business risks resulting from that usage are properly mitigated.”

The benefits of using open source are obvious – why reinvent the wheel? The ability to scale development activities by consuming pre-built artifacts is clear. The appeal of using one technology that’s free rather than buying a licenced, chargeable piece of software is also apparent. But so are the risks – so it is concerning that some developers are simply ignoring the policies crafted and communicated for their organisations, likely for the sake of speed and costs.

IDG’s ‘Best Practices for Creating an Open Source Policy’ provides practical advice and names developers first in the list of stakeholders to include:

• “Developers – the people who will have to follow the policy

• IT staff, as they probably download and use open source software

• Managers of teams that use open source software

• Attorneys

• CIO and staff

• Technical architects; many companies have architectural committees, and they should be involved”

And they also include the qualifier: “the people who will have to follow the policy”. But it’s eight years since this article is written and this current survey tells us that many of the developers aren’t following the policy. “Ignoring” is a strong word – it suggests wilful obstruction. We know though that the vast majority of developers we work with take enormous pride in their work – they don’t want to create licensing and security issues for the rest of their organisation through the choices they make for the components in the software supply chain. But it’s just too hard for them to find out whether what they are about to download and incorporate into their application comes with what level of risk.

And they are not alone. The IDG article goes on to explain why you might need a background statement for your Open Source Policy, for example, when:

• “Management doesn’t know how much open source software the company uses or depends on

• There are widely varying opinions on how much open source software is used

• There’s an open source software rule or policy that conflicts with reality (e.g., «No open source allowed,» but your IT infrastructure is built upon open source software)

• There are big disagreements on how the company should use open source software”

The 2018 DevSecOps survey data also tells us that 38% of organisations have a complete bill of materials for each software application while 62% of organisations report that they do not have meaningful controls over what components are in their software applications.

This doesn’t have to be the case. We can automate all of this with tools like Sonatype’s Nexus Lifecycle. We can automate the bill of materials and make it visible to all where we might have open source components in a software supply chain and highlight the risks of using particular components whilst offering alternatives – and we can do this in the IDE, thereby taking the burden off the developer so they don’t ever have to sacrifice quality of their product for speed of delivery. You can automate your open source policy and break the 100:10:1 security constraint.