Group hug: developer team proximity could ease security fears

Wolfgang Kandek, CTO at Qualys has spoken to the Computer Weekly Open Source Insider blog this week to present his reaction and thoughts to Black Duck’s open source security report: The State of Open Source Security in Commercial Applications.

Qualys is a network security and vulnerability management company.

Open Source Insider: Why is open source software viewed as a security risk when, surely, open source software gets more eyes on it so, in theory, is therefore more secure?

Let’s think online and remember that web applications can work at two levels – there might be open source products used for a specific function, like ImageMagick to handle image manipulation, that are embedded in the web app. Alternatively, there might be specific sections of open source code that are used within the application itself.

More group hugs needed when two functional areas are handled by different teams

More group hugs needed when two functional areas are handled by different teams

The challenge here is that these two functional areas are normally handled by different teams. Scanning for vulnerabilities on open source products would be done by the IT operations team — and they have tools that can flag issues like this to them where known vulnerabilities or issues are found.

Scanning on the code side would be handled by the developer team – however, this code-level approach is probably less developed in terms of maturity around processes. It should be done just as regularly as the operations team.

Practically, both operations and developer teams should regularly check for vulnerabilities across their applications; however it’s important to bear both code and tools in mind.

Open Source Insider: Why is this split on responsibilities a problem?

Often, it’s a case of not knowing status across the whole team – the developer who put the application together may know that a section of open source code is in place, but the manager or the QA team may not be aware of this.

There are also often fixes available for those issues – the recent ImageMagick vulnerability that was found last week was protected against using a config file available from the team. It’s been in existence for two years. However, that has to be applied. Not everyone knows that it exists, or that open source products like ImageMagick are being used in the first place.

It’s impossible to keep apps or other IT assets secure without knowing what you have in place. Keeping an accurate list of all assets – from endpoint devices through to software components – should be a base for IT security.

Open Source Insider What other steps can organisations take to protect their infrastructure from such problems?

Regularly scanning for vulnerabilities is essential to flag problems, whether they are new or old. However, putting aside time and budget to fix those issues is also required. It’s difficult to explain that there was not the budget to fix a known vulnerability if it gets exploited, particularly if you don’t have a good email trail where that issue is discussed.

Open Source Insider What should our ‘takeaway’ be here then? 

As an industry, we have to make managing vulnerabilities more accessible and enable the defenders to accurately know this inventory and pinpoint the most critical vulnerabilities.

Our traditional methods are not restrictive enough and yield huge numbers of vulnerabilities all tagged as critical. This overwhelms all but the most structured and mature organisations. Additional vulnerability attributes can be used to prioritise vulnerabilities beyond simple criticality – this helps IT teams concentrate on those issues that affect them the most.

Image Credit: Fajar Andryanto/Solent on Daily Mail.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.