GitLab: Addressing the Roots of Enterprise Security Issues

Security frustrations and challenges in organisations are often perceived as a cultural issue — but leaders also need to focus on other challenges including tech stack, vulnerability management and process complexity, says GitLab’s CISO, Josh Lemos. 

GitLab is an AI-powered DevSecOps platform designed to fundamentally change the way development, security and ops teams collaborate and build software. It helps companies to manage the growing complexities around developing, securing and deploying software to boost efficiency and innovation. 

As CISO, Josh drives enterprise vision, strategy and programme to ensure customers and their organisations are protected. Here, he brings his unique insight from this work to some of the most common leadership challenges. 

What are the main issues software developers face?

GitLab’s survey of DevSecOps professionals revealed several issues related to organisational culture that could inhibit greater alignment between engineering and security teams. 

A majority (62%) of UK security professionals said they have difficulty getting developers to prioritise remediation of vulnerabilities, and 52% said that red tape often slows their efforts to fix vulnerabilities quickly. 

Security professionals also pointed to several specific challenges related to their jobs, including difficulty understanding security insights, excessive false positives and testing happening too late in the software development cycle.

DevSecOps promises stronger integration between engineering and security, but it’s clear that frustrations and misalignment remain. 

That’s because these challenges are symptoms of a more significant problem with how organisations view security, how teams work together and how they allocate time to security.

How has vulnerability scanning improved security programmes? 

Vulnerability scanning surfaces all possible vulnerabilities. However, just because a software package has a common vulnerability or exposure (CVE) doesn’t mean it’s reachable or usable by bad actors. 

Security teams and developers alike are still triaging and filtering through vulnerability learnings that have grown exponentially over the years since authenticated vulnerability scanning became standard.

The move to authenticated scanning has improved the effectiveness of security programmes in multiple ways, but it’s also put developers on an endless cycle of fixing things that don’t matter.

When teams waste their efforts on patches that don’t fix an exploitable vulnerability, they are removed from more critical tasks, such as patching vulnerable and exploitable flaws. 

That’s the source of much of the chasm between security and engineering teams today.

How can organisations address the underlying causes of these issues?

They should begin by silencing the noise and focusing on actionable high-fidelity inputs. 

Excessive false positives were the second highest-rated frustration pointed out by security respondents. False positives are an issue, but are often a vulnerability management problem in disguise.

Many false positives could indicate that an organisation hasn’t done everything possible to ensure its security findings are high-fidelity. 

Organisations should narrow the focus of their security efforts to address what’s important. That means traditional static application security testing (SAST) solutions are probably insufficient – SAST is a powerful tool but loses its value if the results are unmanageable or lack appropriate context.

Another challenge is that most scanning tools have a very slim context window for understanding vulnerability learnings. 

This is one of the areas where AI can help with AI-powered features that outline security vulnerabilities.

What about minimising the tech stack? Does it reduce the attack surface?

The growing complexity of organisationsal tech stacks is a major contributor to security challenges. 

Some complexity is a given when building large, multi-faceted software systems. However, organisations should avoid complexity resulting from suboptimal design calls, such as difficult-to-maintain code and outdated dependencies. 

This unnecessary complexity creates a bigger attack surface and generates more security scan results for teams to sort through, prioritise and remedy.

Although AI is poised to help simplify software development processes, many organisations still have a way to go. According to a GitLab survey, businesses using AI were considerably more likely to want to streamline their toolchain than those not using AI. 

This suggests that the increasing use of different point solutions running different AI models could be adding complexity, not removing it.

Organisations should view development through the lens of software minimisation – being intentional about the software required in their codebases to deliver their software. 

This helps reduce dependencies, improve the security of the software supply chain, reduce scanner noise and lessen the burden on developers to fix non-critical issues.

What can developer teams do to avoid surprises?

Security testing happening too far into the software development lifecycle is another of the top frustrations identified by DevSecOps professionals. 

Teams might be frustrated when they want to ship something and it gets held back because a vulnerability is detected late. But often, it might not have been possible to detect that vulnerability sooner. 

What is possible, however, is operationalising easily deployable, reusable security components, limiting the unknowns and potential vulnerabilities.

Teams can avoid surprises late in the game by embracing tested and assured design patterns based on standardised use cases – known as the “paved roads” approach. 

A paved road is a suggested path, including a curated set of tools, processes and components, that teams can use to build secure applications more efficiently. For example, utilising GitOps to version and deploy well-built and tested Infrastructure as code that deploys at scale for all workloads.

Adopting paved roads may remove some flexibility, but it ultimately cuts the operational burden and rework on engineering teams and increases security. 

This needs to be a collaborative effort between security and development. Security can help to design paved roads, but engineering has to be involved to operate and maintain them as part of the codebase.

Why is security shifting from a separate team to an engineering practice?

We already see security as a practice transition into engineering teams (similar to performance monitoring or observability), and we can expect the borders between the two to continue to blur. 

However, with the quick adoption of AI and the corresponding acceleration of software development – 65% of UK DevSecOps professionals said they are releasing software twice as fast or faster than a year ago – it will be essential for organisations to establish systems and frameworks that optimise for the most substantial security benefit. 

The notion of a cultural disconnect between development and security isn’t the whole story. 

Fostering a culture of collaboration is essential.

Security and engineering teams must also collectively rethink foundational aspects of software development, such as optimising existing codebases and building scalable engineering-centric tools that technical teams across the business can seamlessly adopt.

Explore the latest edition of Cyber Magazine and be part of the conversation at our global conference series, Tech & AI LIVE and Cyber LIVE.

Discover all our upcoming events and secure your tickets today.

Cyber Magazine is a BizClik brand