BylinesArtificial IntelligenceCyber SafetyGovernance & ComplianceThreat Detection & Defense

Beyond Culture: The Systemic Security Flaw in Modern Software Development

GitLab’s Josh Lemos argues that modern security frustrations stem from systemic issues in tech infrastructure, not just team culture, and outlines how to break the cycle with DevSecOps.

By Josh Lemos, Chief Information Security Officer, GitLab

Josh Lemos, Chief Information Security Officer, GitLab

There is a prevailing narrative that security frustrations result from cultural issues, yet this overlooks the critical role of technical infrastructure. Leaders must confront the realities of tech stack complexity and the persistent challenges of effective vulnerability management. These are not just cultural hurdles but systemic obstacles impeding security maturity for organisations.

In Asia Pacific, the Singapore Institute of Directors’ new Cyber Resilience Guide for Boards in Singapore further reinforces the need for a cohesive security framework to protect digital assets in an evolving threat landscape.

GitLab’s latest DevSecOps survey revealed a disconnect between engineering and security teams. A majority (58%) of security respondents said they have difficulty getting development to prioritise the remediation of vulnerabilities, and 52% report that red tape often slows their efforts to fix vulnerabilities quickly. Security respondents also identified several work-related challenges, including difficulty understanding security findings, frequent false positives, and late-stage testing in the software development process. These findings point to a deeper organisational challenge that is not just about culture but also process and technology.

These frustrations and misalignments highlight a significant opportunity for organisations. DevSecOps can foster better integration between engineering and security to help address the root cause of how security is perceived and how teams work together.

Escaping the vulnerability hamster wheel

Vulnerability scanning surfaces all potential vulnerabilities, but not every common vulnerability or exposure (CVE) is reachable or exploitable.  As a result, security teams and developers spend significant time triaging and filtering through an ever-increasing number of vulnerability findings—a problem that has grown substantially since authenticated vulnerability scanning became standard practice.

While authenticated scanning has strengthened security programs in many ways, it has also forced developers on an endless hamster wheel of fixing non-critical issues—often at the expense of more critical tasks, such as addressing truly exploitable vulnerabilities.

This cycle contributes to the division between security and engineering teams. So, how can organisations break this cycle and improve collaboration between teams? Here are three ways to prevent common security frustrations.

  1. Focus on actionable high-fidelity signals

Excessive false positives were the second-highest-rated frustration identified by security respondents in our survey. False positives are a challenge but are often a vulnerability management problem in disguise.

If an organisation sees many false positives, that could be a sign that they haven’t done all they can to ensure high-fidelity security findings. Organisations should narrow the focus of their security efforts to what matters. That means traditional static application security testing (SAST) solutions are likely insufficient. SAST is a powerful tool but loses much of its value if the results are unmanageable or lack appropriate context. For SAST to be most effective, it must be used seamlessly with other security and development tools and be accessible to developers.

Another issue is that most scanning tools have a very narrow context window for understanding vulnerability findings. This is one of the areas where AI can help with AI-powered features that explain security vulnerabilities.

  1. Minimise the tech stack, minimise the attack surface 

Staying focused on what matters doesn’t just apply to security testing—it should start with how an organisation builds software in the first place.

Although AI promises to help simplify software development processes, many organisations still have a long road ahead. In fact, respondents who are using AI were significantly more likely than those not using AI to want to consolidate their toolchain, suggesting that the proliferation of different point solutions running different AI models could be adding complexity, not taking it away.

The ever-increasing complexity of organisations’ tech stacks is a major contributor to security frustrations. Some complexity is unavoidable when building large, multi-faceted software systems. However, organisations should take steps to avoid complexity resulting from suboptimal design decisions, such as difficult-to-maintain code and redundant dependencies. This unnecessary complexity creates a larger attack surface and generates more security scan findings for teams to sort through, prioritise, and address.

Organisations should approach development through the lens of software minimisation—being intentional about the tools they adopt and what they decide to build into their codebases. This will help minimise dependencies, improve the security of the software supply chain, reduce scanner noise, and ease the burden on developers to fix non-critical issues.

  1. Normalise paved roads 

Security testing happening too late in the software development lifecycle was another one of the top frustrations identified by our survey respondents. Teams might be frustrated when they want to ship something and it gets delayed because a vulnerability is detected late—but in many cases it might not have been possible to detect that vulnerability any earlier. What is possible, however, is operationalising easily deployable, reusable security components, limiting the variables and potential vulnerabilities.

Teams can avoid late-stage surprises by embracing tested and assured design patterns based on repeatable use cases: the “paved roads” approach. A paved road is a recommended path, including a curated set of tools, processes, and components, that teams can follow to build secure applications more efficiently—for example, using GitOps to version and deploy well-architected and tested Infrastructure as Code that deploys at scale for all workloads.

Adopting paved roads potentially removes some flexibility but ultimately reduces 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.

Security is a domain, not a team

The integration of security into engineering teams is accelerating – a trend only amplified by the rapid adoption of AI and the resulting surge in software release velocity. GitLab’s survey revealed that 66% of respondents are releasing software at least twice as last year. To capitalise on this speed without compromising security, organisations must establish frameworks that prioritise security. For example, Lendlease has demonstrated the power of this approach by empowering developers across Australia, Singapore, the U.S., and the U.K. with a unified DevSecOps platform that integrates security into the development process at the earliest stages to accelerate software deployment.

This underscores that bridging the cultural gap between development and security is only the first step. Security transformation demands a fundamental reimagining of software development. We must move beyond fostering collaboration to revolutionise core processes – optimising existing codebases and building scalable, engineering-centric solutions that seamlessly integrate across the entire organisation. Only then can we ensure that security keeps pace with the unprecedented speed of modern software development.

Josh Lemos

Chief Information Security Officer at GitLab

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *