You’ve Tackled Shadow IT - Now It’s Time to Tackle Shadow DevOps

Originally published by Dazz.

Written by Noah Simon, Head of Product Marketing, Dazz.

For years, companies have been solving Shadow IT - the use of software, hardware, or SaaS services without the knowledge or approval of the IT team.

While Shadow IT remains an evolving challenge, IT and Security teams have been able to improve shadow IT discovery through solutions such as:

• Remote Monitoring, Mobile Device management, and Endpoint Security solutions
• SaaS and Secure Service Edge (SSE) solutions
• Network Monitoring tools

Now that just about every company is a software company, a newer challenge has emerged: Shadow Devops.

‍

What is Shadow DevOps?

Shadow Devops consists of essentially “shadow code” and “shadow pipelines”.

Let’s start with shadow code - code that makes its way into production, but is not known, maintained, documented -- and most importantly, vetted and approved. Shadow Code can take a few forms:

• Legacy code that is no longer actively maintained or documented, but still being used
• Third-Party / Open source: the use of third-party libraries and code obtained and used without official approval and vetting
• Unofficial code: undocumented code written by developers that have not gone through official testing processes

Shadow pipelines occur for many of the same reasons as well. Unknown development pipelines include:

• Non-standard development practices: individual developers or teams may use development practices and tools that differ from the standard processes put in place by the DevOps or IT team.
• Ad-hoc pipelines: developers may create their own separate pipelines for the purposes of prototyping or experimenting, and these pipelines may contain code that eventually works its way into production.

‍

What Risks Are Introduced From Shadow Devops?

Shadow Devops can pose risks internal to your business, but also to the applications that are built and used by customers and consumers.

Let’s start with the risks of shadow code. These include:

• Vulnerabilities that are introduced from code that hasn’t been identified and/or monitored. One of the biggest causes of shadow code - third party libraries -- is now a pressing security risk. Veracode research shows that roughly seven in every 10 applications have flaws. Recently, OpenAI, makers of ChatGPT discovered it was using a Redis library known to be vulnerable, exposing ChatGPT user data.
• Auditing: unvetted and unmonitored code can lead to auditing, and potentially compliance issues
• Stability: code that hasn’t been sanctioned can introduce performance and stability issues

Shadow pipelines may result in the risks above, and additionally knowledge transfer. As developers enter and exit teams and companies, shadow pipelines make it difficult to track down documentation and knowledge about specific code bases.

‍

How to Monitor Shadow DevOps

Just like Shadow IT, there are processes and technologies you can implement to monitor and reduce Shadow DevOps.

From a process standpoint, enforcing code documentation, reviews, version control, and codebase inventory are extremely important. Yet, even with strong reinforcement - any process can break down, especially in fast-paced development environments.

Many companies supplement these processes with a few technologies, including:

• IaC Platforms: The use of IaC platforms usually result in more efficient and transparent infrastructure changes that are parallel to application development
• AppSec Tools: Source code analysis (SCA) and dynamic or static application testing (DAST/SAST) can identify undocumented or potentially risky code within your software systems
• CI/CD scanning: GitHub, GitLab, Jenkins, and other CI/CD platforms have native capabilities to scan code repositories
• IDE scanning: many IDE-integrated tools feature the ability to run scans directly within the IDE